[leobelle]

> Who the hell thinks it's OK to store non-encrypted passwords in this day and age?

The post gave no indication how Cricketer was storing the passwords. They may very well be stored encrypted.

You can send plain text passwords back if you've encrypted them, you just have to decrypt them first. There's no point at all in returning the results of encrypting a password if the clients don't know how to decrypt those results. Given that the API uses plain text HTTP, I doubt that the passwords are encrypted.

What the passwords are not stored as however, are hashes. A hash is not the same as text that was encrypted. A hash is a difficult to reverse unique identifier for bit of text.

Having said all this, it is funny to see your post, and all its replies making fun of security incompetency while also being incompetent in themselves.

[eru]

> You can send plain text passwords back if you've encrypted them, you just have to decrypt them first.

Yes, and security-wise that's just a slightly obfuscated version of plain text.

[leobelle]

That's not true at all. If you use secure encryption to store plain text, and proper use of HTTPs to transfer said text, that's secure. It's not as bad as obfuscated text. What you've said is just plain untrue.

One problem with storing passwords is that there is no good reason to. The other security issue is that people reuse passwords. So everyone should be creating hashes instead of encrypting passwords, but encrypting text, and transmitting it securely is still secure. This API didn't do that, it did a lot of things wrong, but these comments are all pretty ignorant as well.

It's just one inane comment after another in this thread.

[peq]

It is secure against man in the middle attacks, but still if the password database is leaked, then the pain text passwords are most likely also leaked and you have to tell your users to change their password everywhere where they have used the same or a similar password.