But are ALL your (email) passwords secure.
Hackers look for and will eventually find a chink in the armor (no offense!)
http://krebsonsecurity.com/2012/06/attackers-target-weak-spots-in-2-factor-authentication/
Topic: [Password Leak] LinkedIn database hacked - page 3. (Read 12914 times)
And remember to always salt your passwords 
I put salt on everything but common I know where to draw the line and its not going to be on a Heart rate monitor!
Thanks for having that publicly disclosed on your site. An example for all sites to follow.
is there only one unique string (password) that corresponds to a given hash?
Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.Yes, thank you. Now, is this statement still true when a typical password is shorter than the 32-byte hash?
For MD5: http://stackoverflow.com/a/2000014
Alright, does this mean that if my password is a reasonably random string, and the unsalted hash is made public, it may be possible to "reverse" it, but it won't be possible to tell for sure that that was the actual password - there could be another string with the same hash out there.
Also, does this mean that you could still type in a "wrong" password (that hashes into the proper hash), and you would be able to log in just fine, since server is ultimately comparing hashes?
Sorry for silly questions, I'm not versed in this topic but I want to understand the implications of these kinds of leaks.
Alright, does this mean that if my password is a reasonably random string, and the unsalted hash is made public, it may be possible to "reverse" it, but it won't be possible to tell for sure that that was the actual password - there could be another string with the same hash out there.
Also, does this mean that you could still type in a "wrong" password (that hashes into the proper hash), and you would be able to log in just fine, since server is ultimately comparing hashes?
Sorry for silly questions, I'm not versed in this topic but I want to understand the implications of these kinds of leaks.
Also, does this mean that you could still type in a "wrong" password (that hashes into the proper hash), and you would be able to log in just fine, since server is ultimately comparing hashes?
Sorry for silly questions, I'm not versed in this topic but I want to understand the implications of these kinds of leaks.
Yes. The server never knows the password it only knows the hash. It hashes the password provided and compares it to the hash it has stored. If they match it logs you in.
So hypothetically if
"This is my password" and "86f7e437faa5a7fce15d1ddcb9eaeaea377667b8"
both hash to "eee411109a229046154bc9d75265a9ccb23a3a9c" then the server would let you login with either.
This is why hashes need to be reasonably long. MD5 (should be considered ancient and horribly broken) is only 128 bit, SHA-1 is 160 bit, SHA-256 and SHA-512 are 256 and 512 bit. The larger the keyspace the lower the probability that any two values will produce the same hash.
This same principal applies to Bitcoin. Since addresses are hashes of the public key it is theoretically possible for two (or more) different public keys to hash to the same address. Any of the associated private keys could spend the funds. RIPEMD-160 and SHA-256 are considered cryptographically strong and have very large keyspaces which makes any collision academic at best. If the algorithms were ever degraded that risk would become more real.
LastPass has your encrypted passwords. They don't, however, have the decryption key.
Will you put your ass on the line to defend that statement as an absolute truth?
is there only one unique string (password) that corresponds to a given hash?
Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.Yes, thank you. Now, is this statement still true when a typical password is shorter than the 32-byte hash?
For MD5: http://stackoverflow.com/a/2000014
Alright, does this mean that if my password is a reasonably random string, and the unsalted hash is made public, it may be possible to "reverse" it, but it won't be possible to tell for sure that that was the actual password - there could be another string with the same hash out there.
Also, does this mean that you could still type in a "wrong" password (that hashes into the proper hash), and you would be able to log in just fine, since server is ultimately comparing hashes?
Sorry for silly questions, I'm not versed in this topic but I want to understand the implications of these kinds of leaks.
It's almost impossible for passwords with readonable length. But yes, the server will accept anything if the hash matches.
You may want to read this: http://en.wikipedia.org/wiki/Birthday_problem
is there only one unique string (password) that corresponds to a given hash?
Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.Yes, thank you. Now, is this statement still true when a typical password is shorter than the 32-byte hash?
For MD5: http://stackoverflow.com/a/2000014
Alright, does this mean that if my password is a reasonably random string, and the unsalted hash is made public, it may be possible to "reverse" it, but it won't be possible to tell for sure that that was the actual password - there could be another string with the same hash out there.
Also, does this mean that you could still type in a "wrong" password (that hashes into the proper hash), and you would be able to log in just fine, since server is ultimately comparing hashes?
Sorry for silly questions, I'm not versed in this topic but I want to understand the implications of these kinds of leaks.
We're talking about a major password leak at LinkedIn, but we're comfortable to have ALL of our passwords stored on an online service (!). Reading more about LastPass and watching the video on how to use it, I understand that LastPass saves the passwords online, so it can "restore" them to another browser on the same or another computer. Moreover, there are features to store auto-fill information (address, email, etc), so you don't have to fill it every time on every site.
Can you imagine the impact if this site has a similar leak of user data?
Can you imagine the impact if this site has a similar leak of user data?
LastPass has your encrypted passwords. They don't, however, have the decryption key.
The safest thing you can do as a consumer is user a random password at each site.
Doing that is much easier with a dedicated password manager, like LastPass.Apologies to all for the offtopic but if you think about it, it's not.
We're talking about a major password leak at LinkedIn, but we're comfortable to have ALL of our passwords stored on an online service (!). Reading more about LastPass and watching the video on how to use it, I understand that LastPass saves the passwords online, so it can "restore" them to another browser on the same or another computer. Moreover, there are features to store auto-fill information (address, email, etc), so you don't have to fill it every time on every site.
Can you imagine the impact if this site has a similar leak of user data?
Local storage (encrypted ofc) or even what Steve suggested is the way to go IMO.
If you restrict the inputs to being within some normal distribution of user password length, then there are no longer an infinite number of inputs. So there are no longer an infinite number of inputs that can result in the same output.
That doesn't make the statement false though because of the hedging word theoretically.
One other thing I would note here is that the act of telling the public how many rounds there are in your password hashing settings may save the attacker quite a bit of work.
That doesn't make the statement false though because of the hedging word theoretically.
One other thing I would note here is that the act of telling the public how many rounds there are in your password hashing settings may save the attacker quite a bit of work.
Would someone please explain this for the uninitiated: is there only one unique string (password) that corresponds to a given hash? I believe the technical term is collision resistance, right? Once you reverse the hash, can you know for sure that you got it right? If password is a dictionary word, it may be obvious, but how about if everyone were using random strings for their passwords? Would the hacker ever be able to know for sure if the reversed hash is the right one?
They don't reverse the hash that is pretty much impossible since these are one way mathematical functions. One input is one output, yet the output can't be reverse to get the original input. So what hackers do is use a dictionary and obvious password creating techniques to create a hash that will be matched against the the hashes they have. Random strings can work but hackers again can create these strings using just like 0000, 0001, 0002, to guess these passwords. Using capitals and numbers can throw it off making it that much more random. For website developers we slide in random Strings with the actual String they want to hash, those random strings are called salts to make the hash harder to crack, not salting can make it an easy couple weeks or if you have the right equipment, a couple of days to crack. People also double hash and triple hash with these salts making it even tougher cause the hacker doesn't know how many times you hash to create that string and can save a database hack like this one.
is there only one unique string (password) that corresponds to a given hash?
Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.Yes, thank you. Now, is this statement still true when a typical password is shorter than the 32-byte hash?
For MD5: http://stackoverflow.com/a/2000014
is there only one unique string (password) that corresponds to a given hash?
Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.Yes, thank you. Now, is this statement still true when a typical password is shorter than the 32-byte hash?
is there only one unique string (password) that corresponds to a given hash?
Theoretically there are are infinite number of inputs that will result in the same hash because the hash function outputs a fixed-length value but the input can be any length.
Would someone please explain this for the uninitiated: is there only one unique string (password) that corresponds to a given hash? I believe the technical term is collision resistance, right? Once you reverse the hash, can you know for sure that you got it right? If password is a dictionary word, it may be obvious, but how about if everyone were using random strings for their passwords? Would the hacker ever be able to know for sure if the reversed hash is the right one?
Bitcoinica: Salted BCrypt with 20 iterations. Enforce minimum 8 characters. It can take months to crack a simple password. (And I use this for all my future app projects. Also recommend everyone to do the same.)
I assume you mean Salted Bcrypt w/ workload=20, that is 2^20 = 1 million iterations. Slightly harder.
A single round of bcrypt takes roughly 5x the clock cycles as long as SHA-256 (OpenCL optimized). Thus bcrypt(20) is on the magnitude of 5 million times harder to crack than salted SHA-256 hash.Another way to look at it. If a hacker could brute force a given password hashed SHA-256 in 1 second it would take them 57 days on bcrypt(20).
There is absolutely no reason to use anything weaker than bcrypt (or similar chained iterative functions like PBKDF2 or scrypt).
pass - stupid
MD5(pass) - cryptographically weak
SHA-256(pass) - vulnerable to rainbow tables
SHA-256(pass.salt) - vulnerable to brute force
bcyrpt(pass,salt,2^10) - vulnerable to weak/common password list
bcyrpt(strongpass*,salt,2^10) - computationally infeasible to attack
strongpass being enforced by the site as
8+ char
not in dictionary
not in known password list
And the best part about bcrypt is that you can dynamically adapt it over time to keep up with Moore's law. Just update the hash whenever after a user successfully logs in with the updated difficulty level.
With the SHA family, you're stuck.
Bitcoinica: Salted BCrypt with 20 iterations. Enforce minimum 8 characters. It can take months to crack a simple password. (And I use this for all my future app projects. Also recommend everyone to do the same.)
I assume you mean Salted Bcrypt w/ workload=20, that is 2^20 = 1 million iterations. Slightly harder.
A single round of bcrypt takes roughly 5x the clock cycles as long as SHA-256 (OpenCL optimized). Thus bcrypt(20) is on the magnitude of 5 million times harder to crack than salted SHA-256 hash.Another way to look at it. If a hacker could brute force a given password hashed SHA-256 in 1 second it would take them 57 days on bcrypt(20).
There is absolutely no reason to use anything weaker than bcrypt (or similar chained iterative functions like PBKDF2 or scrypt).
pass - stupid
MD5(pass) - cryptographically weak
SHA-256(pass) - vulnerable to rainbow tables
SHA-256(pass.salt) - vulnerable to brute force
bcyrpt(pass,salt,2^10) - vulnerable to weak/common password list
bcyrpt(strongpass*,salt,2^10) - computationally infeasible to attack
strongpass being enforced by the site as
8+ char
not in dictionary
not in known password list
We salt for the rainbow and iterate for the dictionary. You gotta love technology lingo.
Jump to: