19 ms·

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

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.

minimaxir 13y ago
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.
- mercurial 13y ago
  > 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 13y ago
    ↑ This!
- wldlyinaccurate 13y ago
  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.
scoot 13y ago
"Who the hell thinks it's OK to store non-encrypted passwords in this day and age?" You'd be surprised: http://plaintextoffenders.com/ http://plaintextoffenders.com/ ...and an amazing number of finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash.
- mschuster91 13y ago
  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 13y ago
    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.
- stevetjoa 13y ago
  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 13y ago
leobelle 13y ago
> 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 13y ago
  > 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 13y ago
    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 13y ago
      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.
SideburnsOfDoom 13y ago
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.

minimaxir 13y ago

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.

mercurial 13y ago
> 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 13y ago
  ↑ This!
wldlyinaccurate 13y ago
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.

scoot 13y ago

"Who the hell thinks it's OK to store non-encrypted passwords in this day and age?" You'd be surprised: http://plaintextoffenders.com/ http://plaintextoffenders.com/ ...and an amazing number of finance organisations who can't handle non alpha-numeric characters in passwords, indicating failure to hash.

mschuster91 13y ago
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 13y ago
  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.
stevetjoa 13y ago
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 13y ago

leobelle 13y ago

> 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 13y ago
> 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 13y ago
  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 13y ago
    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.

SideburnsOfDoom 13y ago

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.