
Simplified Sign-Up and Log-In Flows - sgdesign
http://sachagreif.com/simplified-sign-up-and-log-in/
======
jkkramer
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.

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

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

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

~~~
wgx
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>

~~~
sgdesign
But how is that different from Googling "site:bagcheck.com John Smith"?

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

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

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

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

~~~
mmatants
It's unacceptable to transmit in plain-text a password that the _user_
specified.

But if it's a randomly-generated new nonce, seems OK as a pragmatic middle-
ground. Folks like us, who care, will log in and change it.

~~~
sunchild
Probably a draw, as you say, since someone could get ahold of an authenticated
link in your email, too.

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

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

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

~~~
fatbat
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-...](https://support.mozilla.org/en-US/kb/what-browserid-and-how-does-it-
work) True to multi-tasking, I left my previously typed comments in still,
hah!

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

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

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

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

~~~
icebraining
I don't use LastPass, but:

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

[https://lastpass.com/support.php?cmd=showfaq&id=1096](https://lastpass.com/support.php?cmd=showfaq&id=1096)

~~~
david_a_r_kemp
I use LastPass with the 2 factor-authentication. It doesn't have my email
password in it (which also requires 2-factor authentication).

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

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

~~~
joedev
Innovation for the sake of innovation is no good.

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

------
mise
If you want someone to pay for your service, put them through checkout first,
__then __ask to choose a password.

------
treelovinhippie
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?

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

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

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

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

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

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

I will never, ever, use your website Bagcheck.

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

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

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

------
dazbradbury
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/>

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

~~~
dazbradbury
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...](https://code.google.com/apis/identitytoolkit/v1/learnmore.html)

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

------
bazzargh
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
We wrote a service for sending out one-time URIs instead of the value itself:

<https://onetimesecret.com/>

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

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

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

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

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

