Simplified Sign-Up and Log-In Flows

http://sachagreif.com/simplified-sign-up-and-log-in/

by sgdesign • 14 years ago

139 86 14 years ago

sachagreif.com

mise• 14 years ago

If you want someone to pay for your service, put them through checkout first, then ask to choose a password.

StavrosK2• 14 years ago

Another one for the list is a project of mine, YourPane: http://www.yourpane.com

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.

These days, though, I prefer BrowserID.

wgx2• 14 years ago

The Bagcheck example exposes the presence of an account - that can't be best-practise for security I would have thought.

arkitaip2• 14 years ago

"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."

ayers• 14 years ago

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".

wgx2• 14 years ago

Right, but by typing a few characters I can establish if a user has an account or not, for a subsequent attack.

http://news.ycombinator.com/item?id=3059759 (top comment thread)

http://news.ycombinator.com/item?id=3156841

judofyr• 14 years ago

When you have public profiles, checking for presence of an account is pretty easy anyway.

sgdesign5• 14 years ago

Right. You can also check for someone's profile with his name or email on Twitter (or even just Google them).

david_a_r_kemp3• 14 years ago

Neither is neglecting to restrict the number of attempts to type the correct password.

treelovinhippie• 14 years ago

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?

arkitaip2• 14 years ago

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.

haraball• 14 years ago

I'm using LastPass for this, you can specify how strong your unique generated password should be and it stores it for you.

There are other similar ones like this also.

Spearchucker3• 14 years ago

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.

cpeterso3• 14 years ago

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. :(

http://supergenpass.com/

decode2• 14 years ago

> 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.

http://passwordmaker.org/

jakobe• 14 years ago

I use the following simplified signup procedure:

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.

bemmu• 14 years ago

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.

icebraining3• 14 years ago

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.

sgdesign5• 14 years ago

I really like this. I think that's pretty much my ideal sign-up flow, at least it's the fastest and simplest one I've heard of so far.

jkkramer• 14 years ago

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.

kasraeg• 14 years ago

I agree. that'll give first time users a full description of the site in a more detailed way than any landing page could ever do.

beaumartinez• 14 years ago

> No sign-up at all. Let them use the site anonymously but fully

Not any more. To post a question, a comment, or vote, you have to sign up.

karterk• 14 years ago

Yes, that's actually a very powerful "feature". I tried that approach for a simple app I wrote:

http://scribble.wreally.com/

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.

bazzargh2• 14 years ago

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.

delano• 14 years ago

We wrote a service for sending out one-time URIs instead of the value itself:

https://onetimesecret.com/

fduran• 14 years ago

Same idea (one-time URI) but with client-side encryption and sender's email notification (including IP & geolocation of receiver): https://whisperpassword.com/

finnw2• 14 years ago

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.

bazzargh2• 14 years ago

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.

AndrewDucker• 14 years ago

I'm really hoping that BrowserID takes away a lot of these issues and streamlines the process of logging in to sites.

StavrosK2• 14 years ago

Yes! BrowserID is much better in terms of usability, way way simpler to integrate and much more secure. I so hope to God it takes off.

fatbat• 14 years ago

Was it that Mozilla thing? Vaguely recall seeing a video about it.

Nevermind, found it. https://support.mozilla.org/en-US/kb/what-browserid-and-how-... True to multi-tasking, I left my previously typed comments in still, hah!

dazbradbury3• 14 years ago

Seems like Google Identity Toolkit addresses these problems and offers a viable solution. It's what I'm planning to use at our startup.

http://code.google.com/apis/identitytoolkit/

http://accountchooser.com/

example use: http://www.openidsamplestore.com/basic/

Spearchucker3• 14 years ago

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.

dazbradbury3• 14 years ago

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.

dazbradbury3• 14 years ago

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.

https://code.google.com/apis/identitytoolkit/v1/learnmore.ht...

icebraining3• 14 years ago

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.

sunchild8• 14 years ago

"... tell them their password is waiting for them in their inbox."

Nope. That email should contain a link to password creation.

scdc• 14 years ago

right, so the email-only signup really just delays the step of creating a password. Is that better?

Would love to see usability commentary on these sites to see if/how they've decided to use one approach over another.

sunchild8• 14 years ago

It's better, in that you now at least know who to contact – someone who showed enough interest to provide an email address.

tomjen33• 14 years ago

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.

sunchild8• 14 years ago

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...

powertower2• 14 years ago

I really dislike this sentiment.

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.

sunchild8• 14 years ago

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.

jerfelix• 14 years ago

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.

sgdesign5• 14 years ago

If you focus only on the sign in flow (and not the rest of the site), it's still a very innovative concept.

joedev• 14 years ago

Innovation for the sake of innovation is no good.

Timothee• 14 years ago

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/).

AznHisoka2• 14 years ago

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.

maxmcd2• 14 years ago

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.

tomjen33• 14 years ago

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.

AznHisoka2• 14 years ago

Why do you need 1 for each service you use?

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?!".

nodata• 14 years ago

"Enter your name" reveals part of your user database to me?

I will never, ever, use your website Bagcheck.

thomaslangston• 14 years ago

I believe (based on the article, not first hand knowledge) that it reveals the contents of your browser's cookies, not the database.

sgdesign5• 14 years ago

No, it does reveal the database as far as I know. But again, it's a completely public site.

kcima2• 14 years ago

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.

maxmcd2• 14 years ago

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.

kcima2• 14 years ago

Good points, especially about no longer being able to log into the account with old password because of a forced password change.

Cyranix• 14 years ago

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.

nchlswu• 14 years ago

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.

joshuarudd• 14 years ago

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.

saurik• 14 years ago

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".

Simplified Sign-Up and Log-In Flows

Related Stories