Re:Google Just Admitted Storing Passwords as Plain Text for ...
by x38iq84n on Thursday May 23, 2019 @04:50AM
(#19989759)
Unbelievable.
Now it's Google, last time it was Fb, we are talking about the richest companies ever in existence. Why is it so hard to have internal pen testers who would discover such fk-ups as storing passwords in plain text? These companies need internal teams actively challenging the security of their products and services - something they don't seem to be doing now, or maybe they do but are not very good at it.
Re:Google Just Admitted Storing Passwords as Plain Text for ...
by bristleworm on Thursday May 23, 2019 @05:58AM
(#19990177)
You know what I don't get? I simply can't understand why, at any point of development, passwords would be stored in plain text in the first place. I mean, there is no good reason to do this.
Re:Google Just Admitted Storing Passwords as Plain Text for ...
by ColinWright on Thursday May 23, 2019 @06:40AM
(#19990408)
There is.
The output of cryptographic functions is, by its very nature, random-looking and effectively untestable. To have a flag that allows you to replace the hashing with a "pass through" function is valuable for the purpose of ensuring that your code is doing the right thing.
A fundamental principle of cryptography is that it's nearly impossible to tell if a hashing function is working properly - it's output is intended to "look random."
When I develop systems like this I always have a flag that gets used everywhere I mock a cryptographic function, and that flag also turns on a HUGE BANNER in the output. It might not be impossible, but it's very, very difficult for the non-secure version to get deployed.
The situation is more nuanced than that, but there definitely is a reason to have this kind of insecure code in existence. The trick is making sure it's effectively impossible for it to go live.
Re:Google Just Admitted Storing Passwords as Plain Text for ...
by ColinWright on Thursday May 23, 2019 @05:24AM
(#19989981)
The second paragraph:
> Rather than "hashing" passwords -- basically replacing the text with a string of seemingly random letters that can only be deciphered with a code -- Google says ...
No. The hashed password can never be "deciphered". That's part of the point of using a cryptographic hash.
Am I alone that I find basic errors like this really annoying?
Now it's Google, last time it was Fb, we are talking about the richest companies ever in existence. Why is it so hard to have internal pen testers who would discover such fk-ups as storing passwords in plain text? These companies need internal teams actively challenging the security of their products and services - something they don't seem to be doing now, or maybe they do but are not very good at it.
The output of cryptographic functions is, by its very nature, random-looking and effectively untestable. To have a flag that allows you to replace the hashing with a "pass through" function is valuable for the purpose of ensuring that your code is doing the right thing.
A fundamental principle of cryptography is that it's nearly impossible to tell if a hashing function is working properly - it's output is intended to "look random."
When I develop systems like this I always have a flag that gets used everywhere I mock a cryptographic function, and that flag also turns on a HUGE BANNER in the output. It might not be impossible, but it's very, very difficult for the non-secure version to get deployed.
The situation is more nuanced than that, but there definitely is a reason to have this kind of insecure code in existence. The trick is making sure it's effectively impossible for it to go live.
> Rather than "hashing" passwords -- basically replacing the text with a string of seemingly random letters that can only be deciphered with a code -- Google says ...
No. The hashed password can never be "deciphered". That's part of the point of using a cryptographic hash.
Am I alone that I find basic errors like this really annoying?