
Building account systems - jsnell
https://blog.plan99.net/building-account-systems-f790bf5fdbe0
======
Terr_
> If the username becomes a form of self-expression on your service, users
> will want to change it from time to time.

IMO separating identity from display-name is an under-used design choice,
_especially_ if you think your system needs to scale up to lots and lots of
unique accounts.

I think Steam is an easy example of a service which does it right: Many people
(usually in different social circles) can use the same name, you can change
your display name easily, other people can see some previously-used names, and
you can assign custom names to friends to avoid confusion.

> Pre-supplied questions make the guessing problem worse.

Personally I've love to have the option of choosing my own question.

All too often the pre-supplied questions _suck_ in various ways. Some might be
patently insecure (ex: name of highschool), inapplicable (name of first pet)
or just too ambiguous to rely on (name of street you grew up on, if you moved
a lot.)

With a custom question, I could craft something both secure (at least against
non-family) and also unambiguous to future-me. Ex: "Your worst encounter with
bees occurred in what place?"

~~~
lewisl9029
> I think Steam is an easy example of a service which does it right: Many
> people (usually in different social circles) can use the same name, you can
> change your display name easily, other people can see some previously-used
> names, and you can assign custom names to friends to avoid confusion.

On the other hand, they won't let you change your login name, which would hint
that they're using it as a unique identifier of some kind internally, which
seems like a bit of an antipattern.

~~~
chipperyman573
Every account has a (public) 32 bit ID, it's unlikely (though possible) that
they use the login name for anything more than logging in.

------
ivanhoe
Many solid advices here, but I still have doubts about the real-life UX of
switching to emailed links instead of using passwords. It's quite popular for
some time now, and security wise it makes a lot of sense, but:

For one, that means that each time I wish to login (or switch between
accounts) I need to fill my email and then go to another tab or to mail app,
and wait for the email. It's not that uncommon to take a while for an email to
be delivered. Requirement to stare for 3-5 (or more?) minutes into a screen of
my mail client and obsessively click on refresh button is less than ideal, and
would just get more and more annoying the longer one uses the app. And even if
email arrives immediately, it's still more steps and time then having my
password manager auto-fill the form and log me in.

Also a (minor) annoyance with this is that clicking on the link in email will
open a new tab/window in the default browser, not reuse the one where I
started the login process.

And then you have a full bag of all the usual problems with users not getting
emails for various reasons, from being marked as spam, to simply moved to
Updates tab in gmail, where you can bet that half of your ordinary users will
not be able to find them. That will generate your support team some steady
flow of extra work, you can bet on that.

From my personal experience, each time in some app we were forcing users to
confirm their email address upon registration (non-tech founders often insist
on this for some reason) we'd see between 40% to even 70% drop. People would
register and then never come back because they just didn't care enough to look
for our confirmation email. You can try to manually follow up with email in a
few days, to offer assistance, but most of them will never reply.

By using this approach, you're forcing users into switching their mental
context and attention between your app and all the other emails arriving to
their inbox, all the notifications on social media, all the other distractions
around us. And you can bet that they care much more about any of that than
about trying out your app.

~~~
ams6110
The problem for me at least for mobile access is that I do not have my "real"
email tied to my phone. I have an Android phone, but have a separate gmail
address that is only used in relation to the phone (activation, google play
account, etc.)

If I have to read an email in order to sign in to a web app or website on my
phone, that means I need to get on my computer and go to fastmail.fm. Which is
inconvenient.

~~~
wmf
Is there a reason you don't have the Fastmail app installed?

~~~
ams6110
I don't consider android phones to be trustworthy, and iPhones are too
expensive. So I don't do email, banking, or anything sensitive on my phone.

------
inopinatus
> _Use email / phone numbers to identify users_

This isn't always good advice. Not everyone has a unique email address, and
not everyone has a phone number.

If you're dealing with technology-savvy adults, sure, go ahead.

But demanding a unique email address or phone number is actually a high
barrier for many people. Case in point, my services is used by families. It's
common for them to share an email address, or for the youngest and oldest
members not to possess a personal phone. They also frequently lose access to
email accounts e.g. when changing ISP, which makes account recovery a painful
manual process.

So we use a domain-specific identifier combining a generated membership number
and the family name, and this works out well.

Bottom line, consider your user base when establishing an identity scheme.
Don't blindly accept prescriptions for your data model.

~~~
GordonS
Some services (including Gmail, I think) let you link multiple email addresses
to an account. That could be useful if you lose access to one of your email
accounts.

~~~
inopinatus
Most definitely not in the circumstances I just described. Again, that's a
solution only a tech-savvy user will find accessible. I'm not designing for my
peers, I design for real people.

------
a_imho
1\. Using 3rd party auth is much more convoluted than rolling your own. There
are key turn solutions for every framework and you don't have to register your
product with other services, agree to a bunch of terms, introduce dependencies
in your stack and essentially give control over your app.

2\. Being stuck in a perpetual password reset scenario is one of the worst UX
decisions imo. Going to an email provider to access a completely different
service is getting it all backwards (and users will have to type in their
passwords anyway). Plus email has its own baggage like spam filters etc.

It is very much up to taste, but personally I would even argue for the
opposite: we could do away with forgotten password links altogether (or at
least make them optional) and trust users to handle their passwords how they
wish instead of collecting email addresses (like HN).

------
zie
Another issue is what privacy are you losing by handing FB or Google all of
your authentication?

Offloading this is a huge privacy fail. It probably is a security win, but
it's a huge privacy fail. Here Google/FB/etc, get _MORE_ information for your
giant catch-all, know-all database, thanks!

Unfortunately better alternatives that are not a security win don't really
exist yet.

~~~
ams6110
What privacy are you losing? Real question. You're probably revealing to FB or
Google that you're a user of web app X, but beyond that? Does using FB or
Google auth enable any additional tracking of activities within the app or
site? I would think only if the site developer was using Facebook or Google
ads or tracking anyway.

Asked another way -- if I sign into a website using FB auth, am I also signing
into FB itself at that time? And so can be tracked around the web as if I had
logged into FB directly?

~~~
twright0
I believe that sign-in-with-X implementations require actually authenticating
with X in that context. So in order to sign in with Google to a website, I
need to sign into Google itself in the same browser. So in that sense, you are
enabling Google to track you in that browser - but no differently than if you
just logged into gmail. You could sign back out of Google immediately
afterwards.

But just the fact that an app uses Google authentication doesn't give Google
any kind of privileged access to that app's data (beyond purely the data that
they're logging in on this browser at this point in time) unless the app is
pushing data actively back to Google (which they could do anyway for a gmail-
managed email address, I guess) _or_ you believe that Google will then
subsequently forge authentication requests to that app and pull data out
itself. Both of these things are hypothetical violations of your privacy
enabled by using auth-with-Google, but for most use cases are rather unlikely,
I would guess.

~~~
zyb09
It's not that bad. The only thing Google/FB/Twitter gets to know is that a
user Y is using app X. Nothing more, and not detailed usage stats, just the
basic fact.

For that they handle the complete user registration, recovery & auth process
for you, with all the work and pain attached to it.

Granted if your OAuth provider were really evil, they could log into the users
App X account and access whatever data he has inside the app, so you have
decide if that a concern or not.

~~~
zie
Yes, but they get "only" that, but with it, they get, time/date of when you
use the app(and perhaps how long, depending on how you/they handle logouts).
Plus they get this for _EVERY_ app that's used. You start aggregating this
information and suddenly you can tell a _LOT_ about a person. Plus this is all
for ad dollars, FB/Google/etc can(will/do?) sell this information, to anyone
willing to pay for it.

For a hello world app, no big. For a game app, what happens when your employer
buys the data, and notices you are playing games on "company" time... Of
course lots more privacy failures can be easily imagined here. I picked low
privacy failures, but larger failures are very easy to imagine.. Especially
when we know that most large governments also have this data, directly
siphoned from Google/FB/etc.

------
homarp
>Often web developers see adding a “sign in with Facebook” or “sign in with
Google” button as a kind of optional nice-to-have, which comes only after
building their own account system. If you’re reading this because you’re
starting a new website from scratch, I argue that “Sign in with …” should be
the only option you offer.

unless you have potential clients in China.

~~~
zyb09
Anyone know if there is a good commonly used Chinese OAuth provider? Or
Japanese and Korean for that matter?

~~~
yorwba
I found this related Quora question: [https://www.quora.com/Is-there-an-
equivalent-of-Facebook-Con...](https://www.quora.com/Is-there-an-equivalent-
of-Facebook-Connect-in-China)

Of those mentioned in the answers, I think QQ would be your best bet. I have
never seen anyone use Renren, but everyone seems to have a QQ number.

Another of those "everyone has it" apps is WeChat, which also provides OAuth:
[http://open.wechat.com/cgi-
bin/newreadtemplate?t=overseas_op...](http://open.wechat.com/cgi-
bin/newreadtemplate?t=overseas_open/docs/mobile/login/guide#login_guide)

~~~
Monotoko
You would not use QQ these days, it would be Wechat instead which pretty much
everyone online in China has. QQ died around 2013

~~~
yorwba
I wouldn't say that QQ is dead, I have definitely seen people use it on their
laptops in class at uni. A number of classes also used QQ groups for
announcements, Q&A, etc.

I agree that WeChat is more popular, though. Those who have both my QQ and
WeChat contacts overwhelmingly go though WeChat.

------
mimg
> Users are always identified to you by email address, phone number or both...

An account system using phone numbers may have a negative impact to privacy.
For some people a phone number is attached to a real name and address. Also it
is not uncommon for a person to change their phone number from time to time.

~~~
joshka
For many people (most?) this is true for an email address as well

~~~
ehnto
Certainly for the less tech savvy and thus those less aware of why that might
be an issue.

------
rebelidealist
About using another domain for marketing email. "The best solution is to send
your marketing emails from a different DKIM domain"

Does it mean to use a entirely new-domain.com or use marketing.domain.com?

~~~
jlgaddis
I've seen instances of using example.net instead of the primary example.com
domain, but as a user I prefer subdomains. It's easier to confirm ("visually",
just from the domain name) that it's actually coming from the same company and
not a phishing email, for example.

------
nitwit005
If you're building some sort of ad supported and public site, using Google or
FB accounts is fine, but it's not always workable if they're paying you a
monthly fee. People will want administrative control over accounts, and
they'll call and demand you fix things when they can't login.

------
jff
Lot of articles re-hashing NIST 800-63 since it came out last month. Here's
the original source: [https://www.nist.gov/itl/tig/special-
publication-800-63-3](https://www.nist.gov/itl/tig/special-
publication-800-63-3)

~~~
programd
In fairness this is more then rehashing NIST 800-63. This is coming from a
Google engineer who worked on their authentication systems. A lot of good
advice here, starting with not building your own.

~~~
am1988
> Google engineer

Oh, so basically scripture then.

~~~
legolassexyman
Wait before you make rash judgments: he also worked on Bitcoin.

~~~
bullen
No, he worked on a Java SPV implementaton of Bitcoin.

