
Best practices for user account, authorization and password management - mooreds
https://cloudplatform.googleblog.com/2018/01/12-best-practices-for-user-account.html
======
JoshTriplett
> 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.

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.

~~~
iraklism
Million guesses per second vs thousands. Really interesting how SHA3 made its
way to this blog post.

~~~
whatevaa
Still better than no hashing. Still a tough nut to crack if it's hashed plus
salted with unique salt.

~~~
oldcynic
Ugh. It's supposed to be _Best Practices,_ rather than better than nothing,
and is ostensibly from Google. So should be limiting to the appropriate
choices: bcrypt, scrypt, PBKDF2 or Argon2.

~~~
user5994461
Not everyone can used the last hype algorithm, whether because of library
support, regulations or technical constraints.

~~~
mediumdeviation
bcrypt is old enough to vote this year

~~~
cyberfart
still can't drink in US though

------
cakoose
This is surprisingly lower quality than what you'd expect from Google.

> 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.

~~~
Matt3o12_
Can you point me to good resources to learn more about Unicode normalization
especially for passwords? What are the gotchas? One the one hand, when users
are allowed to enter any character, they often have difficulties to log in
when they are aboard and not use their own devices. Though, I don't know if
every Russian (for instance) would be able to enter a "English" password.

~~~
drdaeman
> Though, I don't know if every Russian (for instance) would be able to enter
> a "English" password.

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).

~~~
spiffytech
Case-insensitive password comparison in a very bad idea because it strips a
lot of entropy from the password pool.

~~~
drdaeman
My bad, I meant not really case-insensitive but flipped case, to account for
possible Caps Lock state. I.e. for "Hunter2" you also accept "hUNTER2" (but
"HuNTeR2" is still not valid).

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.

------
TheAceOfHearts
Third-party identity providers are bad for a number of reasons. My biggest
issue is that none of the mentioned services make any guarantees against
arbitrary account termination or lockdown. If the identity provider decides to
lock you out, there's no recourse for the user. Google Accounts are notorious
for this, making it nigh impossible to reach a human unless you have an
engineering connection on the inside.

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.

[0] [http://shiro.apache.org/](http://shiro.apache.org/)

~~~
dpcan
I think it USED to be hard to reach a person at Google, but over the past
year, for a number of various reasons I've needed to reach Google, and I've
spoken with a very helpful person in every case I had, it was pretty awesome
actually.

~~~
chmars
How did you get your contact?

~~~
mcpherrinm
Well, that depends on what you need support for. Are you a company giving
google lots of money? Their more professional products, like Gsuite and GCP,
have support available:
[https://gsuite.google.com/support/](https://gsuite.google.com/support/) and
[https://cloud.google.com/support/?options=premium-
support#op...](https://cloud.google.com/support/?options=premium-
support#options)

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.

------
ricardonunez
Validate email addresses before people can use your service. I lost count how
many people have created accounts using my email address just because I happen
to own the Gmail for my name. Banks, health records, dating sites and even
students emailing me their homework thinking I am their teacher.

~~~
vit05
This happens to me and I'm already pissed off. It's a lot of emails from
people who miss something in the address. Worse, these same people try several
times to retrieve the password of an email that they do not have. Or put my
email as a password recovery from their addresses. I get invoices from card
accounts, personal emails, work emails.

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.

[https://i.imgur.com/Vh44YXd.png](https://i.imgur.com/Vh44YXd.png)

~~~
fro0116
That... sounds like a nighmare. I've always been slightly bitter about not
ever having been able to get the canonical version of my first name or first
name last name combination on email services due to having a rather common
name, but now I'm kind of glad I wasn't able to after hearing what people in
this thread have had to deal with.

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.

~~~
mistersquid
> 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

~~~
isostatic
I used to do this 15-20 years ago, ran my own smtp server too, dropped thing
via spamassasin, custom email aliases for each sign up, etc etc.

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.

~~~
mistersquid
Not all blocked senders/recipients are sources of spam. I have a list of
senders/recipients I refuse communication with for both personal and
professional reasons.

Since 2013 I use macOS Server which simplifies the overhead of running a IMAP
mail server.

------
CM30
Okay, I'm probably going to get a fair bit of heat for saying this, but am I
the only one who's never been a huge fan of letting users delete all content
associated with their account at will?

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.

~~~
kuschku
I suggest you read about the new European General Data Privacy Regulation,
which comes into force in May 2018, and requires you to allow users to (a)
export and (b) delete all personal data they gave you, including messages,
posts, etc. Violation will be punished with a fine of up to 20 Million EUR or
4% your global revenue, whichever is higher. This law will apply to all sites
that have EU customers, no matter where the site is located, and will be
enforced globally (through banks assisting with account freezes, etc).

~~~
shandor
Where did you get that "messages and posts" are included in data that falls
under the regulation? Not contesting, genuinely interested. I was under the
impression it only covered personal data in a very strict sense (names,
addresses, personal info like gender, etc)

~~~
kuschku
The GDPR, as far as I was told when asking a lawyer, covers anything that
could contain personal information.

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.

------
jwilk
> _If you must cap password length, only do so based on the maximum POST size
> allowable by your servers. This is commonly well above 1MB. Seriously._

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.

~~~
taberiand
And for God's sake, ensure the length checks performed at login are the same
ones used on account creation. More than a few times have I been stuck at
login because my 20+ character auto- generated password was silently truncated
to some arbitrary length between creation and login.

~~~
davchana
India's version of 401k account, eNPS does that, will accept all passwords,
but silently truncates at 14 char length, and when you try to login, throws
error.

------
torstenvl
_Usernames should be fully case-insensitive. It 's trivial to store usernames
and email addresses in all lowercase and transform any input to lowercase
before comparing._

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.

~~~
myroon5
Interested in this one. Could you provide a specific example?

~~~
torstenvl
For the first, any situation where there isn't a 1:1 coupling of capital and
lowercase letters would result in collision or ambiguity upon a .tolower()

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...](https://stackoverflow.com/questions/319426/how-do-i-do-a-case-
insensitive-string-comparison)

~~~
dmichulke
> 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.

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

~~~
torstenvl
Yeah my bad for the ambiguity. I meant normalize the input into the database,
i.e., into the backend.

------
chx
Here's my advice: do not use passwords. Just don't. If someone wants to log
in, mail them a one time link. And make the session long enough this doesn't
happen often -- when was the last time you needed to log into HN or Github?

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.

~~~
newscracker
Edit: This is a decent enough solution, though it comes with its own pitfalls.

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?).

~~~
MildlySerious
Another big one is that this method is not entirely device agnostic. I am not
able/willing to log into my email account on every device that I might want to
log into your service with.

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.

~~~
adambrenecki
now.sh handles this quite nicely: when you log in there, they send you an
email and display three random words. When you get the email, you verify the
words match, click the link, and then you'll be logged in _in the original
browser tab, on the original device_.

------
nnq
> 4\. Allow multiple identities to link to a single user account

 _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...).

~~~
ubernostrum
The correct pattern for this has been known for a very long time:

[http://habitatchronicles.com/2008/10/the-tripartite-
identity...](http://habitatchronicles.com/2008/10/the-tripartite-identity-
pattern/)

------
ryan-c
My (probably unpopular) opinion is that passwords should be randomly generated
by the service, and not possible to change to a user-selected value.

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.

~~~
trevyn
For services that generally "stay logged in", why have passwords at all? Just
do "magic login link" emails, with some sort of 2FA if you're into that.

~~~
ryan-c
I think "magic login links" are fine for most services. Doing 2FA with that is
not feasible though, unless you want to argue that receiving the email counts
as "something you know" or that "something you have plus something else you
have" counts as 2FA.

~~~
trevyn
If you have your email protected with 2FA, I think you're covered -- "An
unlocked device with an active session" is the thing you have.

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.

------
0x7f800000
#1 best practice for managing passwords is: don't try to implement password
management yourself because you will get it wrong.

~~~
Osiris
That's exactly what I was thinking. Using OAuth logins from Google, Facebook,
etc. saves a lot of pain.

~~~
pavel_lishin
It offloads that pain to the user. What if I no longer wish to have a Facebook
account? What if I lose access to it?

~~~
ams6110
Or what if I don't have one? Now I need to sign up for some social media
platform that I don't want, just to use your service?

------
mike_hearn
I used to work on Google's account system and wrote up a set of suggestions
for how to implement user accounts on your website here:

[https://blog.plan99.net/building-account-
systems-f790bf5fdbe...](https://blog.plan99.net/building-account-
systems-f790bf5fdbe0)

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.

~~~
spydum
Great post Mike! Just wish there was a solid solution for identity providers
in the enterprise space (gsuite and activeAD exist, but pretty rare). Instead
every company ends up building their own IDP and making all these same
mistakes. The difference is they aren't often quite as targeted for abuse (tho
depends on the business).

------
sethammons
> SMS 2FA auth has been deprecated by NIST
> ([https://pages.nist.gov/800-63-3/sp800-63b.html](https://pages.nist.gov/800-63-3/sp800-63b.html))
> due to multiple weaknesses, however, it may be the most secure option your
> users will accept for what they consider a trivial service.

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.

~~~
bowyakka
It was in older versions from 2016

[Out of band verification] using SMS is deprecated, and will no longer be
allowed in future releases of this guidance

~~~
sethammons
ah, thanks!

------
pgodzin
> Allow users to change their username

Does Google allow me to change the username of my elementary-school aged gmail
account?

~~~
balladeer
They also say this:

> 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.

------
secabeen
> Do not store plaintext passwords under any circumstances.

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.

~~~
mygo
You store plaintext passwords? Interesting... where do you work? What’s your
tech stack? Oh and what’s your name? ...

------
mindcrime
This is timely as I am literally just getting into working on the account
management / login / registration stuff for a new app tonight. Most of this
stuff isn't really new, but it's good to have a reminder, and/or validation of
certain things.

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.

[1]:[https://github.com/apereo/cas](https://github.com/apereo/cas)

------
EGreg
This is good advice. However in 2018 you can go a lot further. Our company
wrote up this guide:

[https://qbix.com/blog/index.php/2018/01/modern-security-
prac...](https://qbix.com/blog/index.php/2018/01/modern-security-practices-
for-web-developers/)

------
privacypoller
>> 8\. Let your users delete their accounts

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.

~~~
kj65557
(also work for google)

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)

* Reddit

* Instagram

* 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".

~~~
balladeer
I have deleted all my photos on Facebook. Some of the "featured" photos I've
deleted dozens of times (I've deleted twice just now leaving this comment
midway) and Facebook still shows those featured photos in my profile when I
log-in. Yes, it doesn't show anything to the public or my friends but I still
can't get rid of those photos on Facebook. I tried to contact Fb couple of
times but of course I didn't receive any response.

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).

------
raarts
Using Google and Facebook for your user's login is easy and safe. It's when
programmers create there own login process where true problems arise.

Does anybody have any data on the percentage of users that refrain from using
Google/Facebook and always create email accounts?

------
marknadal
Even better best practices: Don't let the server be able to derive the
password at all. Have fully P2P user accounts that use PBKDF2 to extend
passwords into proofs that can client-side only decrypt public/private
keypairs. For an example, see:
[https://github.com/amark/gun/wiki/auth](https://github.com/amark/gun/wiki/auth)

------
stedaniels
So has anyone got a guide on implementing the relevent portions of these best
practices in ADFS?

~~~
spydum
Check out Azure AD. Most of the best practices are implemented there.

------
interfixus
> _Third-party identity providers enable you to rely on a trusted external
> service to authenticate a user 's identity. Google, Facebook and Twitter are
> commonly used providers_

The highly trusted Google and Facebook indeed. Nothing like a fresh oxymoron
to start my Sunday.

------
matt_wulfeck
This article is basically one giant ad for using google sign in for your
website... and for good reason! They know what they’re doing. I’m delighted
when I see that I can create an account using Google SSO because I’m so much
more confident with them.

------
cjsawyer
Leave it as Hunter2 and call it a day

