Basically you’re advocating case-insensitive passwords. No need to detect caps lock for that, just toUpper the string 
No, I don’t. Your suggestion costs n bits of entropy, where n is the length of user’s password.
I suggest to sacrifice 1 bit of entropy. It’s quite different.
1 Like
I wonder if the shift behavior you mention is common place.
For uncommon behavior users, such as you or me (I have caps lock disabled), my suggestion sacrifices 1 bit of entropy and nothing else, so I don’t see much downside.
It would be great if SQRL had some serious backing - it has the potential to be a great alternative to the whole username/password plague. It’s something we desperately need!!
The whole way through this article I was thinking: all of this would be irrelevant if we could just all use SQRL. If your reading this and you follow the link please don’t let the website scare you off. It’s hideous yes, but the ideas involved legitimately solve the problem of passwords on the web.
roblockyer is right that Gibson’s website describing SQRL is lacking aesthetic appeal. http://sqrl.pl/blog/ provides a quality explanation of the technology with a much better eye for page design.
I watched the Last Lecture multiple times, and I have no doubt the man was probably one of the best CS instructors in existence. However, I fail to see how this “What would God do?” (WWGD?) conceit helps at all.
Take your example of sorting. God would just perform a bogosort, with the twist that his first try works every time. How does that help me? Does it mean I should start with bogosort in analyzing a sorting problem? I sure hope not.
The answer is it doesn’t help me at all. I’m right back where I started. Not having omniscience and omnipotence, I actually have to work at the problem.
Sure you should always have the goal to make things as simple as possible for both the user and the code. If that’s what you are trying to say, why not go straight to that? I’m just not seeing where dragging in an entity that doesn’t have the same problems I have (or in fact any problems) clears things up in the slightest.
A few thoughts:
-
Was there some discussion about (not) having a “remember me” checkbox?
-
In terms of allowing a user to change their e-mail, that probably means you have an internal account ID which is not their e-mail address. Theoretically that’s an implementation detail and not UX, but it’s one that makes the UX work reliably so worth mention. There’s also the question of what happens if you lose access to an e-mail address and need to get back in to the account.
-
In the end, because of what I think was some maintenance going on on this site that I had the bad luck to hit, it took me a couple hours to sign up and post this. Which makes me think of a a higher level issue - isn’t the “God algorithm” for a public forum one that makes sure a user can post a comment and it won’t get lost? Ideally, I’d be able to post my comment first and then worry about logging in, signing up, etc. - by the time I’ve gotten the confirmation e-mail, etc. I’ve opened a few other browser tabs and possibly gone on to do other things altogether. (Maybe this is a way to ensure quality but then again the trolls may me more likely than anyone to come back.) For example, ask me for my comment and an e-mail address (with the usual “e-mail will not be public” thing) then when I post, let me know that you’ve save my comment but since I’m not logged in, you’ve sent me an e-mail with instructions to create an account which I need to do before my post will show up. Or something like that.
Very informative, we are in the beta phase of our web application and we are doing analytics using some of the information provided here. Can’t wait to see the result!
@robertlagrant He is not advocating pass phrase case insensitivity, he is saying you should accept the EXACT opposite case of the “correct” pass phrase as valid. Example: if the “correct” pass phrase is ‘thisisapaSSphrase’, then you would also accept ‘THISISAPAssPHRASE’ as well, but you would NOT accept ‘THISisapassphrase’. The end result is that exactly 2 pass phrases are valid, instead of exactly 1. That does not significantly harm the security, unless I am mistaken.
I am pretty sure this is how Facebook does it.
1 Like
If I logged into every website with Google, and the access to Google was compromised - bum, all my accounts would be compromised too.
So, the more places you use your Google account to log in, the more danger is there for that Google account to be compromised.
In other words, maximum security is needed if using a single account to login in multiple places - e.g. at least two-factor authentication or yubikey or whatever.
I prefer using password managers and a unique password for every single website. Plus two-factor where possible. This way, even if my passwords storage account is compromised (e.g. Roboform Everywhere, LastPass etc), no access is gained to all my accounts. The accounts that, similar to the-Google-case, use a single website to log in, but in some other sense this time.
CodingHorror, I’d add that one should test their login screen with all popular passwords manager tools as well.
1 Like
I agree, and if that means loading the login form in your ajaxed website and just hiding it from view, so be it.
So many ajaxed SPAs nowadays don’t work correctly with password managers because they search the page for login forms after page load, not periodically.
So requesting and injecting the login form after pageload, may get in the way of a lot of people’s login workflows.
How do you handle international keyboards with regards to special characters or do you offer this on only alphanumeric passwords ?
Wouldn’t logging in be simpler without passwords at all?
This is how my wife uses most websites:
- go to site
- click lost password
- check email for password
She rarely remembers her passwords, especially for infrequently used commerce websites. The passwords are an annoyance, and they are a definite security weak point. Most people don’t use password managers, and most people are not capable of being imaginative enough to generate a decent password per website.
For a lot of real users out there, wouldn’t it be better as just:
- go to site
- enter email
- click link in email
Just send a link with a one-time / time-limited key to the one place she knows and hopefully has a strong password. This is effectively how my wife uses most websites anyways, and could we improve security by removing the fallacy that we need this password at all?
Also, this saves her time from creating a new password, going through a few more dialogs, etc. In commerce you want to remove barriers; the longer it takes to process a sale, the more sales you lose.
Maybe we just call it poor mans offline oath.
2 Likes
What removing the login button altogether?
As a user types their password, constantly check whether it’s accurate or not by sending requests to the server. When the user hits the right password, you automatically log them in. There are some security issues involved, but they can be dealt with.
@codinghorror I’ve noticed that Discourse’s behavior has changed in the meantime. You no longer tell people whether they’ve entered a valid email address. Instead they just get a general “Incorrect username, email or password” error message.
What caused you to change your mind?
I just tested on meta.discourse.org in an incognito window and that’s not the case…
If you see some other message, someone has switched off the “tell people when they type in an invalid email” feature in their Discourse site settings. Because technically this exposes a bit of information, though I think the cost/benefit to end users of hiding the email hit (or non-hit) on password reset is totally not worth it.
1 Like
Oh, I see. You show a specific error when trying to reset the password, but a general error when trying to log in.
What’s the reason for this difference? Why not give the user who tried to log in the same information?
Generally you are most concerned about this at the time of password reset. Nobody’s ever asked for outside of forgot password, to my knowledge.
OH! Thanks. I massively misunderstood.