Best practices for user account, authorization and password management
cloudplatform.googleblog.com
cloudplatform.googleblog.com
One of these things is not like the others, one of these things just doesn't belong
Don't use SHA3 or any other fast hash for passwords. Use a password hash designed to stymie brute-forcing, like PBKDF2, scrypt, or bcrypt.
So perhaps not as good has the bespoke password hashing functions, but not a disaster waiting to happen either.
> Your service should instead store a cryptographically strong hash of the password that cannot be reversed — created with, for example, PBKDF2, SHA3, Scrypt, or Bcrypt.
Not distinguishing between plain cryptographic hashing and password hashing is a newbie mistake.
> With that in mind, you should allow your users to use literally any characters they wish in their password.
You can't just say this without making sure people understand Unicode normalization, or they're going to get bitten later.
I realize this post is from GCP evangelism, but it's still the "Google" brand, which has a good reputation for security so a lot of people are going to trust it. I wonder if an internal product security person even reviewed it.
I believe in every country with non-Latin alphabet users have two keyboard layouts: local (e.g. Russian) and English/Latin. All major OSes (desktop, tablet or mobile) have install-time defaults like this, and I never ever saw any divergence from this rule, except for removing native layout if it's deemed unnecessary and going English-only, or configuring system to use some third language (e.g. a foreigner setting up a device purchased abroad, changing the defaults). I mean, I never saw anyone in their sane mind removing English layout and keeping only the local.
It is virtually impossible to use computers without having to type in some Latin characters on some occasions, like typing URLs or email addresses. Therefore, I think you may reasonable safely assume capability to enter basic Latin.
However, you should also consider that user may forget to switch the keyboard layout (happens all the time), so if you want to do some password transformations like case-insensitive password matching (due to Caps Lock), and you have significant foreign user base, you may also want to consider common keyboard layouts issues (e.g. "hunter2" <-> "ргтеук2" for QWERTY <-> Russian).
Facebook does this. This is only a single bit compromise, and if there are a lot of users affected, benefits may overweigh the slight security downgrade.
@ademarre's RFC link looks like a good place to look for guidance.
This post is a blatant ad for Firebase Auth. Why isn't there any mention of competing services like Auth0 and okta?
There's also lots of frameworks and libraries which handle everything for you with minimal effort. For example, you could setup something like Apache Shiro [0] as an independent service which you call out to from your app. I've seen a few different alternatives in this space, although I can't remember their names off the top of my head. They're usually written in Java, presumably because getting these features right is important for some enterprises.
You're going to have trouble if you're trying to get support for free services (or cheap consumer services) though. Support ain't cheap, and ads aren't going to pay for that.
FOR YOU
Then if you run into any issues with the third-party provider, you just "disable" the integration and do a normal email-based password reset flow.
You could have the user register by providing an email and clicking a verification link, and then optionally allow em to link third-party services. Regular account access is allowed after authenticating through any available method, but administrative actions require going through the email flow. That way you reduce the risk from a compromised or malicious third-party. Of course, this would assume that email is a good identification authority, which isn't always the case.
You don't need that complex workflow; most third-party authentication services allow you to also request the user's email address during the initial process.
I don't think some of these alleged identity providers should have as much power and trust as they have.
4. Allow multiple identities to link to a single user account
I've tried to search information in google forums to prevent them from putting my email as a recovery without the confirmation and apparently it is not possible.
They create account in instagram, twitter, uber using my email and I need to go to the service to cancel the use of this address. Many times I have account with this address in certain service, but they sign up using a dot between the names and it ends up redirected to my email.
I try to warn them but just ignore them. Since December I received this gigantic amount of requests to change my password, in none of them did I request it.
Out of curiosity, have you considered switching to a new email address? I've done so once in the past in the process of migrating from an @gmail address to an email address on a domain I own, and the process itself was every bit as slow and painful as anyone can imagine, but I feel the end result was totally worth it because now I can freely switch between providers without worrying about going through that process ever again. Just mentioning this because it seems like switching to an email on a custom domain would largely take care of the issue of random people mistakenly using your email as well.
There are a number of benefits to receiving email to a custom domain on a server you admin.
1. Everyone gets a tracking email like somecompany.com@mycustom.tld
2. Targets of spam can be blocked at the server level: somecompany_leaked_my_email.com@mycustom.tld REJECT
3. Leaked emails can be changed using a timestamp somecompany.YYYYMMDD.com@mycustom.tld
4. Blocked recipients map to blocked senders so somecompany_blocked.com@mycustom.tld will be notified they are blocked.
EDIT: formatting
The life got too short. Pine was ok for simple emails, but HTML mails and attachments meant moving to a graphical system. Wanting access to mail on the go meant squirrelmail which was inferior to most web mail. Then along came smart phones and I was having to run imap on my server too.
I suspect nowadays any emails I sent from my anti server would be scored highly for spam flagging too.
In the end I just used gmail. I can count on one hand the number of spams I get each year.
Since 2013 I use macOS Server which simplifies the overhead of running a IMAP mail server.
I also get an array of notices to what I imagine is a late middle age woman in the Midwest. She apparently enters my address believing it is her husbands for important accounts. I get service notices on their cars, billing notices and other account info for her Talbots card, etc. Have tried to contact this couple as well with no luck. I’ve even responded to a couple of non-list senders and asked them to pass on the message for me.
Over the years, I’ve grown less annoyed and more curious about the people causing themselves a privacy nightmare by sending their data to someone with fewer scruples than myself.
The intruiging part of this is they should never have been able to get a GMail address using a variation of my name (say my removing or adding a .) since GMail says they disallow it, but then I just don't get it how so many people have managed to signup to so many services using such an 'impossible' variation of my address? Is there a loophole in GMail or do all these services accept account registrations without email verification?
Either way I'm now seriously considering moving to a different email address and making it something esoteric so no one will think of using it, but that means I'll have to give up on using my name.
Dots are ignored a in gmail address.
johnsmith@gmail.com and john.smith@gmail.com is the same inbox.
I found out only in Dec 2017 when I tried creating a new twitter account. I could reset the password, because I have control over my gmail address. I thought, ban was because email was unverified. So I verified. Even provided a mobile number. Even though, It wouldn't undo the account suspension. I sent support ticket 5+ time, and every time got "Account permanently suspended because of repeated violation of twitter rules".
So unforutnate, ultimately I just created a new gmail/twitter pair.
It's amazing how many banks and financial/medical institutions don't even bother in confirming email addresses given how sensitive the info they handle is.
I don't have a common name, just lucky enough to get a preferred gmail account.
Someone, I don't know, signed up to American Express with my email. I'm getting all their AMEX emails.
When AMEX was contacted, they wanted my SSN and "sell me" their identity protection services (as i remember) and didn't care (?) that their member's statements was going to the wrong person.
I don't even know anyone who has a Diner's card in Italy, or even thought of getting one... It's even less commonly accepted than AmEx and has fewer perks.
I mean, in the olden days of forum software, this sort of thing was removed as a feature for a reason. Because it meant that if left uncontrolled, people could basically destroy discussions and make the site difficult to use by removing vital information from the middle of a conversation or making it hard to track whatever's going on. See for example many old Reddit topics, where you've got a long string of names saying 'deleted' and comments referencing some script that 'removes all posts to protect the user's privacy' or what not.
That's why my ideal solution has always been to basically say 'by signing up with this service, you grant us an unrevocable, unlimited right to use your posts for the purposes of the community' with a nice 30 minute or so editing window set for content. Don't like that? Well that's life I think. You can't take back emails or phone calls and you can't ask people to take your name or information out of a book or magazine once it's been available for years.
Still, maybe I'm old fashioned now.
If a user chooses to put their SSN into an HN post, then that post is now also personal data. Or their address. Or if they write in a post that their parent has a specific kind of cancer.
Unless you can guarantee that no post contains such data, you should assume them to be personal. And no ToS rule "don't post personal data" will protect you.
So you absolutely don't want to do that.
Google handles this by, over the course of a few weeks, even deleting all traces from its backups and caches.
None of those things are going to turn up in a Google search 20 years from now - there's a relatively limited number of people who are going to dig up this information and send it to your employer, or use it to commit crimes against you.
Privacy is not binary, as much as it's nice to think about it that way - something I've only told 2 people I trust is decidedly more private than something I've published to the world, and something I've published online and then removed is more private than something I've left up.
You'd be therefore trading direct communication for archived communication and I'm not sure that's more valuable.
Soooo, HN?
Yeah, no. If someone submits a megabyte-long password, it's not because they like it super strong; it's because they're trying to DoS the server.
A sensible password length limit is probably a few kilobytes.
Case-insensitive comparison is not the same as convert-to-lowercase-and-compare. You should also normalize the input or you're going to set up issues where an account created on one device with one locale will be impossible to log into on another device with another locale.
There is nothing trivial about either "lowercasing" or "case-insensitive compares" in general Unicode strings...
Reading the documentation you link to, the answer in the fine print is that fc() gives you incorrect results for Turkish text.
For the second, one OS, locale, and input method may result in Unicode fully-composed forms, and another in fully-decomposed forms.
Is ø one code point or two? The answer is: it depends on your software environment. If you don't normalize your input, you could have a situation where an account created on, say, Win XP, might be inaccessible for the average user from iOS.
There's actually a pretty good StackOverflow post on dealing with this issue in Python: https://stackoverflow.com/questions/319426/how-do-i-do-a-cas...
This only applies if you handle the normalization in the front-end. But you should normalize it in the back-end, right? Or am I missing something here?
Edit: Answered further down by wongarsu
Designs for an SZ ligature has been part of typesets from the 1910s until the 1950s, but in the opinion of Herrmann (2011), the long-standing alphabetic equivalence of ß with ss and the abolition of the optional capitalization of ß as SZ (abandoned in 1996⁽¹¹⁾) means that this is no longer a valid option that "Germans would want to use on a regular basis".
¹¹ until 1996, it was recommended to render ß as SS in allcaps except when there was ambiguity, in which case it should be rendered as SZ. The common example for such a case was IN MASZEN (in Maßen "in moderate amounts") vs. IN MASSEN (in Massen "in massive amounts"), where the difference between the spelling in ß vs. ss could actually reverse the conveyed meaning.
Also, https://en.wikipedia.org/wiki/%C3%9F contains a concrete example:
That's why modern string APIs ask you which locale to use for case conversion.
We also AES encrypt the emails with the key stored on a network share. It doesn't add a lot of complexity and if an attacker gets hold of the contents of the database, they still don't have this piece of PII. It's by no means a big hurdle against any serious attack but it's nice to have.
How exactly are you sure that the email is encrypted and is read only by the intended receiver and not by anyone else? This is too simplistic as a solution. Things like what to do if a user clicks on the same link more than once also have to be considered (is it really the intended user who clicked it or a malicious actor that the user is not aware of?).
One way this has been prevented for me so far is to include a one time pass in the mail along with the link, but some people might still not have a second device on hand every time they want to log in.
Same way you make sure that the password reset links sent to your email are only received by you and not by anyone else?
I wish every site did this. Especially for non technical users, passwords are such a mental barrier.
Edit: Even if it's an account held on a private server, there must be a password, must there not?
Point is, this advice is probably aimed at developers who aren't working on email systems.
Hallelujah! Finally someone like Google recommends this, so I'm no longer going to be called for crazily overengineering it every time I suggest this...
Pretty please, read points 3 and 4 from this guide and take them into consideration if you're designing any king of reusable auth-library thinggy or a framework. (If you'd also also add entity-role-based permissions so I can say "this account has role X with respect to resource Y, which grants him permissions A, B, C etc." then finally you have the minimal required imho auth/indent/perms system for your framework and I will not have to rip it off and replace it with a custom one every time, or add zillion of patches on top of it...).
http://habitatchronicles.com/2008/10/the-tripartite-identity...
If you allow people to choose their own passwords, the vast majority will reuse them, and their account will eventually be compromised via credential stuffing.
I recognize that this solution will, at least initially, infuriate people. Letting people opt in to federated auth if they prefer that (I hate services that require it) might make it more palatable.
I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.
That's the point.
> you don't know any of your passwords so you cannot even log onto any of your accounts to change them
Nearly every service allows email-based password reset.
> I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.
For most people, their entire identity relies on the security of their email address plus some information they shared on Facebook.
I think this is actually what's happened -- people now know not to leave unlocked devices unattended, so you basically do 2FA every time you unlock your device, so the device can now stay persistently logged into all services.
"Your email provider temporarily rejected our email to you. We will retry in a few minutes. If this happens persistently, please (check our guide for your provider, $MAJOR_PROVIDER|contact your provider) to figure out how to whitelist our login emails"
I would rather have a client side TLS certificate that's generated by the website I'm trying to log into when I create an account with them. You could still keep the username and password application level log in in addition to the certificate to get a second authentication factor.
Also, all passwords appear in plaintext at some point. Even when sitting in a type="password" field that was autofilled by your uber secure password manager.
The main problem is that this solution is just pointlessly bad UX for most sites. But worth it (or something like it) if your users are losing real money.
It could be displayed as selectable/copyable but not visible text by default with a "reveal" button to prevent shoulder surfing.
But for a regular person, you may put them into a deadlock if you generate a secure random 16 character password with 1 chance to remember it.
Just imagine dropping "K@!G-:)XTqqy<44x" in front of a regular user telling them they have 1 shot to store this password before it disappears forever.
Most people who aren't into tech are just going to give up and leave IMO. It took me like 5 minutes to explain case sensitivity to my dad who knows computers well enough to do day trading but calls me up for things like "why can't I login to my email?". Asking him to type in a password like that would probably give him a stroke.
Emailing it to them in plain text is also not a reasonable solution. Not only is it wildly insecure, but you would be surprised at how many people don't know how to copy / paste text.
Maybe call it an access code rather than a password to avoid "don't write down your password" training.
fvtwt gvltv wlbth wgwdh njfnn
If you have clients that run locally (and for which the updates are hopefully signed offline), I do think that approach is sensible.
OTOH maybe requiring client to compute the hash is sometimes too drastic. Sending the password to the server via a properly encrypted channel (https) may be fine, provided that the server never stores it, and just uses it to compute a hash for comparison. Then my original point does not hold.
1. Forcing people to create an account on a service they don't use or trust to access your website. Remember, quite a lot of people despise Facebook and Google, and by forcing them to use those services, you're making them choose between their privacy and your service.
2. Giving said services too much leeway on how the setup works. Do Facebook or Google or Twitter or whoever now charge money to use their account login system? If so, tough luck; you're gonna have to either rework your whole system or pay up.
3. Giving said services too much control in general, and letting them centralise the internet. This is a bad thing for numerous related reasons, ranging from easy access to personal data for tyrants to dependence on a walled garden run by a large corporation).
4. Making them the world's number 1 target for hackers. Admittedly they're already likely this, and homegrown systems have their own security issues in this department, but I certainly don't like the idea that the whole of the internet is basically now compromised the minute a data breach hits Google or what not. Any centralised system is basically a giant bullseye for every bad actor on the planet.
So no, it's not necessarily accurate that no one should try and implement password management or account systems or farm it out to third parties. That's a good way to give whatever controls remains over to large corporations.
Authentication is such a core part of the UX of your product. You should know how it works. If you're factoring out to a black box because you couldn't do it yourself, then I'm not convinced you're any more secure.
If your team is too incompetent to do it correctly (there are so many resources online), then how are they going to do anything else correctly, like ensure I can't access your private messages when I change /<my_id>/messages to /<your_id>/messages in the URL bar, or query the database without sqli?
This "don't do it, it's too hard" meme does nothing but scare people away from core competencies of our profession.
For example if you have multiple social logins, what do you do if the user forgets which account(e.g., google or facebook) they used?
You could just let them login with any as long as the email matches. But then what if you have a social login type that doesn't require verified email? For example let's say you add an imgur login but the user doesn't have an already have an account there. Then an attacker can just create the imgur account with that unverified email and then use that to log into the same email on your site.
There's also a bunch of edge cases with handling users who use different emails for different social accounts so you can't assume one-to-one correspondence between email address and users anymore.
And there's a bunch of other issues with how to initialize a good default display name from these different social profiles. And also the issue with how to handle if they unlink all their social login methods. And how/who to send reset password. And so on and so forth.
In the end this was all too hard and I gave up and only allowed logging in with google and google only. Which kind of sucks.
I don't remember if I used Google, Facebook, or SO's own auth when I created my SO account. Some sites have upwards of 5 to 10 different ways to login and I find it very confusing.
https://blog.plan99.net/building-account-systems-f790bf5fdbe...
The advice overlaps in various areas, but is different in a few. Might be useful as another take and to see what's the same and what's different.
I skimmed through the NIST document and couldn't find that claim.
> [5.1.3.1 allows if] sent from the verifier to the out-of-band device via the PSTN (SMS or voice).
Maybe it is interpreting this part from the same section?
> the device SHOULD NOT display the authentication secret while it is locked by the owner
So it seems to me that SMS is not deprecated but open to issues if the SMS shows the secret. I looked a little deeper in the doc. Section 5.2.10 on Restricted Authenticators lays out that devices could become restricted as times change, but I couldn't find where the doc actually says 2FA over SMS is now restricted.
The post claims that users may allow SMS for trivial services, but does not call out what that means. I don't use more than a password manager for trivial services (forums and the like), and I use 2FA over SMS for things that might have financial details (if 2FA is an option).
The rest of the article makes sense, but I'm having trouble with this one point. Did I miss something in the NIST document? And if 2FA over SMS is out, as a website with billing, should one look at using an authenticator like Duo? The author says to just auth via Google et al, but that feels like kicking the can down the road hoping they or Twitter have something better than 2FA over SMS.
[Out of band verification] using SMS is deprecated, and will no longer be allowed in future releases of this guidance
Does Google allow me to change the username of my elementary-school aged gmail account?
> Don't impose unreasonable rules for usernames
On Google+ the selection of vanity URL is such a master stroke of tragedy that it hurts to think whether the restrictions are idiotic or just incompetent.
They already have decided the first part of your username for you: <base_url>/FirstnameLastname........
Yes, You only get to choose the last part of your username - the first part is decided. Even though "Firstname, or "Lastname", or "FirstnameLastname", or anything else that you want to choose is available, you can't choose them - unless you are famous enough or possibly you know someone at Google. The latter, I believe, is also very useful if you happen to lose access to your Google account.
After trying twice I just deleted Google+ from my Google a/c.
I really wish the original EAP-TLS specification had had some support for passing passwords across the TLS session. Certificates are great, but so few places provided them, and everyone who wants to easily support Windows 7 machines on the WPA2-Enterprise system has to store plaintext passwords on the server to support MSCHAP-V2.
EAP-TTLS finally did solve that problem, but with Windows 8. When Windows 7 finally dies, one of the first things I'm going to do is discard the plaintext passwords in my authentication databases.
We're not (currently) doing 3rd party providers like Google / Twitter / Facebook, but since we have (well, will have) multiple independent apps out there, we have a CAS[1] server set up for SSO and all our apps use that for authentication.
This current app is a little more complicated to deal with, since it's basically an "app for provisioning apps". So we have "login to the main site" level login, and then login / authorization for the stuff that gets provisioned. We also want to support things like "invite a user to join via email", etc. Still working on how exactly the user experience will work on some of these scenarios.
https://qbix.com/blog/index.php/2018/01/modern-security-prac...
Man, if I was drinking milk I would have shot it out my nose at that one. Google and every single social network are the last actors who make it easy (or even let you for-realize-ies) delete your association. They may let you remove access to the persona they store and monetize, but they certainly don't let you "easily delete your account". THis entire post is a giant crock.
It is pretty easy to delete your account on many social networks. The following support deletion:
* Google (all account data)
* Facebook (all account data except messages that others have received)
* Snapchat (requires you to "deactivate" for 30 days)
One thing that is confusing is that many websites also have a "deactivate" feature. Some users may confuse the two and mistakenly think "deactivation" is the same as "deletion".
So no, I really don't think I should trust Fb with my account deletion. Besides for a long time that's just deactivation. A friend deactivated his account and after few months he received an email that in case he had changed his mind he should click this link and then they should go ahead with reactivation process. Well, that link was reactivation.
As for Google, here's an example - I get a brand new YouTube account when I visit YouTube and just play a video if I am logged in to my Gmail a/c in that browser session. The last time I tested it (before deciding to not ever logging into Fb, Tw, Google etc in the my main browser where I do my most of, and personal, browsing) it would create a YouTube account. No, not a single message, or pop up or anything. Just an automatic YouTube account. I must have deleted my YouTube account (or accounts) some 15 times by now.
I've never used Instagram, or Snapchat. Yes, Reddit's account deletion is actually straightforward (unless they too keep it hidden from user and don't delete it).
Similarly, you can delete your emails from Gmail and your calendar data from Google calendar, but you cannot delete the metainformation consisting of their tracking data and so forth.
Which is what privacypoller was saying: you can remove _your_ access to some of this stuff, but you can't remove all the information they are collecting about you.
You can delete your comments manually (but of course only before deleting the account).
https://support.google.com/accounts/answer/32046?hl=en
Google does let you delete your account. But it can take a few weeks for all the data to be really deleted (there is a recovery period, then some lag to delete everything).
But do know that GDPR will require this for the EU. https://gdpr-info.eu/art-17-gdpr/
Does anybody have any data on the percentage of users that refrain from using Google/Facebook and always create email accounts?
The highly trusted Google and Facebook indeed. Nothing like a fresh oxymoron to start my Sunday.