Building account systems

https://blog.plan99.net/building-account-systems-f790bf5fdbe0

by jsnell • 9 years ago

138 56 9 years ago

blog.plan99.net

Terr_3• 9 years ago

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?"

jlgaddis4• 9 years ago

I simply generate non-sensical answers regardless of what the questions are. For example, "What is your favorite place to go on vacation?" was a security question I recently encountered. My answer was something absurd, along the lines of "FourteenZebras".

wmccullough• 9 years ago

lewisl9029• 9 years ago

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• 9 years ago

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.

Terr_3• 9 years ago

While I would like to change my login name, the important thing is that it's not used anywhere else. This means it does not get in the way of my self-expression, and also that nobody who I talk to through the system can harass me by repeatedly entering wrong passwords.

Come to think of it, that also serves as a counterexample to one of the article's pieces of advice: using an email address as the users login. Steam used to work that way, which is why I have to log in using a string which is an email address I don't use anymore.

benpbenp• 9 years ago

and also unambiguous to future-me. Ex: "Your worst encounter with bees occurred in what place?"

Optimistically assuming your worst-bee-encountering days are behind you, of course.

PaulRobinson• 9 years ago

Lying in the hospital bed, the "Get well" cards decorating the space around you, the creams and ointments soothing, you realise you haven't checked your bank account since The Incident.

You pick up your phone and log in to internet banking.

"Oh no. Oh no, no, no. Why is it taunting me? Sacramento was _nothing_ to this. _Nothing._"

A tear rolls down your cheek.

Through the window a lone bee watches. The tear it sees is good, but not enough. It will go back to the hive and dance to communicate to the others your pain, but their ultimate failure in their plan. They will regroup. They will be back.

inopinatus3• 9 years ago

The trouble with that is that now you can never relate your amusing/horrifying story about the bees. Also consider the worrying possibility that you may have another, even worse encounter with bees.

I had a similar recent experience (not with bees, with security questions) whilst joining the Apple Developer programme. All the questions on offer assumed a conventional middle-class American upbringing and referenced experiences and institutions that I have simply never encountered. This is not unusual. Fortunately my password manager generates all the fake cats & cars & prom dates I never had.

hardwaresofton• 9 years ago

One counter point -- it's pretty hard to add new steam friends by ID because often it's hard to figure out exactly which name to search for in their online tool.

You can't really add people by direct username, so you have to go by their most recently used nickname, and you get some complexity that you don't expect as an end-user.

ubernostrum• 9 years ago

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.

The one true pattern for auth/identity has been known a long time:

http://habitatchronicles.com/2008/10/the-tripartite-identity...

jff• 9 years ago

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

programd• 9 years ago

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• 9 years ago

Google engineer

Oh, so basically scripture then.

ivanhoe2• 9 years ago

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.

ams61103• 9 years ago

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• 9 years ago

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

jlgaddis4• 9 years ago

Very similar for me. The only emails I get on my iPhone and/or iPad are alerts for $work. For anything else I have to pull up my mail client (I don't use webmail) so it's a huge pain in the ass. I'm hoping this method of "authenticating" quickly dies out.

virgil_disgr4ce• 9 years ago

Agreed. And furthermore, some corporate email filtering can delay receipt of emails for HOURS, making it literally impossible to login under certain circumstances, which in my own experience is insane and enraging.

jlgaddis4• 9 years ago

If you're requiring an email/login and 40-70% of users never confirm or bother coming back, perhaps your product isn't something they really want. Personally, I hate being forced to go through the process of creating an account only to quickly discover that I'm never going to use application/website/whatever again.

ivanhoe2• 9 years ago

I'm talking about the situation where you can't login into the site without first confirming your email. Yeah, I know it sounds crazy, but owners initially insisted on doing it that way on two separate projects I was involved with. So customer has never seen the actual product. They'd register and then instead of immediately going to their email client to confirm it and login, they'd go somewhere else, and never come back to test the product. In many ways this is a similar process to the one with password links, and I think it would have the same effect.

_cereal• 9 years ago

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.

Some countries in Europe require to prove user opt-in consent, in addition the EU General Data Protection Regulation (GDPR)[1] approved in 2016 and active starting from May 2018 will, in practice, extend it to all EU countries.

[1] https://en.wikipedia.org/wiki/General_Data_Protection_Regula...

rebelidealist• 9 years ago

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?

zrail• 9 years ago

Either way is fine. A subdomain is generally easier for users to grok and it looks less like a phishing attempt.

jlgaddis4• 9 years ago

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.

zie3• 9 years ago

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.

noir_lord• 9 years ago

Yep, side project I'm thinking of playing with in a month or two when the batteries are recharged pretty much completely rules out using either (health data).

I wouldn't sign up to my own side project if I had to use either in that case.

jopsen2• 9 years ago

I'll have to admit I prefer services that has a "sign up with" particularly google, github or facebook in that order :)

It's one less password to manage...

ams61103• 9 years ago

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• 9 years ago

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.

zie3• 9 years ago

Exactly, Google, FB, etc. They require you login to their website. They also now know you use web app X, the date/time, how often you use said website, etc.

For some applications, that privacy loss may not be a big deal. Except if you combine this information with the other 500 web apps the user also uses through 'Sign in with...' links, plus all the other information they gather, they suddenly get to know you really, really well.

greenyoda• 9 years ago

"You're probably revealing to FB or Google that you're a user of web app X, but beyond that?"

That in itself could be giving away a lot of personal information. Merely knowing that someone visits a particular web site regularly could disclose their sexual orientation, health/mental issues, financial status, religious or political affiliation, etc.

If FB or Google then starts serving you ads that reflect these associations, it could publicly leak information about you that you don't want leaked. In some countries, having the "wrong" sexual orientation or political association could be deadly.

nitwit005• 9 years ago

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.

mimg• 9 years ago

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• 9 years ago

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

ehnto2• 9 years ago

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

homarp• 9 years ago

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.

zyb093• 9 years ago

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

yorwba2• 9 years ago

I found this related Quora question: https://www.quora.com/Is-there-an-equivalent-of-Facebook-Con...

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

jimktrains2• 9 years ago

I hate and never use "Sign in with ..." as I don't like my identities to be closely tied together like that. I avoid giving Google and Facebook any information I can't avoid/don't want them to have.

Terr_3• 9 years ago

Personally, that drives me to a competitor, especially if the site offers absolutely nothing I'd ever want to integrate -- or have someone else integrate -- into my real-name persona.

ehnto2• 9 years ago

I did find that an odd comment. I understand the assumption is that you will eventually roll your own (perhaps?) but to imagine requiring a user to be part of those services to use your own service, especially of your service has nothing to do with those, is very strange. Just a few examples of how that could become a pain for our pretend user Greg:

a) The obvious, Greg simply does not want a Google/Facebook/etc account.

b) Greg is from a region that does not have strong Google/Facebook/etc uptake and does not have one.

c) Greg is from a region that actually disallows those services, making your service blocked entirely.

d) Greg does not want to link his 3rd party account to your service.

Lastly if you are targeting enterprise clients: Greg is signing up to your service for a company he works for, not for himself, and there is of course no "Company Facebook Account". If his company uses Google Mail then he is in luck, but if not then there is a whole new account management process to go through. Someone will inevitably leave the company, lose the credentials, forget they ever had an account in the first place or remember they had an account but forget the new 3rd party services password instead.

Not to mention, if you are running a company, relying on a third party for such an important part of the puzzle is putting an enormous amount of trust into that third party. I know there are lots of those trust connections to take into account in any business, but if I am in the business of writing software it seems odd for me to not have the confidence and ability to manage an in house accounts system.

inopinatus3• 9 years ago

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• 9 years ago

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.

inopinatus3• 9 years ago

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• 9 years ago

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

Building account systems

Related Stories