New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
How does that make it insecure? A 59-60 characters long password is sufficient secure.
bcrypt cutting off long passwords isn't a weakness of bcrypt. It's simply not designed for longer passwords. You don't increase the cryptographic strength by increasing the password length, you increase it by increasing the number of iterations.
Bullshit. There are plenty of people that use phrases instead of passwords for authentication - in their case it may not be enough. That you personally find 60 characters enough does not mean that this goes for everyone else. You have to keep in mind that you're not developing a site for yourself, but for other users.
Um, yes, it is. If you're not aware of the character limit, [you will be caught by surprise by PHP (and everything else) silently cutting off your password, thereby reducing the strength of the password to the max amount of characters(http://pastebin.com/2Kyh8VXn), regardless of the actual password strength - this may lead to making bad decisions in terms of whether a passphrase is sufficient or not.
If you are aware of the character limit, you are potentially forcing your users to choose less secure passwords, which is a weakness in itself.
Why are you guys making such an effort to 'defend' bcrypt when it has a clear demonstrable security issue, while offering no unique features that I am aware of?
Instead of putting that effort into trying to find justification for using bcrypt, put it into using a sane hashing algorithm. Scrypt, SHA512, I don't care - as long as it isn't an algorithm with a known (and practically undocumented!) vulnerability. You're promoting poor security practice.
Uh, what? You realize that password length does have a significant impact on the strength of a hash, right?
@joepie91 from password breaches it's clear the majority use weak passwords - often very short. This obviously doesn't make it good/right but that is the reality. Whilst I can agree there are peeps that do use very long passwords/phrases this is a tiny, tiny minority. A discussion about webappsec that digresses into supporting 60+ len passwords is missing the wood for the trees...bigger fish to fry, no?
Please learn your math. There is no practical benefit of using a password with 70 characters instead of one with 60 characters.
Here is the script --
http://pastebin.com/TtbBmKvJ
Apart from other issues mentioned above, It is a bad idea to let the user know if password was wrong or the email(userId) was wrong after a login failure. You should print out the same failure message for both.
Most of the time I'm using > 128 character passwords from keepass, dunno about youguys. If a site can't handle that I move away, but if I have to use it I send a mail to the owners. Pagerduty.com first had a 40 character limit, mailed them, now they allow my 256 char password.
Crap. Every character added to a passwords increases the brute force time exponentially. (As long as the algorithm or implementation is not cracked). There is a big difference between a 60 or 70 char password.
True, but the practical benefit is 0. Does it really matter if an attacker needs 10 years vs 15 years to bruteforce your password? I don't think so :-).
That would be valid reasoning only if their character limit added more security in another respect - which I am not aware of it doing.
I've said this on IRC towards NickM and I'll say it again here:
This is not something I'd necessarily agree with - not telling the user what the problem is, barely adds any security (after all, you should already have bruteforce protections in place anyway), and creates a very big problem for users. More about this here: http://blog.mailchimp.com/social-login-buttons-arent-worth-it/
Actually, it does. Your response seems to assume that cryptographical algorithms will always retain the same strength and tak e the same time to be bruteforced - but that isn't the case. Computing equipment gets stronger over time, and algorithms get cracked. The advantage may not exist right now, but it damn well will when the algorithm of choice suddenly gets broken. And especially if the site you are signing up to still uses MD5 hashes (and sadly, many do), you'll want to have something that at least takes a bit of time to crack. Which makes me think of the following joke:
I agree with the article on reduction of login failures due to ease of guessing/recollecting your own password. At the same time, you make it much easier for an acquaintance to guess and identify your userid/password with the mentioned approach.
To improve the login experience, I send a welcome message with userId mentioned in it during registration. The mail also contains the email verification/account activation link whenever verified mails ids are needed.
It's a matter of choice and I have seen very few authentication systems using specific error messages for id and password errors.
Not really. If you allow more than a certain amount of login attempts without at the very least notifying the user and temporarily blocking someone in the first place (which would make 'hiding' things pointless), you're doing it wrong to start with.
A lot of people tend to change e-mail addresses and lose access to old e-mails or e-mail addresses. They would have a problem. This isn't a rare situation either.
No, it's not. You can only call it a 'matter of choice' if there is no significant difference to the user regardless of what you pick. It's matter of user-friendliness versus perceived security.
I've seen many do that. Not that it matters; popularity should not be a factor in security (or user-friendliness, for that matter).
@joepie91 True, i didn't consider the people using passphrases. According to some quick research a common 58 characters long passphrase provides only 80 bits of entropy.
@Raymii there is no practical difference between a completly random alphanumerical 60 characters and 70 characters password.
completly random does not exist. And in cracking time (brute-force) there is a big difference. However, lets say a thousand years and two-thousand years, still big difference.
Now i am displaying the same error message as "Either Email ID or Password is wrong!!"
for both when Email Id not in the db or the corresponding password is wrong.
Now the question is how do I use the crypt() function with few thousands of SHA256 rounds
as mentioned by @joepie91 ..
Also the script which I mentioned above .. how much it is vulnerable to SQL Injection .
http://pastebin.com/TtbBmKvJ
as mentioned by @joepie91 ..
This is a (modified) snippet from the code that I use
Reasoning for the above: in normal crypt() usage it will output a string that contains not just the hash, but also the salt - and since I use a dynamic (per-user, database-stored) salt plus a static (global, disk-stored) salt, it would be a problem for me to store the static part of the salt in the database. Therefore I generate and store the salt seperately, and just use the hash that is returned from the crypt() function
Splitting up into a dynamic salt and a static salt is a good idea because it means that someone cannot get the full salt through an SQL injection (or other kind of database access) and would need actual disk access to get the entire salt - which makes cracking a hash harder. This does increase the complexity of your code, and just using a dynamic salt will also be sufficient most of the time.
The simpler way, only using a dynamic salt:
You can just store the entire $hash in your database as the hash, and it'll include the salt. Note that the
random_string
function doesn't actually exist in PHP - it's a custom function I wrote. The code for this is as follows:http://pastebin.com/TtbBmKvJ
It is currently not vulnerable - but to avoid making mistakes in the future, you should still look into using PDO, especially because the
mysql_*
functions are now officially deprecated and will be removed from PHP in the near future.I'd also like to remind you that giving the same error for both an incorrect username and password, doesn't add any proper security - it's a form of security through obscurity, which should be heavily frowned upon. Instead of giving vague errors, add a bruteforce protection, where for example IPs or accounts are temporarily blocked after entering the wrong password 10 times.
I suggest you read this: http://phpacademy.org/forum/viewtopic.php?f=28&t=15356
"Thousands of SHA256 rounds" = super bad.
Doesn't come back in the article as far as I can see. Please @kamalnasser, tell my why it is "super bad"?
"Thousands of SHA256 rounds" = super bad.
That refers to manually doing double hashing, not using the built-in crypt() function which was designed to do this in a proper manner.
@joepie91 that's what I meant, didn't read the whole topic here
I think something that's been missed here, yet I've seen multiple times:
Do NOT install random services that you do not need on the web server. For instance, I've seen the following services that are not required on a simple web server:
8888 - Sun Answerbook HTTP Server.
27015 - Valve Game Server (wtf)
Basically, you should cut down the points of entry into the system possible.
For SSH, do use Private/Public Key instead of password authentication.
Seems.. legit?
Of course it does. See quantum RNGs. But even /dev/random produces enough entropy to create a secure password.
The problem is that we aren't talking about 1000 vs 2000 years. Assume an a-zA-Z0-9 password. That gives 62 possible characters, resulting in 62^60 vs 62^70 possible combinations. A recent computer with a GPU can compute ~5000-1000 bcrypt hashes per second (assuming a reasonable number of rounds).
Taking into account Moore's law that results in around 163,840,000 guesses per second on a single computer 30 years from now. Lets assume your password is so important 30 years from now that it gets cracked on 6,100 nodes at the same time, which results in 1,000,000,000,000 guesses per second.
This means that it will take 10^88 years to crack your 60 characters password (or 10^105 for the 70 characters one). As you can see there is no practical difference.
You have to consider that some developers use email addresses as the username. Is email obscurity frowned upon??
If it's getting this technical: Don't you mean it could take up to 10^88 years? I think it's safe to say that most people don't use a password consisting of only 9's.
I don't see how indicating whether an e-mail address exists or not, can be considered a problem in any reasonable situation?
Of course, i was speaking only in terms of the worst case scenario.
Email exists = user with that email exists = email is valid and belongs to someone = you'll get an email harvesting bot hammering your login page.
It depends on your application, for example:
None of them tell you what piece of information is wrong because none of the "usernames" are openly available to the public.
Yeah, no.
A login page does not give any more certainty about the validity of an e-mail address than the source where said harvesting bot found the e-mail address in the first place. Trying to find e-mails by bruteforcing a login page is extremely inefficient and generally useless to a spammer.
That did not actually explain how indicating whether an e-mail address exists or not, is a problem. "They do it too" is not valid reasoning, especially not when talking about security. Instead, come up with solid reasoning.
Why don't you make the argument for showing valid usernames, emails and account numbers to the public?
The "Solid Reasoning" behind "They do it too" should be pretty "Self-Explanatory".