There's also the Stack Overflow method for first-time users: no sign-up at all. Let them use the site anonymously but fully, and register at their leisure. I'm using that for a current project.
It works totally offline, and if and when you are ready to sync, it takes the locally stored stuff online. For bonus points, it continues to work offline too! :)
Scribble users totally love it. BUT - it really increases the amount of effort and complexity involved.
"Those options correspond to however you’ve authenticated with the site in the past. In my case choosing “Twitter” redirects me to Twitter for the standard auth dialog, and picking “Bagcheck” displays a standard password field."
As wgx suggests, it does look like the auto complete shows two Sacha user accounts. I presume this is before you get "those options to choose your authentication method".
97%+ of people don't care about passwords being sent in plain text over email for non-banking sites. Or for accounts that have no info until you populate them.
The other 3% can just log in and CHANGE the password after-the-fact.
I'd rather not inconvenience the majority of my signups, nor force my ideas on how things should work on them.
And what percentage would – like me – delete their account as soon as you send them a plaintext temp password?
You're living in the past if you think this is an acceptable practice. I don't care how trivial your web service is, if you're throwing my password around willy-nilly, I don't want you.
But usually, those links expire, or are only able to be used once. So the password the user creates is secure, and the period the attacker can use the captured link is only from the time the user requests the password reset until the time the user tries to use the reset, it doesn't work, and the user requests another reset.
When a user is sent a password via email, unless that user is required to change eir password upon entering it, it is inherently less secure than sending a link.
This isn't an attack for the downvote. But if you're the type of customer that flips out over getting your temp password in the mail to a blank account, I don't want you. As the troubles are only starting...
Nope. That would require the user to take more action that necessary, since they now have to click on a link and remember your password. It would also be less secure, since they may choose a bad password.
A. They don't need to remember any password. They're creating it for the first time.
B. Minimum password length/complexity. It's not hard to do.
I can't believe you're actually arguing that creating a new password is less secure than using an auto-generated password that was sent via email. I hope you are just confused...
Hell yeah it is less secure. password, letmein, 123456, j@nuary1
All bad passwords. All will be chosen by your users at some point. The last satisfies any complexity requirements I have ever run against in the wild.
There is nothing insecure about sending a plain-text password that compares to a badly chosen password -- email isn't that easy to intercept and properly nobody is hacking your users physical (or wireless) network. At least not compared to the number of people who will be attempting to crack their online password.
For most of your users creating a new password will be much less secure than giving them a password.
> B. Minimum password length/complexity. It's not hard to do.
It is hard to do. That's why so many people reuse passwords, or have hopelessly weak passwords. (Some word with a few vowels swapped for digits, or some word with two digits tacked on the end.)
I agree that sending passwords over email is sub-optimal, but the solution is not to surprise users with a password creation screen.
Are you taking the position that only auto-generated passwords can be secure? I'm trying to understand what conclusion to draw from your comment.
My point was that imposing length validations on passwords is not hard. Complexity validation, while more difficult, is also not exactly a novel problem.
I feel like I'm in bizarro-world with all these people telling me that sending a plaintext password via email is more secure than giving users the option to follow an authenticated link to create their own password because...users can't be trusted to choose good passwords?! Really?
Users are hopeless at creating secure passwords. They are especially hopeless at creating secure passwords if you suddenly present them with a password creation screen.
Adding complexity generation does not help. If anything, it makes things worse. People use stupid weak passwords, often re-using them across different websites. They'll do simple substitutions of digits for vowels, or they'll use one word with a couple of digits stuck on the end.
Complexity validation gives a false sense of security.
To sign up/in, you just enter your email and get a permanent signin token which you can use to log in whenever you like. You can also change this if it gets compromised.
1) User is asked to enter his email address
2) User is immediately logged in, and a generated password is sent to his email adress
The generated password is short and pronounceable, lower case only and avoids annoying characters like l, I, 1 etc. While most security experts would consider this password extremely insecure, it is in practice much more secure than any other password the user would choose because the user can't choose the same password he usually chooses. If my server becomes compromised, there's no risk to his other online accounts.
This approach might not be sufficient for a banking site, but it's probably enough to deter occasional mischief.
As a user I would like this flow, but as the site owner I worry about people misspelling their e-mail address. They would then proceed to do things under the account, but once their login expires they could never get back.
Show them the email in nice, big, centered letters after they sign up and let them edit it. I think it was Luke Wroblewski who said this approach reduces misspellings to a ridiculously low number.
You know what I would love? A strong generator for the password field. My browser remembers all my password but I still have to generate a strong one by myself, which is completely unnecessary. I don't even have to see it; in worst case, I will simply request a password reset.
I use SuperGenPass, a password-generating bookmarklet. Instead of storing your passwords (locally or on a server), SuperGenPass generates a strong, site-specific password by hashing your master password and the site's hostname. I remember just one master password, but no site has the same password in their database.
The problem is when some site has unusual password requirements that SuperGenPass can't support. Then I must make up and remember a password for that site. :(
> The problem is when some site has unusual password requirements that SuperGenPass can't support. Then I must make up and remember a password for that site. :(
PasswordMaker is similar to SuperGenPass, but you can create exceptions to your default password scheme on a site-by-site basis. So, you can use lower complexity and shorter passwords for sites that have bad password policies, but still use better passwords for those that support them.
A serious deficiency in PasswordMaker is that, by default, it ignores subdomains, so bbc.co.uk and evil.co.uk would share the same password. But if you enable the subdomain option, then www.bbc.co.uk and www2.bbc.co.uk then have different passwords.
I'm using the Firefox add-on version 1.7.8, with the default URL Components settings (subdomains not enabled), and it uses "bbc.co.uk" as the domain for "www.bbc.co.uk" and "evil.co.uk" as the domain for "evil.co.uk", so the problem you described doesn't exist.
Maybe this was a problem in an earlier version and it's been fixed?
Always amazed when I hear people use services like LastPass. Your password. In someone else's database.
I'm not saying LastPass (or any similar service) is bad. I am however amused at the anger we display when the likes of Path upload our contacts without our knowledge, while we voluntarily give our most sensitive data (passwords, and the locations they're used at) to a third party to manage.
1) Using LastPAss doesn't mean one stores sensitive passwords in it. You can memorize a few that really matter (email, bank, etc) and keep the rest there.
2) They claim it's secure:
This is important because your sensitive data is always
encrypted and decrypted locally on your computer before
being synchronized. Your master password never leaves
your computer and your key never leaves your computer.
No one at LastPass (or anywhere else) can decrypt your
data without you giving up your password (we will never
ask you for it).
An alternate, and which I use, is 1Password which doesn't store our database of passwords and whatnot on their services as it's a local file. You can sync it with Dropbox and it's therefore on Dropbox's servers but it's secured in some way. I remember trying LastPass but dropped it because of security worries.
You're definitely right about it being amusing at what get's people in a row. The main difference between this and the phone apps is that they deliberately chose to place their data with LastPass. So, it seems to be not the content but the authority that matters.
Remark: As far I know 1Password does not encrypt everything. Lets say you store a password in 1Password for twitter.com then the password is being encrypted but the information that the password is used for twitter.com is not. So someone could find out that you are using twitter simply by going through your 1Password file. This may be a problem with sites that are not as harmless like twitter.
I don't know how similar online password managers work, but I use PassPack. They store your whole encrypted password file in one field in their database, and the encryption/decryption is done only on the client side. The key is never transmitted over the internet.
This doesn't do anything to defend against client-side malware, but at least if their database is stolen the bad guys will be unable to decrypt your passwords (as long as your passphrase is strong enough.)
There is a weakness - they keep historical versions of your password file. Presumably because some customers forget their new passphrase but remember their old one and so they can recover their file, less any edits since they changed their passphrase. But if you changed your passphrase because your old one was compromised, the bad guys can now decrypt the old version and have a chance to get some still-current passwords from it.
Funny that Bagcheck is listed as a "good" example.
I was just commenting to someone as to how confusing that site is. There's a box next to the "JOIN" / "SIGN IN" words in the upper right, that is positioned next to those words (as if those words are the label for the text box).
So you start to key in your name, to join, and a bunch of choices are displayed. If you select one (even your own), you are whisked away to another page that isn't even the join / sign in part of the site. You are no closer to being signed in than you were before. And actually further than if you had clicked on the label for the text box that says "sign in" (which is actually a button or a link, although not identified as such, unless you happen to mouse over it).
Ends up the "join / sign in" text box is actually a SEARCH text box.
yeah, real simplified. Put the word "search" in there. geesh.
Actually it's worse than that. You're not happy with the fact that the Search input is too close to the "Sign in" text.
But the "Sign in" page asks you to type your name and then be offered the "sign in with…" option you used when joining.
So, the only thing it does is removing one button. (Twitter or Facebook) At this point, you still have to enter your login information for Facebook or Twitter.
A better solution IMO is to present directly "Sign in with Twitter" and "Sign in with Facebook". One thing you might be worried about is people who first joined with one and try to sign in with the other: does that create a new separate account? Do you put a warning? etc. But you can curb that by keeping a cookie of the sign-in method used and present that one with an option to see the other options. That's what RPXNow is doing IIRC (https://rpxnow.com/).
Two years ago we (UserVoice) removed the need for end-users to sign up or register. When submitting an idea, voting or commenting, they simply identify themselves with their email address – much like commenting on most blogs. This eliminated one of the biggest barriers for user participation: registration.
Later, if they want, users can confirm their address and add a password. This is optional, unless the user is an account administrator or is trying to access private content (in which case we do require to confirm and protect their identity for security reasons).
We also allow people to sign in with their Facebook or Google identity. Since those services return a verified email address, we can reconcile it with an existing user record if one exists. This eliminates another barrier for returning user participation: “Which 3rd party service did I sign up with last time?” and “If I choose the wrong service, will I accidentally create a separate user profile?"
Even if the user forgets, they can simply enter their email address and, if it’s protected with a password or FB/Google authentication, we prompt them with the correct method to use (while unprotected users don't need to authenticate at all).
Lastly, we removed the need to sign-in (or sign-up) before participating on the site. By asking users to identify themselves at the moment they want to participate and not requiring a registration process, participation is just as easy as leaving a comment on a blog. This, along with not requiring registration, eliminates the issue where new and returning users were interrupted by a sign-in/registration process in the middle of their existing workflow.
One thing worth noting is that this isn’t a one-size-fits-all solution for all online services. It works great for UserVoice and our customers since most users aren’t performing private or sensitive tasks.
I’m very excited to see more services focussing on creating great experiences when identifying new and returning users, and questioning whether common pre-conceived notions around these requirements are still necessary.
Eh, the user still has to go check their email to find whatever password has been assigned. That's an annoying step.
With the second example, I think it would be better to show both Facebook and Twitter logins. If the user authenticates with the wrong service, perhaps show a prompt encouraging them to authenticate with their other provider (Facebook or Twitter). Then you have both accounts authenticated and linked.
Still, in the grand scheme, all these signup and login schemes suck. Surely we can develop something better... ideas?
BagCheck is more of a good concept of a simplified login, but the implementation drops the ball.
I've looked into registration/sign up flows for a project a while ago, and I find it hard to group Pinterest invites into the "sign up" flow. Ultimately, Pinterest users still have to complete a registration flow once they receive an invite.
I think it's pretty difficult to break from some established webform design (lukew's book was pretty good regarding web form design, but it's a bit old now) for registration.
I may be splitting hairs, but I ultimately consider some of the onboarding steps used to increase conversions part of a broader "conversions" flow with the "sign up" flow within that. Pinterest may increase conversions and give an illusion of simplicity, but the actua registration flow is hardly simplified by adding the invite step.
Authentication on most of the web is directly connected with an email address.
If you have access to an account's email, then you can have access to the account.
Since most people have their email always open, or at least a click or two away from being open, why not skip the password creation altogether?
Users are presented with an email field and a button saying something like, "Send me a key to login".
An email is sent that contains a direct login link with a temporary token. Login tokens would quickly expire, but cookies could keep the user logged in to the site for extended periods of time.
This would be as secure as any password reset system, without having to go through the hassle of setting and remembering a password. It also prevents users from creating week passwords or using the same password across many sites.
While I see that is solves some issues I actually know few non-tech web users that keep their email constantly open. Implementing this would also remove the convenience of password saving tools.
Also, if all you need is an email to log in, if my email is compromised I have little to no indication that the offender has logged into that service if they delete the email. With the current web standards, if someone reset my password vie email I would no longer be able to log into the account. With your suggestion, my email could be compromised, services could be logged into and I would have no indication.
Some of these problems could be solved, but I'd say the biggest problem now is that it's very far removed from typical web standards.
FWIW, until reading this article, I never thought one could just sign up for a Pinterest account randomly, so I never did. I had wanted to use the site, wanted to get an account, but was like "Request an Invitation?... bah, maybe I'll come back later".
But one can get a list of usernames from this site. One can then see which passwords are on a known password list, and then one has a list of usernames and passwords to try against other services.
Bagcheck doesn't seem to have a limit of the number of attempts you get to type the correct password, either, so one can run a full dictionary attack on the passwords too.
There's a reason no-one else does login like this.
It definitely does address some of these problems, but raises others.
First and foremost is denial of service. If the identity toolkit goes, so does access to everything it issues tokens for.
To be absolutely fair, I've not used the toolkit so don't know whether I could use a Hotmail account when my Gmail account is inaccesible.
A business risk you take on is reliance on their T&Cs. It may (or not) be worthwhile planning a mitigation or contingency, depending on the value of your service.
The other part is that anything from Google is, by way of Google's business model, spyware. This is my (note: very personal) preference, but I don't use any Google products, services, or products or services that make use of anything from Google.
Regarding denial of service, does that not apply to any identity provider? OAuth, Facebook/Twitter sign in, all suffer the same problem. Perhaps I have too much faith in their systems, but I don't imagine downtime occurring in reality.
You are correct in assuming you can't use your hotmail address when Gmail is inaccessible, unless it was planned beforehand. As in, you can auth a second identity provider for the same account - which would be possible, but not as an afterthought - so probably useless.
I guess a careful read of their T&C's is a good idea, but what would you envisage as warning signals?
Spyware, well, if users signed up using gmail, google would know. That's most users anyway these days. But you're right, in using google analytics I'm providing them all this information anyway, so perhaps I'm less concerned.
Personally, I think the benefits outweigh the problems you've raised, but perhaps I'm being an optimist. If something did happen down the line, I would have to issue all users with a new password down the line, that would be frustrating, but not the end of the world as a mitigation strategy.
Having spoken to the product manager at google, I got the following response:
While there is no service level agreement (SLA) for the Google Identity Toolkit, Google itself uses the same infrastructure as GITKit to support federated login for Google accounts. Google users can even opt-in to use an Account Chooser in place of the traditional Google login box.
Sorry for the delayed reply. When I mentioned T&Cs I meant the risk that the provider you use changes the terms and conditions some time after you've deployed and have an established user base that relies on the provider's service.
Sigh. It uses OpenID and yet it gives you no option to put your own URL, and if you use Google Apps for your email, you have to use it as your IDP. How I love the corporatized web.
Is everyone ok with the password being mailed out in plain text? (as one of these flows does, and Hacker News does itself)
Even if doing this on password creation doesnt imply that the passwords are stored plaintext, by emailing out the password, it can be sniffed over wifi or unsegmented wired networks, or read on intermediate servers, in your caches, in your backups, etc. Fairly low-hanging fruit.
Same idea (one-time URI) but with client-side encryption and sender's email notification (including IP & geolocation of receiver): https://whisperpassword.com/
Nearly all websites mail out replacement passwords (or password reset tokens) in plain text. That is not good but is hardly unique to HN.
I was about to say "HN doesn't do SSL" but just tested and it does. I wouldn't make a habit of this though - the site struggles with current traffic levels as it is.
Password reset tokens are single-use. If the resets are time- and IP- limited then attacking them is awkward (reset a password while the victim's in the same room?)
I don't think "nearly all" is right. I've never worked on a site which mailed out plaintext passwords; and I can't think of a site I regularly use (other than HN) that does it. However, I tend to close accounts if sites mail me plaintext passwords - so my sample's a bit self-selecting.
We should stop being cute. There's no need to create new authentication schemes. Just stick with username, password, email, what's wrong with that? It's worked for us for so many years. Pinterest really isn't creating a new login scheme though, but BagCheck's is really adding unnecessary confusion in the marketplace.
Agreed. Except for the super-user crowd, I'd image changes in login and signup flow would generate more confusion that good. With a large enough user base, AB testing something like this could yield good results, but reinventing the wheel at an early stage isn't a risk I'd want to take.
Hell no it hasn't. Passwords are useful when you need one or two at most. On the nets you need one for each service you use and you have to remember it. Also you have to choose your username, which you have to remember too.
This scheme puts a lot less requirements on the users, since they only have to remember their email, which is public, non-secret and (presumably) easy to remember.
I just use 1 common password for every non-critical service and I make that password different from my email password. I stick with the same username as well.
I use 1 separate password for my critical services, and store it in EverNote, and I just copy/paste it when I log-in.
It's not such a huge pain. We as tech people always tend to over-abstract solutions to problems. But it has worked for the most part for 10+ years. Ask any regular internet user and they will tell you it's not a big deal. It's only when we invent new ways of logging in like FB Connect, when users start getting angry and spoiled, asking us "Where's FB connect?!".
Here's the question I have for Bagcheck: what happens when people have the same name? Since these are human names and not unique usernames, you're bound to get collisions. Are you relying on users identifying themselves from a tiny profile image? If anyone has an idea about how to solve that case, or if my assumptions are incorrect, please enlighten me.
