Hey guys, I'm @omervk, one of the co-founders and the maintainer of PTO. Always a pleasure to be featured on the front page of HN.
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. :)
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!
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.
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.
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
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.
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.
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.
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).
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? :-(
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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
If you are changing the password/registering, the password is in plaintext in the memory on the server anyway; it just has to be. So they can just mail it to you.
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.
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.
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.
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.
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?
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?)
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. :)