Passwords in plain text(plaintextoffenders.com)
plaintextoffenders.com
Passwords in plain text
http://plaintextoffenders.com/
115 comments
Hi, I'm @hmemcpy, @omervk's partner in crim^H^H^Hplaintextoffending :)
One of Such Volunteers (wow!) made a Chrome Extension that scrapes addresses from PTO and shows you a red banner if you're on a site that's featured PTO!
https://chrome.google.com/webstore/detail/plain-text-offende...
One of Such Volunteers (wow!) made a Chrome Extension that scrapes addresses from PTO and shows you a red banner if you're on a site that's featured PTO!
https://chrome.google.com/webstore/detail/plain-text-offende...
Apparently the list of offending sites is hardcoded in the extension ( https://github.com/klinskyc/PTOAlert/blob/master/sites.json ) and the extension is not updated to reflect changes on the sites.
I suppose the only downside is the list of reformed sites using improved password security appears to rely on user verification and submission, so the list may not always be up to date - but it's certainly better than not knowing at all. Kudos to the extension maker.
Cool stuff. I was working on a similar site for a while which would give stars to site depending on their various security practices:
- HTTPS, HSTS support
- Password hashing (and type of hashing if available)
- Third party auth support (OpenID/Persona)
- 2FA
- ...
Is this something you would like to go towards? I would love to help (depending on the backend of the site, I may offer technical help too)
- HTTPS, HSTS support
- Password hashing (and type of hashing if available)
- Third party auth support (OpenID/Persona)
- 2FA
- ...
Is this something you would like to go towards? I would love to help (depending on the backend of the site, I may offer technical help too)
Great stuff, although it would be nice to have the list of sites in a more usable format - browsing through individual blog posts looking for a domain isn't particularly efficient.
Have you thought about reporting on other aspects of password security, such as misguided length limits or character requirements?
Edit: sorry, I guess you've just about covered my first point.
Have you thought about reporting on other aspects of password security, such as misguided length limits or character requirements?
Edit: sorry, I guess you've just about covered my first point.
We've covered length limits before (and entered it into our mandate), since those limits are many times created by placing the password into a fixed-width field in the database.
One more very important thing that I neglected to mention is how you can help:
- Submit offenders - Spread the word (we're also on Facebook and Twitter (@plntxtoffenders) - Contact offending sites and let them know they're on the list
- Submit offenders - Spread the word (we're also on Facebook and Twitter (@plntxtoffenders) - Contact offending sites and let them know they're on the list
For good measure you should list websites allowing you to enter a password on a non-https page, too. That's plain text, too.
Not necessarily. The login page could be http, but as long as it posts to an https address, the password is never transmitted in plain text.
If your login page is HTTP, your HTTPS receiver is useless. A MITM can just change the form's target URL in the HTTP login page. On inject any scripts.
We have a few of those :)
A couple of simple client-server type graphics would do a lot in explaining why this is an issue to the layman.
That sounds lovely! Can you help us either in making it or recommending someone who might be able to?
You are also listing websites that send you your password when registering or changing password.
I am not sure that's appropriate. I know systems that send you the mail with your password after registration/password change and then save the passwords to database hashed.
You cannot deduce that they save passwords in plaintext because they send you the password after registration/password reset.
Example: http://plaintextoffenders.com/image/89463394135
I am not sure that's appropriate. I know systems that send you the mail with your password after registration/password change and then save the passwords to database hashed.
You cannot deduce that they save passwords in plaintext because they send you the password after registration/password reset.
Example: http://plaintextoffenders.com/image/89463394135
Yes, this is also explained in a link from our About page here: http://plaintextoffenders.com/post/7006690494/whats-so-wrong...
TL;DR - it's still a security issue (albeit smaller), we've included it in our mandate, please don't do it.
TL;DR - it's still a security issue (albeit smaller), we've included it in our mandate, please don't do it.
[deleted]
> If someone were to hack into any mail account, all they need to do is search for ‘password’ and they have all of the user’s passwords.
Only if you're dumb enough to not delete any password emails.
Granted, preferable any site sending you your password in an email should either send a reset link or "your password is 'red*'"
Only if you're dumb enough to not delete any password emails.
Granted, preferable any site sending you your password in an email should either send a reset link or "your password is 'red*'"
Only if you're dumb enough to not delete any password emails.
You delete it from your MUA, but how can you be sure that it wasn't stored in any of the intermediate servers?
You delete it from your MUA, but how can you be sure that it wasn't stored in any of the intermediate servers?
The natural assumption is that the hacker has got your password, not hacked gmail or hotmail, etc.
The case where you get your new password by mail when you just changed it does not necessarily mean it is stored in plain text. They could keep it around in memory just long enough to send it by mail.
Doesn't mean it is a good idea though.
Doesn't mean it is a good idea though.
Even if it's not stored at their end in plaintext it's a security issue that it's emailed in plaintext.
There was an article on HN in the last week (or so) claiming that both inbound and outbound encryption of email was happening.
http://readwrite.com/2014/06/06/google-gmail-encryption-fail...
Correct me if I'm wrong but wouldn't this mean that only the email stored on the recipient's email provider's server was then unencrypted.
Correct me if I'm wrong but wouldn't this mean that only the email stored on the recipient's email provider's server was then unencrypted.
Unfortunately, STARTTLS is subject to service degradation attacks and it is very common for email servers to use unsigned keys. Simply enabling STARTTLS protects against passive attacks, but until email servers refuse connections that do not create a TLS session with proper certs, email will remain subject to MITM attacks. Meanwhile, this failure mode is a usability problem for email. My experience with notifying companies about insecure email practices has been extremely disappointing, even among those that should know better (like national labs and financial institutions).
It happens, but way too little.
[deleted]
[deleted]
There are some ways to do that sort of thing safely, for some value of 'safe', but they're non-trivial. Sticking the plaintext passwords in a database row is trivial. Which do you think is more common? :-(
That's really trivial, and many web applications work this way:
email = input.email
plainPassword = input.password
hashed = hash(plainPassword)
saveToDb(email, hashed)
sendGreetingEmail(email, plainPassword)
It's not the same but there are other security issues. The server to server transfer of the email message might not be encrypted (it might be if both have TLS extensions enabled). So, emailing plain text passwords is always a bad idea even if it's not stored as such.
I agree that from a security standpoint it's better not to send the password in plain text at all.
But then you can start listing non-HTTPS sites, too. You disclose your password in plaintext to many servers every time you login on those.
But then you can start listing non-HTTPS sites, too. You disclose your password in plaintext to many servers every time you login on those.
Those should be listed too. I'm not sure I follow your point: Because there exists this other really bad but common practice, why are we harping on this bad practice?
Being overly concerned about having your email sniffed as its passed along internet peer is just misplaced anxiety. Anyone who can successfully sniff your password from your email in transit can already own if they chose to. The convenience factor of having your password emailed and having a record of it in many cases trumps this concern.
"But what if someone hacks your email, they know all your passwords!"
What if someone hacks your 1password account? It's the same exact scenario. Having a single point of failure that one can be extra vigilant with guarding is much better than the alternative of having a hundred unique passwords one must remember.
"But what if someone hacks your email, they know all your passwords!"
What if someone hacks your 1password account? It's the same exact scenario. Having a single point of failure that one can be extra vigilant with guarding is much better than the alternative of having a hundred unique passwords one must remember.
Re: your 1password vs email point, while they might both be single points of failure, in practice one's email is usually more vulnerable. Boyfriends, girlfriends, friends, etc, have occasional or accidental access to email for whatever reason (Bosco!). Especially on a smartphone. This kind of thing is much less likely, though of course still possible, for password managers. I don't know about 1password in particular, but the one I use has a 15 minute of inactivity (or upon sleep) timeout before the master pw is required again. The iPhone version requires a pin any time it loses and regains focus. And you can customize the settings to alleviate pretty much any level of paranoia.
My point is that if you feel that the email practice should be listed for the reason that it sends passwords in clear text over the network, then the equally bad practice of sending password over plain HTTP should be listed too.
Having the user send their password over a non-SSL connection when they choose it in the very first place is also less-than-perfect security. Having the user ever type in their full exact password is less-than perfect, because of key-loggers; when asked to choose a password the very first time, the system should ask how long it is, then ask for random characters from it until the whole thing has been supplied.
OR, we should just accept that there's a whole magnitude of difference between sending a password by email on a single occasion, and storing it in plain-text, and focus on the latter problem first.
OR, we should just accept that there's a whole magnitude of difference between sending a password by email on a single occasion, and storing it in plain-text, and focus on the latter problem first.
> Having the user send their password over a non-SSL connection when they choose it in the very first place is also less-than-perfect security.
Who does that? That's even worse than storing it in plain text on the backend.
Who does that? That's even worse than storing it in plain text on the backend.
The first site [1] on the blog in question, for example.
[1] http://www.assosfactoryoutlet.com/customer/account/create/
[1] http://www.assosfactoryoutlet.com/customer/account/create/
But that has nothing to do with the fact that just because the site emails you a password doesn't mean that they store the password in plaintext. The catch here is that if they email the password upon the user having entered it (made an account or changed their password, or had password generated for them, ...). If user requests a lost password and it's returned in plaintext, then one can be sure that the password isn't being stored in proper way.
HN does this too, by the way. If you request a new password for an account, it's being sent in plaintext. No problem here, what comes to storing it.
HN does this too, by the way. If you request a new password for an account, it's being sent in plaintext. No problem here, what comes to storing it.
No problem here? It goes through so many servers, unencrypted…
It's no problem, as long as it's a one-time-only password and has a limited lifetime (ideally only a day or so). It's similar to a password reset URL, which is also a password equivalent, but only usable once.
At least it's better than asking for your mother's maiden name.
At least it's better than asking for your mother's maiden name.
[deleted]
How many servers does it go through? Mail in the real world, today, is virtually always source server -> destination MX server. There was once a fanciful era when occasionally offline servers passed off to various smarthosts, and this was the big fear about email, but that is no longer the case.
HN passwords are not high security. If we lose an HN account, not only can it be easily restored by an admin, it's really not a huge loss - start again. There doesn't need to be extreme practices.
Oh, you use the same password across sites? (which is the source of 99% of password security concerns). That is crazy, and you shouldn't do that. That's on you. (You being the conceptual person up in arms)
HN passwords are not high security. If we lose an HN account, not only can it be easily restored by an admin, it's really not a huge loss - start again. There doesn't need to be extreme practices.
Oh, you use the same password across sites? (which is the source of 99% of password security concerns). That is crazy, and you shouldn't do that. That's on you. (You being the conceptual person up in arms)
Well, what would you do with an encrypted password sent to you by email?
How do you propose to solve this? Using password reset links instead changes very little.
> Using password reset links instead changes very little.
Actually it changes a lot. Password reset links are one time only, and they get sent before you change your password. Mailing your password in plaintext after you've just changed it means it's good even if someone gets a hold of it months or years later. That's significantly worse.
Actually it changes a lot. Password reset links are one time only, and they get sent before you change your password. Mailing your password in plaintext after you've just changed it means it's good even if someone gets a hold of it months or years later. That's significantly worse.
Odds are that you registered over plain HTTP anyway
There's a fairly trivial way to do it in Django I think (whether it's still safe to send an email with pw in plaintext is still questionable at best):
Say a user forgot their password and they click some link to reset their password:
Generate the password text, then create an email with that password, send the email, and then store the password, connected to the User object, in the default Django way, which is SHA'd.
Say a user forgot their password and they click some link to reset their password:
Generate the password text, then create an email with that password, send the email, and then store the password, connected to the User object, in the default Django way, which is SHA'd.
The Django builtin functionality is more secure than that. Do not send passwords in email.
You should create a token, and mark the account with it, send the token to the user, and if the user sends the token back to you (at the URL, normally), you let him replace his password. The password itself is never communicated back to the user.
You should create a token, and mark the account with it, send the token to the user, and if the user sends the token back to you (at the URL, normally), you let him replace his password. The password itself is never communicated back to the user.
And be sure to destroy the token immediately after the user resets, and also after a reasonable time period regardless if it was used (24hrs seems fine to me).
Otherwise the email could be found later and used to gain access.
Otherwise the email could be found later and used to gain access.
I wasn't suggesting to do this and I have never done this, just pointing out that it is technically easy. I don't really know why I got a downvote for that
Just a point, this is pretty much the same as sending a plain text one use password.
Scrape all the URLs from that website. Then write a browser extension that looks up the current tab's URL and turns red if it matches one of those domains. Use PRs to manage addition/subtraction of offenders to the list. Now even grandma knows when a website doesn't save your password safely and shaming them will have more impact.
There's already a Chrome Extension for it if I'm not mistaken.
Can you share the name or link please?
From a comment further down https://chrome.google.com/webstore/detail/plain-text-offende...
I wrote something similar a few months back https://github.com/MikeRogers0/justdelete.me-chrome-extensio... for Just Delete Me, though they offered a nice JSON file for me to use.
A lot of talk of passwording concentrates on threats at the technology end, and they ignore threats at the user end.
Emailed Passwords are a failure from a tech point of view, but they allow users to create more complex passwords without punishing them when they forget that password.
As it is, I have situations now when the complexity requirements of a password combined with the fact that I need to sign in to a separate mobile App and I'm given no way of seeing what the password was when I created it that I just throw my metaphorical hands in the air, and reset it to generic password "Green!12Letmein." on yet another account.
This is wrong of me. I know it's wrong, I'm aware of password remembering services and I'm technical but I still do it.
If I'm doing this, and you're doing this, then most of the world is doing it. By discounting passwords sent through email, then we may be making overall security worse instead of better.
Emailed Passwords are a failure from a tech point of view, but they allow users to create more complex passwords without punishing them when they forget that password.
As it is, I have situations now when the complexity requirements of a password combined with the fact that I need to sign in to a separate mobile App and I'm given no way of seeing what the password was when I created it that I just throw my metaphorical hands in the air, and reset it to generic password "Green!12Letmein." on yet another account.
This is wrong of me. I know it's wrong, I'm aware of password remembering services and I'm technical but I still do it.
If I'm doing this, and you're doing this, then most of the world is doing it. By discounting passwords sent through email, then we may be making overall security worse instead of better.
There's no point in using a secure password if it's stored in plaintext. Brute-force attacks on passwords usually need to be done offline in order to be effective (unless the site happens to not throttle authentication queries), so essentially as long as your password isn't one of the attackers' first 100-1000 guesses (being extremely charitable here), then it doesn't matter if your password is 15 characters or 150 characters, because the primary attack vector (database compromise) will reveal it instantly.
Additionally, allowing passwords to be e-mailed is even worse than this, because there's a good chance the password is not encrypted in transit, which means that it can be intercepted on the way to your mailbox. In that case, the attacker doesn't even need to compromise the database to get your password, no matter how complex it is. Storing passwords in plaintext removes security even if it makes people use less complicated passwords.
Additionally, allowing passwords to be e-mailed is even worse than this, because there's a good chance the password is not encrypted in transit, which means that it can be intercepted on the way to your mailbox. In that case, the attacker doesn't even need to compromise the database to get your password, no matter how complex it is. Storing passwords in plaintext removes security even if it makes people use less complicated passwords.
1Password has mobile apps so you can copy and paste passwords on mobile (pretty rare, since most services will remember you). Once you start using it you get really used to it and you won't go back. You just have to force yourself those first few days.
As far as I can remember HN also ( not a long time ago ) was giving plain text passwords. I'm glad this was discontinued and proper recovery password email is sent now.
http://i.imgur.com/sDt0DVK.png
http://i.imgur.com/sDt0DVK.png
But how does one handle password resets without resorting in one form or another to sending some info in plain text to users?
At least one website on the current front page is there because it sent a temporary password in plain text. I assume this happened because the user forgot his password. This says nothing about how they store passwords and after all how else would you handle a password reset? Send a password reset link? That's the same thing.
Sending passwords in plaintext back to the user after he has set/changed his password is clearly a security risk but when it comes to temporary passwords or password resets how else would that info be sent?
At least one website on the current front page is there because it sent a temporary password in plain text. I assume this happened because the user forgot his password. This says nothing about how they store passwords and after all how else would you handle a password reset? Send a password reset link? That's the same thing.
Sending passwords in plaintext back to the user after he has set/changed his password is clearly a security risk but when it comes to temporary passwords or password resets how else would that info be sent?
You should be sending a token and/or reset link which will allow the user to choose a new password.
This is much better than just sending a new password because:
* It can have a TTL.
* The user has to change it, they can't just keep using the plaintext one forever.
* You can perform some kind of verification, was the request for a new password sent from the same country/IP/device as the person generating a new password.
This is much better than just sending a new password because:
* It can have a TTL.
* The user has to change it, they can't just keep using the plaintext one forever.
* You can perform some kind of verification, was the request for a new password sent from the same country/IP/device as the person generating a new password.
But can't you implement all three with a temporary password as well? Make the password valid for 24 hours only and when the user logs in with their temporary password perform any kind of extra verification and if that's passed then also force the user to change their password. Seems like the same thing.
The website I noticed on the front page (sunsuper.com.au) was doing precisely this (although their TTL was 90 days which is indeed far too long and it's impossible to tell whether they forced a password reset or simply recommended a password change).
The website I noticed on the front page (sunsuper.com.au) was doing precisely this (although their TTL was 90 days which is indeed far too long and it's impossible to tell whether they forced a password reset or simply recommended a password change).
Yes, but using a token is better for usability and trust since that wont make it possible to lock out other users by clicking the forgot password link, and I as a user will think it is more likely someone doing token based resets has done security correctly.
We already have a fairly good solution to this problem in OAuth. However, current popular implementations of OAuth are third-party owned which is not desirable for many reasons (for example, google won't use facebook owned OAuth, and vice-versa).
Ideally, we should have a self-owned OAuth service implemented by browsers or operating systems. And the APIs of this service should be standardized. Also, the storage should be locally available with remote sync optionally available for backup and cross-device syncing.
Ideally, we should have a self-owned OAuth service implemented by browsers or operating systems. And the APIs of this service should be standardized. Also, the storage should be locally available with remote sync optionally available for backup and cross-device syncing.
Something like the Firefox Accounts¹ project? Which has Oauth2 support² in the works.
1: https://wiki.mozilla.org/Identity/Firefox_Accounts
2: https://github.com/mozilla/fxa-oauth-server
1: https://wiki.mozilla.org/Identity/Firefox_Accounts
2: https://github.com/mozilla/fxa-oauth-server
FxA is primarily for Firefox's own products and services. Mozilla Persona (confusing name - personas is what they called firefox themes as well) is closer.
Yea but there's really no good docs for Persona around anymore, that I can find.
The plan is to use Persona for ones FxA:
> One we get the basics down and enable single sign-on for relying Mozilla Services with your Firefox Account, we hope integrate Firefox Accounts with Persona on the Web and Firefox user agents to make logging in everywhere as painless as it should be.
The plan is to use Persona for ones FxA:
> One we get the basics down and enable single sign-on for relying Mozilla Services with your Firefox Account, we hope integrate Firefox Accounts with Persona on the Web and Firefox user agents to make logging in everywhere as painless as it should be.
I think that was Microsoft Passport. More recently, it's Mozilla Persona. The problem has always been a lack of incentives for websites to implement them, coupled with user indifference.
[Edit]: added comment on Mozilla Persona.
I would disagree. It's common knowledge (backed by many A/B tests) that shorter sign-up forms see less traffic drop. So, if OAuth can replace a number of things (name, email, password, email verification, and so on) by a couple of clicks, I as a website owner will be very happy. Also, when sending interesting emails to inactive users, I see quite a few come back but drop again after a few unsuccessful login attempts. Again, OAuth will help.
The reasons website owners (at least I) don't use facebook or google's OAuth are following:
1. They brand their service too much. The button itself says Login with Facebook/Google. I don't want my users' mind share to be consumed by them. Everything from login/logout to account management happens on pages in the context of their brand. Browser/OS providing this service is much less problematic, and even they should have pluggable services for replacing their default implementations, just like the ability to change the default browser on any OS.
2. They own the data and not the user. I have faced an incident in the past where one of my games was blocked by facebook because they thought it was gambling. I lost 95% of my users in one stroke. It took me two weeks haggling with FB to get my game whitelisted again. Still, the damage was done and we could never fully recover. The data must be owned by the end user and stored in open format so that user can take it freely from one place to another, just like I can take my contacts in vCard format to wherever I like.
3. Any such solution (especially when so heavily branded) will naturally turn other big players hostile. for example, facebook and google will have their own separate implementations instead of having a common one. This will almost ensure that standardization will hot take place. One button each for signup with Facebok/Google/LinkedIn/OpenID/... doesn't make for great UX and it's unnecessary overhead for website owners.
Mozilla persona is a good initiative. Hope they prefer standardization over trying to use it to promote their own browser.
I would disagree. It's common knowledge (backed by many A/B tests) that shorter sign-up forms see less traffic drop. So, if OAuth can replace a number of things (name, email, password, email verification, and so on) by a couple of clicks, I as a website owner will be very happy. Also, when sending interesting emails to inactive users, I see quite a few come back but drop again after a few unsuccessful login attempts. Again, OAuth will help.
The reasons website owners (at least I) don't use facebook or google's OAuth are following:
1. They brand their service too much. The button itself says Login with Facebook/Google. I don't want my users' mind share to be consumed by them. Everything from login/logout to account management happens on pages in the context of their brand. Browser/OS providing this service is much less problematic, and even they should have pluggable services for replacing their default implementations, just like the ability to change the default browser on any OS.
2. They own the data and not the user. I have faced an incident in the past where one of my games was blocked by facebook because they thought it was gambling. I lost 95% of my users in one stroke. It took me two weeks haggling with FB to get my game whitelisted again. Still, the damage was done and we could never fully recover. The data must be owned by the end user and stored in open format so that user can take it freely from one place to another, just like I can take my contacts in vCard format to wherever I like.
3. Any such solution (especially when so heavily branded) will naturally turn other big players hostile. for example, facebook and google will have their own separate implementations instead of having a common one. This will almost ensure that standardization will hot take place. One button each for signup with Facebok/Google/LinkedIn/OpenID/... doesn't make for great UX and it's unnecessary overhead for website owners.
Mozilla persona is a good initiative. Hope they prefer standardization over trying to use it to promote their own browser.
> Mozilla persona is a good initiative. Hope they prefer standardization over trying to use it to promote their own browser.
Well, there's this:
https://groups.google.com/forum/#!topic/mozilla.dev.identity...
Well, there's this:
https://groups.google.com/forum/#!topic/mozilla.dev.identity...
Why are we still doing this? We've known how to do secure authentication without the remote end holding your secret for years via public keys. Everyone here likely does this every day with ssh. There is even a browser mechanism for generating personal certificates for web authentication. The correct long term solution to this ought to be making this solution more intelligible and accessible to users. To hell with passwords and password exchange. They are a huge bug on the internet.
Used a sportsbook a few years ago where the popup to view and update your account details, which had a hidden address bar in most browsers, contained "password=<yourpassword>" in the query string. I reported it but they assured me they were 'using encryption' and to look for the 'lock in my browser'. They were using SSL, but had no clue. The site probably handled millions of $ a week.
I wish websites would actually use client certificate authentication instead of having to play hot potato with secret passwords.
This a thousand times. And ssh keys for servers.
But then, how would you log into e.g. gmail from a cybercoffee in a foreign country? (Assuming you dare do so in spite of the risk of key loggers.)
But then, how would you log into e.g. gmail from a cybercoffee in a foreign country? (Assuming you dare do so in spite of the risk of key loggers.)
> But then, how would you log into e.g. gmail from a cybercoffee in a foreign country? (Assuming you dare do so in spite of the risk of key loggers.)
This still applies with any other authentication schemes...
This still applies with any other authentication schemes...
I say just mailman.
Anyone from Mozilla, EcmaScript, GnuPG and thelike here? Don't miss your monthly "password reminder" mail...
P.S. Just save ONLY a salted hash. Hash functions are designed to be one-way, so no one but you can re-store your password. EVER.
Anyone from Mozilla, EcmaScript, GnuPG and thelike here? Don't miss your monthly "password reminder" mail...
P.S. Just save ONLY a salted hash. Hash functions are designed to be one-way, so no one but you can re-store your password. EVER.
I filed a bug and it was closed waiting for mailman 3 to ship :-/
I've been just thinking about this after receiving 2 such emails in one day this week. Submitted both to the archive, thanks so much for doing this!
Name and shame, that's the minimum to make them change.
Name and shame, that's the minimum to make them change.
The scariest part is that there are 200+ pages of those...
The worst is list running mailman that actually sends monthly password reminder. Is the new GNU mailman still shipped with such reminder feature?
Just use a unique password every time and rest easy.
99.99% of people won't do that. We're trying to make the Internet safer for them.
That makes things better, but it's still not great to have your account compromised on one website because that website stored its passwords in plain text.
Just don't get hacked, easy.
Its a little scary how big that list is.
My concern is that this is a great source of websites with poor security for potential hackers to exploit.
My concern is that this is a great source of websites with poor security for potential hackers to exploit.
usenetbucket.com
Usenet provider
Forgot password asks you to type a password, in which it instantly emails back to you in plaintext.
Doesn't mean it stores it in plaintext.
Usenet provider
Forgot password asks you to type a password, in which it instantly emails back to you in plaintext.
Doesn't mean it stores it in plaintext.
It seems that most of these just send you your password as confirmation (or a temp one after requesting password recovery). Even assuming the best case scenario that these are just password confirmation emails, it still bothers me that my password would now be in my email as plaintext.
Exactly! That's what i thought. Mailing a password to a user on changing it is maybe not the safest, but it does not mean it saves it plaintext to the database. They can just send out an e-mail when updating the password to the database and then never use the plaintext version anymore.
digitalocean.com stored your password in plaintext!!!
I am a Digital Ocean customer and the only password they've ever emailed me is the root password for the server I just bought. Arguably this isn't as safe as AWS' process of making you download a kaypair and only letting you login with that. However, VPS owners should get in the habit of logging on to any server they buy and immediately disabling password auth and root login via SSH, which helps negate the root password being sent over email issue to a certain extent.
How is downloading a key pair generated by someone else safer? If this is only for login purposes (I don't use AWS, so maybe there is another reason), you should generate your own key pair and send them only your public key (which doesn't require an encrypted transfer, BTW). If AWS knows your private key and can view it or provide it to you at anytime, that's no different than storing passwords in plaintext.
AWS generates the key pair client side, and never sees your private key. Also, you can just chose to upload your own public key that AWS will utilize (which is best practice).
AWS cannot view or provide you your private key at any time - once you click 'ok' on that javascript window, that private key is gone for good.
AWS cannot view or provide you your private key at any time - once you click 'ok' on that javascript window, that private key is gone for good.
The keypair AWS generates can only be downloaded once, at the time of instance creation. Beyond that, they expect you to be in possession of the keypair when launching another instance that uses the same keypair. If you happen to lose the file, you're basically out of luck.
So to directly address your concern, you can't download the keypair at any point in time, it's just a one time thing. To me that seems much more secure than emailing out a root password and enabling password authentication by default.
So to directly address your concern, you can't download the keypair at any point in time, it's just a one time thing. To me that seems much more secure than emailing out a root password and enabling password authentication by default.
I much prefer DigitalOcean's option of no root password and letting me upload my public key. There's no need for them ever to know my password or private key.
… or even better: Disable password authentication entirely.
It does not seem safe or anything...
Should really start doing this for sites using MD5/SHA1 for password hashing too, as using them is barely above plain text in terms of security these days.
How would one gather that information? What form of evidence would you accept?
We'd like to refrain from asking people to hack into sites just to figure out their hashing scheme :)
We'd like to refrain from asking people to hack into sites just to figure out their hashing scheme :)
It is harder than with plain text, yes, but it can show through at times. For example, a while back I was looking through my profile settings on a forum I have an account on, and saw a "check password security" link on it. Out of curiosity, I clicked it, and was greeted with "if a Google search for [unsalted MD5 hash of your password] returns results, your password is not secure." I reported it to the site and turns out it was a leftover from their old system, and it got removed shortly after (along with the MD5 password hashes).
You could also always ask too. I was reading through the forums of another site and stumbled upon a thread of someone asking HTTPS support for the site. The staff was pretty reluctant about the idea, which made me wonder about other security concerns. Looking around a bit, I noticed that the site cookies contain a "pass" value that looks very much like an MD5 hash. I got someone who used to be staff to ask the current staff how passwords are hashed, and the answer was "salted MD5".
Also, why is my initial post getting downvoted? Generic hashing algorithms are built for speed, which is bad for passwords. Key derivation functions exist for a reason. Hell, just a while back there was a user database leak from a site called MangaTraders, and they used unsalted MD5 for password hashing. It didn't take long before the vast majority of passwords had been cracked.
You could also always ask too. I was reading through the forums of another site and stumbled upon a thread of someone asking HTTPS support for the site. The staff was pretty reluctant about the idea, which made me wonder about other security concerns. Looking around a bit, I noticed that the site cookies contain a "pass" value that looks very much like an MD5 hash. I got someone who used to be staff to ask the current staff how passwords are hashed, and the answer was "salted MD5".
Also, why is my initial post getting downvoted? Generic hashing algorithms are built for speed, which is bad for passwords. Key derivation functions exist for a reason. Hell, just a while back there was a user database leak from a site called MangaTraders, and they used unsalted MD5 for password hashing. It didn't take long before the vast majority of passwords had been cracked.
If anyone can gather this sort of information, we'll gladly publish it :)
> as using them is barely above plain text in terms of security these days
How so?
How so?
Cracking them is so fast these days that they don't offer much in terms of security. For example, take a look at this post:
http://www.troyhunt.com/2012/06/our-password-hashing-has-no-...
Then note that it was posted two years ago. GPUs surely haven't gotten any slower since then.
http://www.troyhunt.com/2012/06/our-password-hashing-has-no-...
Then note that it was posted two years ago. GPUs surely haven't gotten any slower since then.
Same applies to all hash functions. It's how you implement it that counts.
If I recall right, those functions are too fast. It is too easy to iterate through all kinds of possible passwords and you are likely to find plenty of matches.
At minimum, you need to add unique salt to each password. It forces the attacker to run dictionary on each account separately. It is also recommended to use different slower hash function or iterate MD5/SHA1 thousands times, so he will be much slower.
At minimum, you need to add unique salt to each password. It forces the attacker to run dictionary on each account separately. It is also recommended to use different slower hash function or iterate MD5/SHA1 thousands times, so he will be much slower.
Try to avoid directly invoking "SHA256" in your own security-related code.
good: http://en.wikipedia.org/wiki/PBKDF2
gooder: http://en.wikipedia.org/wiki/Scrypt
Maybe avoid using SHA256 with them because of Bitcoin ASICs. If your passwords get leaked in hashed form, even with these, you'll still want to tell your users and advise/force them to change their passwords. Forcing makes more sense if you have 2FA to something not likely to be accessible with their previous password (SMS maybe?)
good: http://en.wikipedia.org/wiki/PBKDF2
gooder: http://en.wikipedia.org/wiki/Scrypt
Maybe avoid using SHA256 with them because of Bitcoin ASICs. If your passwords get leaked in hashed form, even with these, you'll still want to tell your users and advise/force them to change their passwords. Forcing makes more sense if you have 2FA to something not likely to be accessible with their previous password (SMS maybe?)
See hashcat. :) It is easy to crack those types of hashes these days. Or even just search for the hash in google.
Same applies to all types of hashes. Implementation counts more than which function you choose.
You're welcome to ask me questions, though we've covered most on our about page (http://plaintextoffenders.com/about). The one we haven't is usually "Is there an API/better search/new site coming?" to which the answer is that we're both doing this in our spare time and though we really want to create something better to host this very important content, we can't spare the time. If you've got time and want to volunteer to create this new site, please let me know. :)