91–100 of 520 posts
Could web developers and password manager developers get together and develop a standard web API for authenticating with a website? I want to specify a URL and have my password manager run a behind-the-scenes conversation with the website and, ultimately, drop me into the home page in a logged-in state.
There was this HN post a bit ago: Relevant Link: https://wicg.github.io/change-password-url/index.html HN comments: https://news.ycombinator.com/item?id=18618193
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…
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.
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…
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.
I would go further than this: don't get clever with logging in. Here's a list of "don't"s: - DON'T arbitrarily restrict my password from being too long - DON'T arbitrarily restrict me from using special characters - DON'T arbitrarily me require to use certain classes of characters (eg 1 uppercase, 1 lowercase and 1 number as a requirement; see https://xkcd.com/936/ ) - (this is a big one) DON'T TRY AND STOP ME PASTIN…
Imo one key point is missing: Don't give users the option authenticate via Google or Facebook. While it may be convenient at signup, it creates an unneeded dependency and confusion if you forget how you log into a certain site.
It is funny how trends shift. A few years ago there was a glutton of articles telling us that we cannot do authentication correction, and to just offer single-sign-on via Facebook/Google instead. Now everyone is back to doing their own home-grown, and Facebook/Google authentication is seen as bloat.
A few years ago, there was much less understanding of the privacy implications of centralized authentication, and much more trust of big tech companies like Facebook and Google.
I would go further than this: don't get clever with logging in. Here's a list of "don't"s: - DON'T arbitrarily restrict my password from being too long - DON'T arbitrarily restrict me from using special characters - DON'T arbitrarily me require to use certain classes of characters (eg 1 uppercase, 1 lowercase and 1 number as a requirement; see https://xkcd.com/936/ ) - (this is a big one) DON'T TRY AND STOP ME PASTIN…
This actually includes all of your rules and others, such as excluding use of password hints and server-specified “security questions” (which are just a kind of weak password used to protect a stronger password), and accepting Unicode.
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…
> 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Óöð
Do: If the username is always the users email, call the field "email" and not "username". (Looking at you, ComEd)
There's been a recent tendency to split login forms into username/password over two screens as mentioned in this article. It's maddening. Password managers can't deal with this, unsurprisingly. I don't see the benefit this provides for anyone.
>Password managers can't deal with this, unsurprisingly Maybe I'm overly paranoid but I choose to manually copy my passwords out of my manager into the login form. Then again I also use a PW manager that doesn't support cloud storage. (Though you could always throw your DB into Dropbox if you desired)