Building account systems
blog.plan99.net
Building account systems
1–10 of 58 posts
Re: Building account systems
#2> 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?"
Re: Building account systems
#3Lot 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
Re: Building account systems
#4Lot 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
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.
Re: Building account systems
#5Many 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.
Re: Building account systems
#6About 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?
Re: Building account systems
#7Another 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.
Re: Building account systems
#8Another 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.
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.
Re: Building account systems
#9Another 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.
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?
Re: Building account systems
#10Many 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…
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.