Best practices for user account, authorization and password management(cloudplatform.googleblog.com)
cloudplatform.googleblog.com
Best practices for user account, authorization and password management
https://cloudplatform.googleblog.com/2018/01/12-best-practices-for-user-account.html
163 comments
Million guesses per second vs thousands. Really interesting how SHA3 made its way to this blog post.
Still better than no hashing. Still a tough nut to crack if it's hashed plus salted with unique salt.
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.
Something they acknowledge later with SMS being a bad idea, but may be the best option for a specific workflow.
Not everyone can used the last hype algorithm, whether because of library support, regulations or technical constraints.
glibc crypt() uses sha512, IIRC (the thing that encrypts passwords in /etc/shadow). Iterated a number of times to make it suitably expensive.
So perhaps not as good has the bespoke password hashing functions, but not a disaster waiting to happen either.
So perhaps not as good has the bespoke password hashing functions, but not a disaster waiting to happen either.
Salting and iterating would make it more reasonable, but the article (a "best practices" document) didn't say to do that, or why.
[deleted]
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.
> 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.
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.
> 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).
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).
Case-insensitive password comparison in a very bad idea because it strips a lot of entropy from the password pool.
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.
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.
This is very good primer on the topic, including unicode normalization, punycode and others, with ultra short python examples and links to more info.
https://www.b-list.org/weblog/2018/feb/11/usernames/
https://www.b-list.org/weblog/2018/feb/11/usernames/
I believe, as a matter of necessity, every PC out there will allow any user to enter ASCII, even if it's not within their contry language's alphabet.
In short, there are multiple ways to represent the same character in Unicode: https://stackoverflow.com/questions/16173328
@ademarre's RFC link looks like a good place to look for guidance.
@ademarre's RFC link looks like a good place to look for guidance.
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/
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/
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.
How did you get your contact?
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/ and https://cloud.google.com/support/?options=premium-support#op...
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.
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.
What if you use third party auth, but keep your own account records, including email addresses?
Then if you run into any issues with the third-party provider, you just "disable" the integration and do a normal email-based password reset flow.
Then if you run into any issues with the third-party provider, you just "disable" the integration and do a normal email-based password reset flow.
That could be a viable path for some services. It really depends on the use-case, e.g. the kind of information being stored and how it's used.
You could have the user register by providing an email and clicking a verification link, and then optionally allow em to link third-party services. Regular account access is allowed after authenticating through any available method, but administrative actions require going through the email flow. That way you reduce the risk from a compromised or malicious third-party. Of course, this would assume that email is a good identification authority, which isn't always the case.
You could have the user register by providing an email and clicking a verification link, and then optionally allow em to link third-party services. Regular account access is allowed after authenticating through any available method, but administrative actions require going through the email flow. That way you reduce the risk from a compromised or malicious third-party. Of course, this would assume that email is a good identification authority, which isn't always the case.
You could have the user register by providing an email and clicking a verification link, and then optionally allow em to link third-party services.
You don't need that complex workflow; most third-party authentication services allow you to also request the user's email address during the initial process.
You don't need that complex workflow; most third-party authentication services allow you to also request the user's email address during the initial process.
That's fine if you're prepared to trust them as a kind of root authority. But it's not always appropriate. By sending an email and having the user visit the activation link you confirm with fairly high certainty that they are in possession of the email being used.
I don't think some of these alleged identity providers should have as much power and trust as they have.
I don't think some of these alleged identity providers should have as much power and trust as they have.
All you're trusting is that they have verified the email themselves. You still get the email address and can then communicate with and authorize the user directly if you wish.
+1. It's a good idea to have some way of contacting your users regardless of what authentication scheme(s) you use.
Hence the additional suggestion to
4. Allow multiple identities to link to a single user account
4. Allow multiple identities to link to a single user account
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.
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
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
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.
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.
> 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 [email protected]
2. Targets of spam can be blocked at the server level: [email protected] REJECT
3. Leaked emails can be changed using a timestamp [email protected]
4. Blocked recipients map to blocked senders so [email protected] will be notified they are blocked.
EDIT: formatting
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 [email protected]
2. Targets of spam can be blocked at the server level: [email protected] REJECT
3. Leaked emails can be changed using a timestamp [email protected]
4. Blocked recipients map to blocked senders so [email protected] will be notified they are blocked.
EDIT: formatting
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.
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.
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.
Since 2013 I use macOS Server which simplifies the overhead of running a IMAP mail server.
I gave up on trying to warn. I have a kid from Ohio who has been doing this since his sophomore year of highschool and is now out of college for at least two years. The most interesting stretch was the first weeks in the dorms ... ohh boy he had some interesting “entertainment” preferences. Of course I also got late notices on his book rentals, login links for medical records after doc visits, etc. I was tempted for awhile to put together a scrapbook of some of the more interesting messages to mail to his parents. Occasionally I will notify a more sensitive sender, e.g. doctor, but have given up on getting him to be more careful or ever change any of the existing accounts.
I also get an array of notices to what I imagine is a late middle age woman in the Midwest. She apparently enters my address believing it is her husbands for important accounts. I get service notices on their cars, billing notices and other account info for her Talbots card, etc. Have tried to contact this couple as well with no luck. I’ve even responded to a couple of non-list senders and asked them to pass on the message for me.
Over the years, I’ve grown less annoyed and more curious about the people causing themselves a privacy nightmare by sending their data to someone with fewer scruples than myself.
I also get an array of notices to what I imagine is a late middle age woman in the Midwest. She apparently enters my address believing it is her husbands for important accounts. I get service notices on their cars, billing notices and other account info for her Talbots card, etc. Have tried to contact this couple as well with no luck. I’ve even responded to a couple of non-list senders and asked them to pass on the message for me.
Over the years, I’ve grown less annoyed and more curious about the people causing themselves a privacy nightmare by sending their data to someone with fewer scruples than myself.
This has happened to me too. Multiple people have used a variation on my GMail address and signed up for stock trading, banks etc., and I keep getting a deluge of their invoices, balance statements, promotional emails etc., and the worst part is none of these orgs will easily approach the person using my email and ask them to update their records. The process of complaining is so cumbersome that I elected instead to redirect their emails into Bin and be done with it, but fresh ones from new addresses do show up occasionally.
The intruiging part of this is they should never have been able to get a GMail address using a variation of my name (say my removing or adding a .) since GMail says they disallow it, but then I just don't get it how so many people have managed to signup to so many services using such an 'impossible' variation of my address? Is there a loophole in GMail or do all these services accept account registrations without email verification?
Either way I'm now seriously considering moving to a different email address and making it something esoteric so no one will think of using it, but that means I'll have to give up on using my name.
The intruiging part of this is they should never have been able to get a GMail address using a variation of my name (say my removing or adding a .) since GMail says they disallow it, but then I just don't get it how so many people have managed to signup to so many services using such an 'impossible' variation of my address? Is there a loophole in GMail or do all these services accept account registrations without email verification?
Either way I'm now seriously considering moving to a different email address and making it something esoteric so no one will think of using it, but that means I'll have to give up on using my name.
>>> The intruiging part of this is they should never have been able to get a GMail address using a variation of my name (say my removing or adding a .) since GMail says they disallow it
Dots are ignored a in gmail address.
[email protected] and [email protected] is the same inbox.
Dots are ignored a in gmail address.
[email protected] and [email protected] is the same inbox.
Yes, someone created a twitter account in 2013 using my secondary gmail address. Used it for few weeks and posted crap. Got blocked.
I found out only in Dec 2017 when I tried creating a new twitter account. I could reset the password, because I have control over my gmail address. I thought, ban was because email was unverified. So I verified. Even provided a mobile number. Even though, It wouldn't undo the account suspension. I sent support ticket 5+ time, and every time got "Account permanently suspended because of repeated violation of twitter rules".
So unforutnate, ultimately I just created a new gmail/twitter pair.
I found out only in Dec 2017 when I tried creating a new twitter account. I could reset the password, because I have control over my gmail address. I thought, ban was because email was unverified. So I verified. Even provided a mobile number. Even though, It wouldn't undo the account suspension. I sent support ticket 5+ time, and every time got "Account permanently suspended because of repeated violation of twitter rules".
So unforutnate, ultimately I just created a new gmail/twitter pair.
I don't understand how this situation is a problem, yet Twitter has no issues with millions of bot accounts existing, which would seem easy to identify if you own the service.
I'm on the same boat here. I get everything from appointments to family meetings to banking info. At first I tried to reach back to correct the mistake but it became a pointless task.
It's amazing how many banks and financial/medical institutions don't even bother in confirming email addresses given how sensitive the info they handle is.
It's amazing how many banks and financial/medical institutions don't even bother in confirming email addresses given how sensitive the info they handle is.
Worse yet, when banks don't even try to correct when contacted.
I don't have a common name, just lucky enough to get a preferred gmail account.
Someone, I don't know, signed up to American Express with my email. I'm getting all their AMEX emails.
When AMEX was contacted, they wanted my SSN and "sell me" their identity protection services (as i remember) and didn't care (?) that their member's statements was going to the wrong person.
I don't have a common name, just lucky enough to get a preferred gmail account.
Someone, I don't know, signed up to American Express with my email. I'm getting all their AMEX emails.
When AMEX was contacted, they wanted my SSN and "sell me" their identity protection services (as i remember) and didn't care (?) that their member's statements was going to the wrong person.
Somebody signed up for Diner's, of all things, using [email protected] (we use a shared email for utility bills).
I don't even know anyone who has a Diner's card in Italy, or even thought of getting one... It's even less commonly accepted than AmEx and has fewer perks.
I don't even know anyone who has a Diner's card in Italy, or even thought of getting one... It's even less commonly accepted than AmEx and has fewer perks.
This, 1,000 times this. I have gotten access to other folks' accounts who think they're using their email address, but they're actually using my email address. Car loans, job applications, doctor appointments, etc.
Or at least have a "you got the wrong email" link on each email sent. I get this problem too but less so because I have my middle initial included. I tried several times to alert them that the email was wrong but it's always impossible, which is just baffling.
Someone registered their US college grant on my email through Gmail. I tried contacting US embassy. The school. Other US government institutions. No luck nobody responded to my emails. It was some us government site that didn't do email validation. I'll see if I can dig it up
I have the same problem and the same cause.
Some institutions were even sending the emails for two different people using the same email address. Which was mine and I was not a client in either of them.
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.
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.
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).
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)
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.
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.
Delete, or make it not findable by other normal user accounts? How is deletion enforcable or provable? Are government agents allowed to enter your premises or those of your data centre(s), and gain complete and unrestricted access to all physical disk media to do a full scan to prove or disprove any given allegation of failure to delete?
There are no government agents entering your premises, but if it turns out you had the data still (and even if it's an employee telling the police), you're on the hook for up to 4% global revenue for the time frame in which you did it, or 20 million EUR, whichever is higher.
So you absolutely don't want to do that.
Google handles this by, over the course of a few weeks, even deleting all traces from its backups and caches.
So you absolutely don't want to do that.
Google handles this by, over the course of a few weeks, even deleting all traces from its backups and caches.
> 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.
None of those things are going to turn up in a Google search 20 years from now - there's a relatively limited number of people who are going to dig up this information and send it to your employer, or use it to commit crimes against you.
Privacy is not binary, as much as it's nice to think about it that way - something I've only told 2 people I trust is decidedly more private than something I've published to the world, and something I've published online and then removed is more private than something I've left up.
None of those things are going to turn up in a Google search 20 years from now - there's a relatively limited number of people who are going to dig up this information and send it to your employer, or use it to commit crimes against you.
Privacy is not binary, as much as it's nice to think about it that way - something I've only told 2 people I trust is decidedly more private than something I've published to the world, and something I've published online and then removed is more private than something I've left up.
Tell that to the EU.
One of the primary reasons I don't like posting here or on services like you describe is because I cannot delete anything. Maybe you've enough users who don't care about that but it should be taken into consideration that many people will not participate.
You'd be therefore trading direct communication for archived communication and I'm not sure that's more valuable.
You'd be therefore trading direct communication for archived communication and I'm not sure that's more valuable.
> That's why my ideal solution has always been to basically say 'by signing up with this service, you grant us an irrevocable, unlimited right to use your posts for the purposes of the community' with a nice 30 minute or so editing window set for content.
Soooo, HN?
Soooo, HN?
There's a significantly higher barrier to having your personal information show up in a book or magazine (eg editors). People make stupid mistakes on social websites on the time.
> 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.
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.
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.
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.
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.
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.
This part of the article is just so English-specific it hurts. It's assuming that usernames will all be ASCII, basically.
There is nothing trivial about either "lowercasing" or "case-insensitive compares" in general Unicode strings...
There is nothing trivial about either "lowercasing" or "case-insensitive compares" in general Unicode strings...
In Perl5 there’s fc() which handles that.
https://perldoc.perl.org/functions/fc.html
https://perldoc.perl.org/functions/fc.html
"handles" in what sense? It needs to give different answers for the same letter depending on whether the text is English or Turkish, for example, so I don't see how it can "handle" it in general.
Reading the documentation you link to, the answer in the fine print is that fc() gives you incorrect results for Turkish text.
Reading the documentation you link to, the answer in the fine print is that fc() gives you incorrect results for Turkish text.
Interested in this one. Could you provide a specific example?
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...
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...
> 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
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
Yeah my bad for the ambiguity. I meant normalize the input into the database, i.e., into the backend.
Say a German user’s chosen name is spaß (“fun”). In all uppercase, that name is equivalent to SPASS or perhaps SPASZ and as of last year[0] SPAẞ.
[0]: https://en.wikipedia.org/wiki/Capital_ẞ
[0]: https://en.wikipedia.org/wiki/Capital_ẞ
I have never seen ”ß” meaning ”sz” (or anything other than ”ss”), can you point me to a source?
From the Wikipedia article:
Designs for an SZ ligature has been part of typesets from the 1910s until the 1950s, but in the opinion of Herrmann (2011), the long-standing alphabetic equivalence of ß with ss and the abolition of the optional capitalization of ß as SZ (abandoned in 1996⁽¹¹⁾) means that this is no longer a valid option that "Germans would want to use on a regular basis".
¹¹ until 1996, it was recommended to render ß as SS in allcaps except when there was ambiguity, in which case it should be rendered as SZ. The common example for such a case was IN MASZEN (in Maßen "in moderate amounts") vs. IN MASSEN (in Massen "in massive amounts"), where the difference between the spelling in ß vs. ss could actually reverse the conveyed meaning.
Also, https://en.wikipedia.org/wiki/%C3%9F contains a concrete example:
https://en.wikipedia.org/wiki/File:ABSCHUSZGERAET.jpg
Designs for an SZ ligature has been part of typesets from the 1910s until the 1950s, but in the opinion of Herrmann (2011), the long-standing alphabetic equivalence of ß with ss and the abolition of the optional capitalization of ß as SZ (abandoned in 1996⁽¹¹⁾) means that this is no longer a valid option that "Germans would want to use on a regular basis".
¹¹ until 1996, it was recommended to render ß as SS in allcaps except when there was ambiguity, in which case it should be rendered as SZ. The common example for such a case was IN MASZEN (in Maßen "in moderate amounts") vs. IN MASSEN (in Massen "in massive amounts"), where the difference between the spelling in ß vs. ss could actually reverse the conveyed meaning.
Also, https://en.wikipedia.org/wiki/%C3%9F contains a concrete example:
https://en.wikipedia.org/wiki/File:ABSCHUSZGERAET.jpg
English has the letter “I“ with lowercase form “i“. Turkish has the letter “I“ with lowercase form “ı“ and the letter “İ“ with lowercase form “i“. This means for any word containing the letter “i“ case conversion rules differ between Englisch and Turkish.
That's why modern string APIs ask you which locale to use for case conversion.
That's why modern string APIs ask you which locale to use for case conversion.
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.
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.
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?).
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?).
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.
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.
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.
> How exactly are you sure that the email is encrypted and is read only by the intended receiver and not by anyone else?
Same way you make sure that the password reset links sent to your email are only received by you and not by anyone else?
Same way you make sure that the password reset links sent to your email are only received by you and not by anyone else?
This! It's like everyone has already implemented email based login (password resets) but chooses more complexity by adding a password.
I wish every site did this. Especially for non technical users, passwords are such a mental barrier.
I wish every site did this. Especially for non technical users, passwords are such a mental barrier.
And how do I log into my email account to access this one time link?
Edit: Even if it's an account held on a private server, there must be a password, must there not?
Edit: Even if it's an account held on a private server, there must be a password, must there not?
Theoretically you could use x.509 certs and a key stored on a smartcard type device, but sure.
Point is, this advice is probably aimed at developers who aren't working on email systems.
Point is, this advice is probably aimed at developers who aren't working on email systems.
Provisioning and maintaining the certificates/keys across even a small user base is a huge pain compared to letting users choose their own passwords.
Hence theoretically. :)
> 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...).
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...).
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...
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.
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.
That pretty much requires you to use something like 1password which if hacked (your error or theirs (who knows how good some random companies security is)) then you are completely screwed as all of your accounts are now compromised. To make matters worse, you don't know any of your passwords so you cannot even log onto any of your accounts to change them (this is also a big problem if you have a customer service problem as it will lock you out of all your accounts).
I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.
I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.
> That pretty much requires you to use something like 1password
That's the point.
> you don't know any of your passwords so you cannot even log onto any of your accounts to change them
Nearly every service allows email-based password reset.
> I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.
For most people, their entire identity relies on the security of their email address plus some information they shared on Facebook.
That's the point.
> you don't know any of your passwords so you cannot even log onto any of your accounts to change them
Nearly every service allows email-based password reset.
> I'm not a security engineer but this sets off all of my internal alarm bells when my entire identity relies on the security of 1 unrelated company that I pay a few bucks a month for.
For most people, their entire identity relies on the security of their email address plus some information they shared on Facebook.
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.
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.
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.
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.
I've considered using "magic login link" emails but greylisting[1] seems to be an insurmountable problem.
[1] https://en.wikipedia.org/wiki/Greylisting
[1] https://en.wikipedia.org/wiki/Greylisting
Generally greylisting is supposed to let future emails through once it establishes that a server will re-send. It should be possible to detect greylisting and warn the user.
"Your email provider temporarily rejected our email to you. We will retry in a few minutes. If this happens persistently, please (check our guide for your provider, $MAJOR_PROVIDER|contact your provider) to figure out how to whitelist our login emails"
"Your email provider temporarily rejected our email to you. We will retry in a few minutes. If this happens persistently, please (check our guide for your provider, $MAJOR_PROVIDER|contact your provider) to figure out how to whitelist our login emails"
Isn't the former what Mozilla Persona was trying to provide? A shame that was canned.
We built a successor project under https://portier.github.io/. Alive and kicking :)
> My (probably unpopular) opinion is that passwords should be randomly generated by the service, and not possible to change to a user-selected value.
I would rather have a client side TLS certificate that's generated by the website I'm trying to log into when I create an account with them. You could still keep the username and password application level log in in addition to the certificate to get a second authentication factor.
I would rather have a client side TLS certificate that's generated by the website I'm trying to log into when I create an account with them. You could still keep the username and password application level log in in addition to the certificate to get a second authentication factor.
Did you ever use StartSSL? They did TLS client auth and it was surprisingly terrible.
TLS implementations themselves need to get a LOT better about describing error conditions before client certs will ever be a viable option for actual user authentication.
Could that be something that a web browser or other client could translate to a more user friendly message?
I never had the opportunity and, according to their website, they closed last month. Since I can't try it out myself, what was so bad about it?
If the password is randomly generated by the service then you need a way to present the password to the user in plain text. I think you're trading 1 problem for another.
If your users are getting pwned because they reuse their easy leaked passwords on your service, then that's the real world adversary.
Also, all passwords appear in plaintext at some point. Even when sitting in a type="password" field that was autofilled by your uber secure password manager.
The main problem is that this solution is just pointlessly bad UX for most sites. But worth it (or something like it) if your users are losing real money.
Also, all passwords appear in plaintext at some point. Even when sitting in a type="password" field that was autofilled by your uber secure password manager.
The main problem is that this solution is just pointlessly bad UX for most sites. But worth it (or something like it) if your users are losing real money.
That's fine. Storing passwords in plaintext is the problem.
It could be displayed as selectable/copyable but not visible text by default with a "reveal" button to prevent shoulder surfing.
It could be displayed as selectable/copyable but not visible text by default with a "reveal" button to prevent shoulder surfing.
Yes, that "show once" feature works well for keys / tokens because developers usually use them right away in their app so it doesn't get lost.
But for a regular person, you may put them into a deadlock if you generate a secure random 16 character password with 1 chance to remember it.
Just imagine dropping "K@!G-:)XTqqy<44x" in front of a regular user telling them they have 1 shot to store this password before it disappears forever.
Most people who aren't into tech are just going to give up and leave IMO. It took me like 5 minutes to explain case sensitivity to my dad who knows computers well enough to do day trading but calls me up for things like "why can't I login to my email?". Asking him to type in a password like that would probably give him a stroke.
Emailing it to them in plain text is also not a reasonable solution. Not only is it wildly insecure, but you would be surprised at how many people don't know how to copy / paste text.
But for a regular person, you may put them into a deadlock if you generate a secure random 16 character password with 1 chance to remember it.
Just imagine dropping "K@!G-:)XTqqy<44x" in front of a regular user telling them they have 1 shot to store this password before it disappears forever.
Most people who aren't into tech are just going to give up and leave IMO. It took me like 5 minutes to explain case sensitivity to my dad who knows computers well enough to do day trading but calls me up for things like "why can't I login to my email?". Asking him to type in a password like that would probably give him a stroke.
Emailing it to them in plain text is also not a reasonable solution. Not only is it wildly insecure, but you would be surprised at how many people don't know how to copy / paste text.
You would still offer a "password reset" feature. Tell them to write it down or keep it in a password manager, and provide links.
Maybe call it an access code rather than a password to avoid "don't write down your password" training.
Maybe call it an access code rather than a password to avoid "don't write down your password" training.
Everyone would have to get on board with that at the same time. If the user is forced to memorize the password your service generates, they'll use it for everything else anyway.
How many people are going to memorize something like this?
fvtwt gvltv wlbth wgwdh njfnn
fvtwt gvltv wlbth wgwdh njfnn
The service should not ever get hold of an unencrypted password.
For a website, that's hard to achieve. You can ship some JS to pre-hash the password, but an attacker that can read unencrypted passwords from the server can probably also modify that JS code to send the original password to them.
If you have clients that run locally (and for which the updates are hopefully signed offline), I do think that approach is sensible.
If you have clients that run locally (and for which the updates are hopefully signed offline), I do think that approach is sensible.
Not storing passwords on the server removes some of the incentives to break into the server, and makes a quick and covert heist impossible.
If the server requires me to send it the md5 of my password (for example), it still has to store something to validate the password, which can then be cracked.
Sure, the server should expect a bcrypt hash, and only store a bcrypt hash.
OTOH maybe requiring client to compute the hash is sometimes too drastic. Sending the password to the server via a properly encrypted channel (https) may be fine, provided that the server never stores it, and just uses it to compute a hash for comparison. Then my original point does not hold.
OTOH maybe requiring client to compute the hash is sometimes too drastic. Sending the password to the server via a properly encrypted channel (https) may be fine, provided that the server never stores it, and just uses it to compute a hash for comparison. Then my original point does not hold.
#1 best practice for managing passwords is: don't try to implement password management yourself because you will get it wrong.
Eh, I disagree with that. Using a third party solution for password management/account logins has its benefits, but it also has quite a lot of downsides too. Such as:
1. Forcing people to create an account on a service they don't use or trust to access your website. Remember, quite a lot of people despise Facebook and Google, and by forcing them to use those services, you're making them choose between their privacy and your service.
2. Giving said services too much leeway on how the setup works. Do Facebook or Google or Twitter or whoever now charge money to use their account login system? If so, tough luck; you're gonna have to either rework your whole system or pay up.
3. Giving said services too much control in general, and letting them centralise the internet. This is a bad thing for numerous related reasons, ranging from easy access to personal data for tyrants to dependence on a walled garden run by a large corporation).
4. Making them the world's number 1 target for hackers. Admittedly they're already likely this, and homegrown systems have their own security issues in this department, but I certainly don't like the idea that the whole of the internet is basically now compromised the minute a data breach hits Google or what not. Any centralised system is basically a giant bullseye for every bad actor on the planet.
So no, it's not necessarily accurate that no one should try and implement password management or account systems or farm it out to third parties. That's a good way to give whatever controls remains over to large corporations.
1. Forcing people to create an account on a service they don't use or trust to access your website. Remember, quite a lot of people despise Facebook and Google, and by forcing them to use those services, you're making them choose between their privacy and your service.
2. Giving said services too much leeway on how the setup works. Do Facebook or Google or Twitter or whoever now charge money to use their account login system? If so, tough luck; you're gonna have to either rework your whole system or pay up.
3. Giving said services too much control in general, and letting them centralise the internet. This is a bad thing for numerous related reasons, ranging from easy access to personal data for tyrants to dependence on a walled garden run by a large corporation).
4. Making them the world's number 1 target for hackers. Admittedly they're already likely this, and homegrown systems have their own security issues in this department, but I certainly don't like the idea that the whole of the internet is basically now compromised the minute a data breach hits Google or what not. Any centralised system is basically a giant bullseye for every bad actor on the planet.
So no, it's not necessarily accurate that no one should try and implement password management or account systems or farm it out to third parties. That's a good way to give whatever controls remains over to large corporations.
I don't think its necessary for said third party solution to be a service. Most frameworks have builtin support or well written libraries that do the password management/login stuff for you.
Maybe that's good advice for a beginner, but I don't see how you can say that seriously as a professional.
Authentication is such a core part of the UX of your product. You should know how it works. If you're factoring out to a black box because you couldn't do it yourself, then I'm not convinced you're any more secure.
If your team is too incompetent to do it correctly (there are so many resources online), then how are they going to do anything else correctly, like ensure I can't access your private messages when I change /<my_id>/messages to /<your_id>/messages in the URL bar, or query the database without sqli?
This "don't do it, it's too hard" meme does nothing but scare people away from core competencies of our profession.
Authentication is such a core part of the UX of your product. You should know how it works. If you're factoring out to a black box because you couldn't do it yourself, then I'm not convinced you're any more secure.
If your team is too incompetent to do it correctly (there are so many resources online), then how are they going to do anything else correctly, like ensure I can't access your private messages when I change /<my_id>/messages to /<your_id>/messages in the URL bar, or query the database without sqli?
This "don't do it, it's too hard" meme does nothing but scare people away from core competencies of our profession.
That's exactly what I was thinking. Using OAuth logins from Google, Facebook, etc. saves a lot of pain.
I had a lot of trouble implementing social logins the other day so it's not completely painless either.
For example if you have multiple social logins, what do you do if the user forgets which account(e.g., google or facebook) they used?
You could just let them login with any as long as the email matches. But then what if you have a social login type that doesn't require verified email? For example let's say you add an imgur login but the user doesn't have an already have an account there. Then an attacker can just create the imgur account with that unverified email and then use that to log into the same email on your site.
There's also a bunch of edge cases with handling users who use different emails for different social accounts so you can't assume one-to-one correspondence between email address and users anymore.
And there's a bunch of other issues with how to initialize a good default display name from these different social profiles. And also the issue with how to handle if they unlink all their social login methods. And how/who to send reset password. And so on and so forth.
In the end this was all too hard and I gave up and only allowed logging in with google and google only. Which kind of sucks.
For example if you have multiple social logins, what do you do if the user forgets which account(e.g., google or facebook) they used?
You could just let them login with any as long as the email matches. But then what if you have a social login type that doesn't require verified email? For example let's say you add an imgur login but the user doesn't have an already have an account there. Then an attacker can just create the imgur account with that unverified email and then use that to log into the same email on your site.
There's also a bunch of edge cases with handling users who use different emails for different social accounts so you can't assume one-to-one correspondence between email address and users anymore.
And there's a bunch of other issues with how to initialize a good default display name from these different social profiles. And also the issue with how to handle if they unlink all their social login methods. And how/who to send reset password. And so on and so forth.
In the end this was all too hard and I gave up and only allowed logging in with google and google only. Which kind of sucks.
https://stackoverflow.com/users/login
I don't remember if I used Google, Facebook, or SO's own auth when I created my SO account. Some sites have upwards of 5 to 10 different ways to login and I find it very confusing.
I don't remember if I used Google, Facebook, or SO's own auth when I created my SO account. Some sites have upwards of 5 to 10 different ways to login and I find it very confusing.
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?
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?
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...
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.
https://blog.plan99.net/building-account-systems-f790bf5fdbe...
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.
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).
> SMS 2FA auth has been deprecated by NIST (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.
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.
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
[Out of band verification] using SMS is deprecated, and will no longer be allowed in future releases of this guidance
ah, thanks!
> Allow users to change their username
Does Google allow me to change the username of my elementary-school aged gmail account?
Does Google allow me to change the username of my elementary-school aged gmail account?
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.
> 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.
Do not tell them this, they will completely disable your account.
> 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.
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.
You store plaintext passwords? Interesting... where do you work? What’s your tech stack? Oh and what’s your name? ...
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
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
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-prac...
>> 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.
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.
(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".
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)
* 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".
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).
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).
If you delete your account on Facebook, I would think that it doesn't delete various information it stores about your social graph and various metainformation about you. And I would think that because it maintains that information for you even if you don't have an account. See https://www.dailydot.com/news/facebook-shadow-profiles-priva... for a brief rundown. I have yet to see any proof, or indeed any claims, to the contrary by Facebook.
Similarly, you can delete your emails from Gmail and your calendar data from Google calendar, but you cannot delete the metainformation consisting of their tracking data and so forth.
Which is what privacypoller was saying: you can remove _your_ access to some of this stuff, but you can't remove all the information they are collecting about you.
Similarly, you can delete your emails from Gmail and your calendar data from Google calendar, but you cannot delete the metainformation consisting of their tracking data and so forth.
Which is what privacypoller was saying: you can remove _your_ access to some of this stuff, but you can't remove all the information they are collecting about you.
Note that deleting your Reddit account doesn't delete your comments.
You can delete your comments manually (but of course only before deleting the account).
You can delete your comments manually (but of course only before deleting the account).
(I work for Google, opinions are my own)
https://support.google.com/accounts/answer/32046?hl=en
Google does let you delete your account. But it can take a few weeks for all the data to be really deleted (there is a recovery period, then some lag to delete everything).
https://support.google.com/accounts/answer/32046?hl=en
Google does let you delete your account. But it can take a few weeks for all the data to be really deleted (there is a recovery period, then some lag to delete everything).
Doesn't Google have tons of old backups in cold storage? Are those old database records also cleaned up?
I can't say what or whatnot Google does. Ask customer support on that.
But do know that GDPR will require this for the EU. https://gdpr-info.eu/art-17-gdpr/
But do know that GDPR will require this for the EU. https://gdpr-info.eu/art-17-gdpr/
It takes longer for data to get purged out of backups than it does for the live data stores, but Google does clean up backups for deleted account data.
[deleted]
I hope someone at HN is listening to that recommendation.
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?
Does anybody have any data on the percentage of users that refrain from using Google/Facebook and always create email accounts?
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
So has anyone got a guide on implementing the relevent portions of these best practices in ADFS?
Check out Azure AD. Most of the best practices are implemented there.
> 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.
The highly trusted Google and Facebook indeed. Nothing like a fresh oxymoron to start my Sunday.
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.
Leave it as Hunter2 and call it a day
[deleted]
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.