
30% of Sites Store Plain Text Passwords - nreece
http://www.readwriteweb.com/archives/rockyou_hacker_30_of_sites_store_plain_text_passwords.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+readwriteweb+%28ReadWriteWeb%29
======
ryanwaggoner
Correction: some anonymous internet guy who claims that he's behind the
RockYou hack _and_ has hacked many major US sites says that 1 in 3 that he has
accessed stores passwords in plain text. So this "data" is pretty much
worthless.

------
tptacek
_For websites, the hacker recommends using hashes with salt or PCI DSS to
protect user data. He said that message-digest algorithm-5 (MD5) is an
inadequate solution. As a case in point, check out this post we saw today on
Slashdot. "If you're storing it in MD5, it's nothing... It's no problem to use
a GPU cracker, or better, a botnet of PS3s. I've got three at home."_

Uh huh.

~~~
nikcub
and all of that is even more useless if your session token is short/weak/easy
to guess

~~~
tptacek
If you even have to think about what your session token is, you've done things
dramatically wrong.

------
jchonphoenix
Its ridiculous that so many sites do this. Especially since it takes all of 2
seconds to activate a salting + hashing function in current web frameworks of
today...and if you're not on a framework, it takes all of 30 seconds to write
your own salting + hashing function or find one on the internet...

~~~
aditya
Yeah - it totally sounds ridiculous, which is why I don't buy it. Something
fishy is going on >:)

~~~
hackoder
Its not all that ridiculous. A company that I used to work for did this. And
while anecdote != data, I've seen it happen often enough to realize that a lot
of devs just dont care about security.

------
pp
When I worked at a large company, their reason for storing passwords (to an
online ordering system; for some 1.5 million clients) as plain text was the
ability to impersonate users when debugging their problems. Then, after a
while, even that became too hard for them so they added a special backdoor: on
the live system, you could go to a special page (it was not linked from
anywhere, but it was conveniently named Login.aspx) and enter the user ID and
a shared password that worked for all users. I'm still amazed why this had
never been taken advantage of while I was there.

~~~
MartinCron
If it's properly secured and leaves an audit trail (sounds like yours wasn't)
an "impersonate user" feature is pretty much a must have for debugging
problems on any site has content or behavior that varies per-user.

I worked at a company that had properly encrypted passwords, but the customer
support people would just ask the user for their username/password and login
through the front door. Once I found out about that, I implemented a simple
yet secured impersonate system and it has served us very well.

~~~
dangrossman
I agree, it's an extremely useful feature to have.

The way I set it up is that the user must first log in to an administrator-
level account before they can impersonate another user by entering a username
or ID.

------
ThePinion
I dunno. I wouldn't call myself a very advanced developer, but all my sites
are pretty decently hashed, Salt included... It's amazing that Rock You was
just seemingly really lazy (or stupid)

------
randomwalker
This is something I started with a couple of other people in response to the
RockYou incident: <http://blockyou.org/>

The overall goal is a "community documentation of bad web authentication
practices," but at a minimum it would be great to compile a list of websites
that send out plaintext passwords when a user forgets their password. Anyone
interested?

~~~
hamiltonianian
Byethost (a personal shared-hosting provider) did this to me. I'm posting this
under a different account because, unless I can find a better free shared-LAMP
host, I'm still with them :(

------
paulgb
The article doesn't mention the 30% figure anywhere (except the title) _[edit:
I was wrong]_ , which makes me wonder where it came from. Is it the hacker's
experience, or is he quoting someone else? If it's the former, issues of small
sample size and selection bias come to mind.

~~~
samdk
From the article: _Tom says that one out of every three sites he's gained
access to store user data in plain text databases._

~~~
paulgb
Oh, I must have missed that bit. Thanks.

------
forkqueue
Or rather, 30% of sites which already have some other security issue also
store passwords in plain text.

Frankly, I'm surprised the percentage isn't higher if the sites are badly
maintained enough to let this guy in through another exploit.

------
bengtan
Another data point:

Doesn't mailman email out monthly reminders of passwords, with passwords in
plain text? I know you can opt out of the reminders, but it's default
behaviour.

------
mortehu
Seems reasonable to me. Some sites have a "recover password" function, and I
wouldn't be surprised if they accounted for more than 30%.

~~~
dotBen
This is actually the best and only real way of knowing a site you just signed
up to is storing passwords in the clear:

1) Create account with "throw-away" password

2) Invoke "recover password" functionality

3) Check email to see if they send you your password in the mail (doh), or if
they ask you to log in to create new one (yay)

~~~
sev
Unfortunately that's not a way of 'knowing' a site stores passwords in the
clear or not. They can send you a new password and _still_ store them in
plaintext.

~~~
dotBen
This is true, I riffed of my first comment too quickly. Thanks for pointing
out.

It's still a _good_ indicator, and if you do get back that throw-away password
then you know to be extra careful/give the site a miss.

~~~
JoachimSchipper
Using a different, decent password for each site is a good idea anyway.

This doesn't apply to, say, the New York Times, of course; but accounts that
you care about should have decent passwords.

------
oscardelben
That's a good reason to use different password for different websites. With
password manager softwares this is easy to do.

------
joshu
"a botnet of PS3s"

