[mercurial]

Somebody is trying to outshine Mt. Gox in terms of amateurism. I wouldn't be surprised to find a number of other vulnerabilities (SQL injection ?). Who the hell thinks it's OK to store non-encrypted passwords in this day and age? It's not like you don't have a major security breach every month...

Also, I like the 'handler.php' endpoint returning some kind of ugly pseudo-SOAP. Ugh.

[scoot]

"Who the hell thinks it's OK to store non-encrypted passwords in this day and age?" You'd be surprised: http://plaintextoffenders.com/

...and an amazing number of finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash.

[stevetjoa]

I was a reviewer for a Springer journal (MMIR). I contacted Springer in October 2012 to let them know that they store plaintext passwords and share the plaintext passwords with their users (e.g. "Hey, it's review season again. Please login to accept or decline your review assignments. By the way, if you don't remember your password, here it is! abc12345"). Over a brief email exchange, I carefully, politely, and concisely laid out the problems with doing so. All I got was a hilariously dismissive reply.

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.

[martypitt]

I was astonished to discover about 18mths ago that MelbourneIT, Australia's largest Domain Registrar stores their users passwords in plain text, and display them to the customer service reps during calls.

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

[mschuster91]

Or they want to avoid the problems that can arise with multiple systems having to authenticate at the system - some of which might use non-exchangeable ways of encoding stuff like Umlauts.

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.

[mschuster91]

Self-reply, as the edit window is out of order: don't forget mobile devices (the support of software IMEs for anything outside the alphanumeric range is spotty to say the best), and as you're talking about financial institutions, also think about ATMs and PoS terminals where the only thing you have worldwide available is a 0-9 keyboard.

[m_darkTemplar]

Many of these are the sites sending users generated passwords which doesn't necessarily indicate that the passwords are stored in the database as plain text. It's reasonable that the passwords are generated, the email is sent with the password, then the password is hashed and stored in the database, and the plain text version deleted.

[jcromartie]

> finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash

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.

[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.

[minimaxir]

Non-encrypted passwords are an artifact of legacy systems, and some modern businesses believe that the risk of plain-text passwords being leaked is lower than the risk of systems breaking due to updating passwords/authentication to an encrypted schema.

Some modern businesses don't make the best decisions.

[wldlyinaccurate]

No, non-encrypted passwords are an artefact of poor design and incompetent programmers. Cryptographic hashing has been around since the 70's, and cryptography itself pre-dates history.

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.

[mercurial]

> Non-encrypted passwords are an artifact of legacy systems

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.

[vrybas1]

↑ This!

[SideburnsOfDoom]

I am surprised that this is the only comment mentioning SOAP.

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.