Am I right or am I right?
-
I have been fretting over the question of hacked userids/passwords. As I understand it, the stolen password is not actually the password but a hashed version of it which the hacker then decodes by brute force and ignorance to arrive at the actual password. But what if that wasn't the actual password. What if the system I was using performed some sort of transformation before it hashed the password for storage. For example, when I log on to my account, I type in pass123 as my password, but unbeknown to me, the system translates that to 321ssap, hashes it and stores it. The hacker tries to log onto my userid and types in 321ssap as my password which is what he thinks it is. This gets translated to 123pass and hashed for checking. But that hash value is not the same as the one that is stored. Therefore an "Incorrect password" error message is generated. Am I missing something here?
-
Seriously, my (mandatory) car insurance company sent me the current password in plain text when I clicked on "forgot my password" (turned out I didn't forget my password, they simply changed the accepted character set for the passwords between my logins so my password wasn't valid but I couldn't log in to change it. Had to spend 3 days on the phone and threaten them with Hell, Damnation and going to another company). That means either my password was stored in clear text or it was sotred in such a way that it was recoverable. That is BAD.
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X // No comment
Relax - it was no trouble to retrieve your password...It was stored as plain text to avoid any future problem :laugh:
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
-
I have been fretting over the question of hacked userids/passwords. As I understand it, the stolen password is not actually the password but a hashed version of it which the hacker then decodes by brute force and ignorance to arrive at the actual password. But what if that wasn't the actual password. What if the system I was using performed some sort of transformation before it hashed the password for storage. For example, when I log on to my account, I type in pass123 as my password, but unbeknown to me, the system translates that to 321ssap, hashes it and stores it. The hacker tries to log onto my userid and types in 321ssap as my password which is what he thinks it is. This gets translated to 123pass and hashed for checking. But that hash value is not the same as the one that is stored. Therefore an "Incorrect password" error message is generated. Am I missing something here?
xiecsuk wrote:
Am I missing something here?
Quite a lot, because it's pretty complicated. Firstly, you are assuming they've hashed the password, some (even large companies) don't they use a symmetric algorithm. If a company can send your password to you, say via e-mail, they are using a symmetric algorithm (at best).This is insecure. The idea is the hashing is one way, so the hash cannot be reversed, so password123 ---> 7FDEADBEEF or whatever. It the password table is stolen there are two immediate vulnerabilities. First off, if the system allows a bad password such as "password" this is going to be the most common value stored in the password field across the table, and you can work backwards through the most probable ones. The second vulnerability is something called a rainbow table, this reduces the amount of time it takes to reverse engineer a password that is going to lead to a particular hash. Worse, these tables are readily available, so you don't need the compuation time to get started. You can salt the password (adding a random bit of text which you store) in various ways, e.g. add then hash or has the password, salt then hash the result. This mitigates against the vunerabilities described above, but given enough time brute force strategies will always win - even if enough time means from now until after the end of the universe.
KeithBarrow.net[^] - It might not be very good, but at least it is free!
-
xiecsuk wrote:
As I understand it, the stolen password is not actually the password but a hashed version of it
In most cases, lately reported over media, it was plain text... :((
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
http://plaintextoffenders.com/[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I am mathematican.And my english isn't good. So sorry if I fail to make oneself understood. I have studied cryptology for a little while. I can say that: Hash code's inverse functions's solutions calculates forever.
Not all of them: MD5 is officially "broken" (and has been for years) - it is possible to reverse MD5 and get a usable password input directly from the output. Not necessarily the original input, but one that generates the same hash value. http://cryptocrats.com/crypto/md5-the-hash-algorithm-is-now-broken/[^] SHA-1 is considered insecure (because there are ways to generate collisions that don;t need a brute force attack), but SHA-2 is still OK, for the moment. http://arstechnica.com/security/2012/10/sha1-crypto-algorithm-could-fall-by-2018/[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
I have been fretting over the question of hacked userids/passwords. As I understand it, the stolen password is not actually the password but a hashed version of it which the hacker then decodes by brute force and ignorance to arrive at the actual password. But what if that wasn't the actual password. What if the system I was using performed some sort of transformation before it hashed the password for storage. For example, when I log on to my account, I type in pass123 as my password, but unbeknown to me, the system translates that to 321ssap, hashes it and stores it. The hacker tries to log onto my userid and types in 321ssap as my password which is what he thinks it is. This gets translated to 123pass and hashed for checking. But that hash value is not the same as the one that is stored. Therefore an "Incorrect password" error message is generated. Am I missing something here?
Correct. To horse with passwords, you need a battery of scripts, to handle the myriad staple functions that protect them.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Relax - it was no trouble to retrieve your password...It was stored as plain text to avoid any future problem :laugh:
Skipper: We'll fix it. Alex: Fix it? How you gonna fix this? Skipper: Grit, spit and a whole lotta duct tape.
also to speed things up we have now stored it on 500000 servers location in dubious countries around the world
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
Seriously, my (mandatory) car insurance company sent me the current password in plain text when I clicked on "forgot my password" (turned out I didn't forget my password, they simply changed the accepted character set for the passwords between my logins so my password wasn't valid but I couldn't log in to change it. Had to spend 3 days on the phone and threaten them with Hell, Damnation and going to another company). That means either my password was stored in clear text or it was sotred in such a way that it was recoverable. That is BAD.
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X // No comment
No, no - they store your password and check it as a nice secure SHA-2 hash value. And in case you need to recover it (as you did) they store the plain text version in the same table! :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
http://plaintextoffenders.com/[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
"Page 1 of 289" :sigh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
No, no - they store your password and check it as a nice secure SHA-2 hash value. And in case you need to recover it (as you did) they store the plain text version in the same table! :laugh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
no that was the old way, now its just stored as "password" so their is no need to decrypt it (saves the NSA 5000 man hours a month )
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
I am mathematican.And my english isn't good. So sorry if I fail to make oneself understood. I have studied cryptology for a little while. I can say that: Hash code's inverse functions's solutions calculates forever.
Yes but a brute force dictionary attack confronting to a DB of hashed passwords does not. It is a common bruteforce: hash("aaaa") = $1. Does $1 exist in the DB? hash("aaab") = $2. Does $2 exist in the DB? .... long, as brute force attacks are, but it works. Unless there is some salt in the hashed password.
Geek code v 3.12 GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- r++>+++ y+++* Weapons extension: ma- k++ F+2 X // No comment
-
"Page 1 of 289" :sigh:
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
you're on the front page? well done
You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.
-
I have been fretting over the question of hacked userids/passwords. As I understand it, the stolen password is not actually the password but a hashed version of it which the hacker then decodes by brute force and ignorance to arrive at the actual password. But what if that wasn't the actual password. What if the system I was using performed some sort of transformation before it hashed the password for storage. For example, when I log on to my account, I type in pass123 as my password, but unbeknown to me, the system translates that to 321ssap, hashes it and stores it. The hacker tries to log onto my userid and types in 321ssap as my password which is what he thinks it is. This gets translated to 123pass and hashed for checking. But that hash value is not the same as the one that is stored. Therefore an "Incorrect password" error message is generated. Am I missing something here?
xiecsuk wrote:
I type in pass123 as my password, but unbeknown to me, the system translates that to 321ssap, hashes it and stores it
This is very close. Actually, what you are thinking of is a salted hash. In other words, the user types in the password, the receiving application receives the password over some secure method (like HTTPS) then it 1. takes the original password 2. adds a secret salt value 3. hashes the entire thing (pass + salt) Since a hash is one-way, no one can really decrypt them -- that we know of. Same Is Same But look, every time you hash "ABCD" with the same algorithm, you get the same hash. That means a nefarious character can create tables of hashes (rainbow tables) of common words. Then, just compare the hash they have to the hashes stored in the datbase. Proper Salt Probably Prevents However, if the original value were properly salted, this would protect against that problem, unless the nefarious character should learn what the salt is. which is usually not the problem. Usually the problem is that the passwords are stored in the database in clear text or simply not salted.
-
Correct. To horse with passwords, you need a battery of scripts, to handle the myriad staple functions that protect them.
I wanna be a eunuchs developer! Pass me a bread knife!
Do we get extra points when understanding the reference here ? Or minus points for those who don't ?
-
xiecsuk wrote:
I type in pass123 as my password, but unbeknown to me, the system translates that to 321ssap, hashes it and stores it
This is very close. Actually, what you are thinking of is a salted hash. In other words, the user types in the password, the receiving application receives the password over some secure method (like HTTPS) then it 1. takes the original password 2. adds a secret salt value 3. hashes the entire thing (pass + salt) Since a hash is one-way, no one can really decrypt them -- that we know of. Same Is Same But look, every time you hash "ABCD" with the same algorithm, you get the same hash. That means a nefarious character can create tables of hashes (rainbow tables) of common words. Then, just compare the hash they have to the hashes stored in the datbase. Proper Salt Probably Prevents However, if the original value were properly salted, this would protect against that problem, unless the nefarious character should learn what the salt is. which is usually not the problem. Usually the problem is that the passwords are stored in the database in clear text or simply not salted.
What he suggests is that the password is transformed again before being hashed, using an algorithm proper to the website. I still fail to see why this is not clever (and it is probably not, otherwise they would all do it. Or maybe they all do it already and nobody knows ?).
-
xiecsuk wrote:
Am I missing something here?
Quite a lot, because it's pretty complicated. Firstly, you are assuming they've hashed the password, some (even large companies) don't they use a symmetric algorithm. If a company can send your password to you, say via e-mail, they are using a symmetric algorithm (at best).This is insecure. The idea is the hashing is one way, so the hash cannot be reversed, so password123 ---> 7FDEADBEEF or whatever. It the password table is stolen there are two immediate vulnerabilities. First off, if the system allows a bad password such as "password" this is going to be the most common value stored in the password field across the table, and you can work backwards through the most probable ones. The second vulnerability is something called a rainbow table, this reduces the amount of time it takes to reverse engineer a password that is going to lead to a particular hash. Worse, these tables are readily available, so you don't need the compuation time to get started. You can salt the password (adding a random bit of text which you store) in various ways, e.g. add then hash or has the password, salt then hash the result. This mitigates against the vunerabilities described above, but given enough time brute force strategies will always win - even if enough time means from now until after the end of the universe.
KeithBarrow.net[^] - It might not be very good, but at least it is free!
-
What he suggests is that the password is transformed again before being hashed, using an algorithm proper to the website. I still fail to see why this is not clever (and it is probably not, otherwise they would all do it. Or maybe they all do it already and nobody knows ?).
-
What he suggests is that the password is transformed again before being hashed, using an algorithm proper to the website. I still fail to see why this is not clever (and it is probably not, otherwise they would all do it. Or maybe they all do it already and nobody knows ?).
Because it wouldn't prevent the commonest way to bypass hashes: look for identical values. Even if you reverse every password before you hash it, every user that uses "password" gets the same hash value. Salting uses different values for each user - the username or row id value for example - and so every user gets a different hash value even if they share a password.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
-
What he suggests is that the password is transformed again before being hashed, using an algorithm proper to the website. I still fail to see why this is not clever (and it is probably not, otherwise they would all do it. Or maybe they all do it already and nobody knows ?).
"Clever" is never secure, because the security vanish the moment someone figure it out. And if attacker could get their hands on the DB then they also could get the application (possibly even source code). So as other said slow(!) salted hashes are secure because it doesn't matter that you know how to create the hash. The way back is expensive. If the "secret way" would be enough then everyone will just XOR the password with something "secret", right?
-- "My software never has bugs. It just develops random features."
-
Do we get extra points when understanding the reference here ? Or minus points for those who don't ?
Minus points for those that don't read XKCD regularly. ;)
