9 ms·
Building account systems
- jff 9y agoLot 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 9y agoIn 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 9y ago> Google engineer Oh, so basically scripture then.
- legolassexyman 9y agoWait before you make rash judgments: he also worked on Bitcoin.
- bullen 9y agoNo, he worked on a Java SPV implementaton of Bitcoin.
- Terr_ 9y 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?"
- jlgaddis 9y agoI 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 9y agoOk
- deleted 9y ago[deleted]
- lewisl9029 9y 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.
- Terr_ 9y agoWhile 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.
- chipperyman573 9y agoEvery 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 9y agoMany 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 9y agoThe 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.
- rebelidealist 9y agoAbout 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 9y agoEither way is fine. A subdomain is generally easier for users to grok and it looks less like a phishing attempt.
- jlgaddis 9y agoI'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.
- zie 9y agoAnother 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 9y agoYep, 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.
- jopsen 9y agoI'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...
- pfranz 9y agoI feel like an old person for hating those things. * I have a password manager because I have to manage 100s of passwords already and most aren't moving to Google anytime soon. * There are a few occasions where I've had to share my credentials with friends or family. It's nice to change the password temporarily and not give them access to my whole Google account. * I don't want to sign into Google on every devices/computer. Similar to the passwordless recommendation: I don't want to sign into email on every device I use the account on. * I don't want Google to know anything about me it doesn't have to. I have a Facebook account and Google account, but I rarely log in. I switched my email away from Google years ago for this reason. * What if I want to create a test account or second account to play around? I like the idea of single signon, but I don't trust the Big Boys with my data. Exclusively having "sign up with" buttons usually makes me leave the site.
- 9y ago
- nitwit005 9y agoIf 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 9y 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.
- homarp 9y 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.
- zyb09 9y agoAnyone know if there is a good commonly used Chinese OAuth provider? Or Japanese and Korean for that matter?
- yorwba 9y agoI found this related Quora question: https://www.quora.com/Is-there-an-equivalent-of-Facebook-Connect-in-China 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_open/docs/mobile/login/guide#login_guide http://open.wechat.com/cgi-bin/newreadtemplate?t=overseas_op...
- Monotoko 9y agoYou would not use QQ these days, it would be Wechat instead which pretty much everyone online in China has. QQ died around 2013
- yorwba 9y agoI 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.
- zyb09 9y ago
- inopinatus 9y 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 9y agoSome 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 9y agoMost 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 9y ago1. 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).