5 ms·

My list: 1. Don’t have your website take a longer password than your mobile app and then not let correct passwords login inexplicably 2. Don’t break completel

My list: 1. Don’t have your website take a longer password than your mobile app and then not let correct passwords login inexplicably 2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code. 3. Don’t mess up MFA if you’re a financial app logging into a 3rd party bank for a user by trying to replay a token code 4. If you login to any 3rd party services on behalf of a user, support a method that doesn’t require asking the users for their password such as OAuth2

Solvitieg 8y ago
My biggest one is... Requiring users to login with a username or customer id. (instead of email).
- iscrewyou 8y ago
  Yeah, this is the biggest one. I remember Google used to do it too! (Not sure if they still do because I haven't tried it). Google would let you log in into your google account with a yahoo email address (or any email address I presume) as the google id. It threw me for a loop the first couple of times.
  - frosted-flakes 8y ago
    My username/email address for my Google account is not a GMail address. I don't use GMail, and it would be ridiculous if I was forced to create a GMail address to be able to sign in to YouTube, etc.
- Casseres 8y ago
  My biggest (related) one is… In the sign-up process, validate the email (don't trust the user). I get a lot of emails that companies never validated, including for a while, from Wells Fargo.
  - wccrawford 8y ago
    I was getting insurance claim information from a large company in another state for a while. I finally made a big enough stink that they took my email off the account. And yeah, I'm sure it was the real company and not some phishing emails.
  - curun1r 8y ago
    Unfortunately, the trend is in the opposite direction. People have realized that email validation is a step in the funnel where you lose users. And when you look at it as a funnel conversion optimization problem, you arrive at myopic conclusions that are insecure and have externalities like the one you noticed.
    - deleted 8y ago
      [deleted]
  - funkymike 8y ago
    This bugs me as well. American Express kept sending me information about someone else's credit card. It took arguing with their customer service for about 20 minutes to get them to remove my email address from the account.
- Ayesh 8y ago
  I always hesitate to even use a service that has customer IDs. Most of the frequent flier programs have numeric IDs and there's no way I'm going to remember them. It makes things worse because you don't always have a password manager-enabled device when you travel. There is also a bank in my country that your login username is first name+birth year. It's even worse than an email address as username.
- trizic 8y ago
  In my experience I am glad that banks don't use email as login. Most sites compromised were using email as login which is now input for bots to test on other sites. Having a unique login ID per site such as using myemail+xyz@gmail.com could help.
theandrewbailey 8y ago
> 2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code. I can't tell you how many sites won't allow passwords with quotes, apostrophes, or colons. (too concerned about SQL injection, are we?) And too many don't like high ASCII characters in passwords; no one's going to guess something like úú©íWq¿S®&ßþDx¼åi4ÒÀÛ'ÓªýS.¾¥ùìbÓöð
- guitarbill 8y ago
  Or god forbid you try and use a non-English password... Unicode exists for a reason.
  - Sammi 8y ago
    All character related issues disappear when you hash the password. There is no problem here. Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.
    - ben509 8y ago
      You have to get the data out of the text form. Unicode passwords mean all text entry forms on all browsers using all operating systems must be returning identical data, or at data that can be normalized to be bitwise identical without discarding the accents. While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of users. And users have to get text into the form. You're allowing users to shoot themselves in the foot if they use accents and then using a keyboard without those accents or one where entering the accents is very tedious.
      - Sammi 8y ago
        Ehhh no? I am at least not aware of any differences in utf-8 compatibility between browsers or other library implementations. UTF-8 is old and extremely standardized.
curun1r 8y ago
Some other ones: 1. Don't disable paste on the password box. Pasting usually means a long, complex password and that's a good thing. 2. Don't limit allowable characters or have an artificially low max-length. It's okay to cap it for DoS purposes, but anything shorter than 64 characters (which maxes out to 256 bytes, given unicode) means you're doing something wrong on the backend. 3. SMS is not MFA. I'm terrified by the number of banks accounts that could be accessed by hijacking my SIM. It is inexcusable.
guitarbill 8y ago
5. Don't force password rotations. 6. Don't force me to use certain character classes if my password is long enough and therefore entropic enough without them. Special characters suck and are inconsistently supported.
- FabHK 8y ago
  Yes and yes... How come huge institutions can't follow password best practices?
- kccqzy 8y ago
  At work I once proposed a solution to address 6. Basically we want to accept either a short password with many different character classes, or a long one with just lower case (or something similar). We tried a prototype where we used zlib to compress the password and measure the compressed length as a proxy for its complexity. I really liked this solution but we didn't adopt it because it's literally unexplainable to normal users.
- adrianmonk 8y ago
  My workaround for #6 is that basically all passwords are auto-generated to include A-Z, a-z, and 0-9. If this doesn't pass character class muster, then I manually append something like "-" to the end of the generated password. I've already got my entropy needs met in other ways, and "-" is special enough to be considered special, but not special enough to be unsupported. In other words, sorry for the pun, but I have special token that I use as a token special.
smhinsey 8y ago
Tivo hosed me on a version of item 2 a while back. My Tivo account is ancient, and when I created it the old email+gibberish@gmail.com trick worked fine. A year or so ago they released a new version of their site that wouldn't accept that email as valid. I was eventually able to sort it out but it required escalating the request several times as apparently even CSR tools couldn't handle the + in my old email and they were also unable to interact with the account. Good times.
_asummers 8y ago
My ire is when a password manager generated password has too many special characters, is too long, or any number of trash restrictions that ultimately cause me to use a manually generated password to get around the restrictions.

Solvitieg 8y ago

My biggest one is... Requiring users to login with a username or customer id. (instead of email).

iscrewyou 8y ago
Yeah, this is the biggest one. I remember Google used to do it too! (Not sure if they still do because I haven't tried it). Google would let you log in into your google account with a yahoo email address (or any email address I presume) as the google id. It threw me for a loop the first couple of times.
- frosted-flakes 8y ago
  My username/email address for my Google account is not a GMail address. I don't use GMail, and it would be ridiculous if I was forced to create a GMail address to be able to sign in to YouTube, etc.
Casseres 8y ago
My biggest (related) one is… In the sign-up process, validate the email (don't trust the user). I get a lot of emails that companies never validated, including for a while, from Wells Fargo.
- wccrawford 8y ago
  I was getting insurance claim information from a large company in another state for a while. I finally made a big enough stink that they took my email off the account. And yeah, I'm sure it was the real company and not some phishing emails.
- curun1r 8y ago
  Unfortunately, the trend is in the opposite direction. People have realized that email validation is a step in the funnel where you lose users. And when you look at it as a funnel conversion optimization problem, you arrive at myopic conclusions that are insecure and have externalities like the one you noticed.
  - deleted 8y ago
    [deleted]
- funkymike 8y ago
  This bugs me as well. American Express kept sending me information about someone else's credit card. It took arguing with their customer service for about 20 minutes to get them to remove my email address from the account.
Ayesh 8y ago
I always hesitate to even use a service that has customer IDs. Most of the frequent flier programs have numeric IDs and there's no way I'm going to remember them. It makes things worse because you don't always have a password manager-enabled device when you travel. There is also a bank in my country that your login username is first name+birth year. It's even worse than an email address as username.
trizic 8y ago
In my experience I am glad that banks don't use email as login. Most sites compromised were using email as login which is now input for bots to test on other sites. Having a unique login ID per site such as using myemail+xyz@gmail.com could help.

theandrewbailey 8y ago

> 2. Don’t break completely on valid passwords because there’s a char you didn’t expect, testing is a good thing in security critical code. I can't tell you how many sites won't allow passwords with quotes, apostrophes, or colons. (too concerned about SQL injection, are we?) And too many don't like high ASCII characters in passwords; no one's going to guess something like úú©íWq¿S®&ßþDx¼åi4ÒÀÛ'ÓªýS.¾¥ùìbÓöð

guitarbill 8y ago
Or god forbid you try and use a non-English password... Unicode exists for a reason.
- Sammi 8y ago
  All character related issues disappear when you hash the password. There is no problem here. Hashing the password should be the very first step taken on the backend when receiving login data, so any special characters should be neatly isolated to a part of the code that can handle UTF-8.
  - ben509 8y ago
    You have to get the data out of the text form. Unicode passwords mean all text entry forms on all browsers using all operating systems must be returning identical data, or at data that can be normalized to be bitwise identical without discarding the accents. While that may be doable, it would require aggressive testing to actually work... for a feature that's a. not necessary and b. of interest to a tiny minority of users. And users have to get text into the form. You're allowing users to shoot themselves in the foot if they use accents and then using a keyboard without those accents or one where entering the accents is very tedious.
    - Sammi 8y ago
      Ehhh no? I am at least not aware of any differences in utf-8 compatibility between browsers or other library implementations. UTF-8 is old and extremely standardized.

curun1r 8y ago

Some other ones: 1. Don't disable paste on the password box. Pasting usually means a long, complex password and that's a good thing. 2. Don't limit allowable characters or have an artificially low max-length. It's okay to cap it for DoS purposes, but anything shorter than 64 characters (which maxes out to 256 bytes, given unicode) means you're doing something wrong on the backend. 3. SMS is not MFA. I'm terrified by the number of banks accounts that could be accessed by hijacking my SIM. It is inexcusable.

guitarbill 8y ago

5. Don't force password rotations. 6. Don't force me to use certain character classes if my password is long enough and therefore entropic enough without them. Special characters suck and are inconsistently supported.

FabHK 8y ago
Yes and yes... How come huge institutions can't follow password best practices?
kccqzy 8y ago
At work I once proposed a solution to address 6. Basically we want to accept either a short password with many different character classes, or a long one with just lower case (or something similar). We tried a prototype where we used zlib to compress the password and measure the compressed length as a proxy for its complexity. I really liked this solution but we didn't adopt it because it's literally unexplainable to normal users.
adrianmonk 8y ago
My workaround for #6 is that basically all passwords are auto-generated to include A-Z, a-z, and 0-9. If this doesn't pass character class muster, then I manually append something like "-" to the end of the generated password. I've already got my entropy needs met in other ways, and "-" is special enough to be considered special, but not special enough to be unsupported. In other words, sorry for the pun, but I have special token that I use as a token special.

smhinsey 8y ago

Tivo hosed me on a version of item 2 a while back. My Tivo account is ancient, and when I created it the old email+gibberish@gmail.com trick worked fine. A year or so ago they released a new version of their site that wouldn't accept that email as valid. I was eventually able to sort it out but it required escalating the request several times as apparently even CSR tools couldn't handle the + in my old email and they were also unable to interact with the account. Good times.

_asummers 8y ago

My ire is when a password manager generated password has too many special characters, is too long, or any number of trash restrictions that ultimately cause me to use a manually generated password to get around the restrictions.