Also, I like the 'handler.php' endpoint returning some kind of ugly pseudo-SOAP. Ugh.
...and an amazing number of finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash.
In October 2013, I received another email from Springer with my password in plaintext, and they CCed this email to another person!!
I declined my review assignments, asked them to permanently delete my account, and I haven't heard from them since.
I discovered this when on a phone call, the agent asked me what my password was, and when I refused to tell him (but offered any other aspect of my account for identity), it took a lot of convincing to get the rep to serve me. If I were malicious, I could speculate that a little social engineering may have gotten the employee to give me the password.
EDIT : To clarify, it was a comment the rep made about my password indicated that he could see my password in clear text on his screen. I asked him, and he confirmed this.
I tweeted the CTO [1], who advised me they were working on the problem, but it was still several months away from being resolved.
This level of insecurity from a major IT service provider was both shocking, and inexcusable in my humble opinion.
[1] https://twitter.com/marty_pitt/status/223622794490019843
Or they want to avoid the customer service calls "I am in Russia and use a Euro sign in my password, how do I login?!?!?!"/"Help, I have a Macbook from my brother, where is the vertical pipe (|) symbol?" so they restrict the keyspace to azAZ09 for reducing this type of error.
When I see this kind of limitation, I usually assume that they have some old mainframe with a fixed-width 7-bit password field, that would take an enormous engineering effort to change or replace.
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.
Yes, and security-wise that's just a slightly obfuscated version of plain text.
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.
Some modern businesses don't make the best decisions.
There is no excuse --no excuse-- for storing passwords in plain text. Anybody who attempts to justify it deserves a swift thwack in the back of the head.
The copyright is from 2004, that's only 10 years ago. I wouldn't say plaintext passwords were a sensible decision back then.
> Some modern businesses don't make the best decisions.
Some modern businesses don't have the best priorities.
I know that it'a a footnote to the insane brokenness of the rest of it, but ugh indeed. Anyone who remembered SOAP the first time around wouldn't re-invent it badly. Or at all.