19 ms·

Simplified Sign-Up and Log-In Flows

139 points by sgdesign 15y ago

mise 15y ago
If you want someone to pay for your service, put them through checkout first, then ask to choose a password.
StavrosK 15y ago
Another one for the list is a project of mine, YourPane: http://www.yourpane.com 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.
wgx 15y ago
The Bagcheck example exposes the presence of an account - that can't be best-practise for security I would have thought.
- arkitaip 15y 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 15y 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".
  - wgx 15y 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 http://news.ycombinator.com/item?id=3059759 (top comment thread) http://news.ycombinator.com/item?id=3156841 http://news.ycombinator.com/item?id=3156841
    - sgdesign 15y ago
      But how is that different from Googling "site:bagcheck.com John Smith"?
- judofyr 15y ago
  When you have public profiles, checking for presence of an account is pretty easy anyway.
  - sgdesign 15y 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_kemp 15y ago
  Neither is neglecting to restrict the number of attempts to type the correct password.
treelovinhippie 15y 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?
arkitaip 15y 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 15y 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.
  - Spearchucker 15y 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.
    - dorian-graph 15y ago
      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.
      - LinaLauneBaer 15y ago
        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.
jakobe 15y 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 15y 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.
  - icebraining 15y 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.
- sgdesign 15y 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 15y 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 15y 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 15y 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 15y ago
  Yes, that's actually a very powerful "feature". I tried that approach for a simple app I wrote: http://scribble.wreally.com/ 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.
bazzargh 15y 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 15y ago
  We wrote a service for sending out one-time URIs instead of the value itself: https://onetimesecret.com/ https://onetimesecret.com/
  - fduran 15y ago
    Same idea (one-time URI) but with client-side encryption and sender's email notification (including IP & geolocation of receiver): https://whisperpassword.com/ https://whisperpassword.com/
- finnw 15y 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.
  - bazzargh 15y 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 15y ago
I'm really hoping that BrowserID takes away a lot of these issues and streamlines the process of logging in to sites.
- StavrosK 15y 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 15y 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-does-it-work https://support.mozilla.org/en-US/kb/what-browserid-and-how-... True to multi-tasking, I left my previously typed comments in still, hah!
dazbradbury 15y 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://code.google.com/apis/identitytoolkit/ http://accountchooser.com/ http://accountchooser.com/ example use: http://www.openidsamplestore.com/basic/ http://www.openidsamplestore.com/basic/
- Spearchucker 15y 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.
  - dazbradbury 15y 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.
sunchild 15y ago
"... tell them their password is waiting for them in their inbox." Nope. That email should contain a link to password creation.
- scdc 15y 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.
  - sunchild 15y ago
    It's better, in that you now at least know who to contact – someone who showed enough interest to provide an email address.
    - SkyMarshal 15y ago
      And sending passwords, even temp ones, through plaintext email is just bad practice, a solved problem, and totally unnecessary.
- tomjen3 15y 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.
  - sunchild 15y 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...
    - 15y ago
jerfelix 15y 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.
- sgdesign 15y 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 15y ago
    Innovation for the sake of innovation is no good.
- Timothee 15y 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/ https://rpxnow.com/).
AznHisoka 15y 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.
- maxmcd 15y 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.
- tomjen3 15y 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.
  - AznHisoka 15y 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 15y ago
"Enter your name" reveals part of your user database to me? I will never, ever, use your website Bagcheck.
- thomaslangston 15y ago
  I believe (based on the article, not first hand knowledge) that it reveals the contents of your browser's cookies, not the database.
  - sgdesign 15y ago
    No, it does reveal the database as far as I know. But again, it's a completely public site.
    - david_a_r_kemp 15y ago
      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.
kcima 15y 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.
- maxmcd 15y 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.
  - kcima 15y ago
    Good points, especially about no longer being able to log into the account with old password because of a forced password change.
Cyranix 15y 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 15y 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 15y 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 15y 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".

139 points by sgdesign 15y ago

mise 15y ago

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

Another one for the list is a project of mine, YourPane: http://www.yourpane.com 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.

wgx 15y ago

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

arkitaip 15y 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 15y 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".
- wgx 15y 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 http://news.ycombinator.com/item?id=3059759 (top comment thread) http://news.ycombinator.com/item?id=3156841 http://news.ycombinator.com/item?id=3156841
  - sgdesign 15y ago
    But how is that different from Googling "site:bagcheck.com John Smith"?
judofyr 15y ago
When you have public profiles, checking for presence of an account is pretty easy anyway.
- sgdesign 15y 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_kemp 15y ago
Neither is neglecting to restrict the number of attempts to type the correct password.

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

arkitaip 15y 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 15y 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.
- Spearchucker 15y 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.
  - dorian-graph 15y ago
    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.
    - LinaLauneBaer 15y ago
      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.

jakobe 15y 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 15y 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.
- icebraining 15y 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.
sgdesign 15y 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 15y 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 15y 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 15y 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 15y ago
Yes, that's actually a very powerful "feature". I tried that approach for a simple app I wrote: http://scribble.wreally.com/ 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.

bazzargh 15y 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 15y ago
We wrote a service for sending out one-time URIs instead of the value itself: https://onetimesecret.com/ https://onetimesecret.com/
- fduran 15y ago
  Same idea (one-time URI) but with client-side encryption and sender's email notification (including IP & geolocation of receiver): https://whisperpassword.com/ https://whisperpassword.com/
finnw 15y 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.
- bazzargh 15y 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 15y ago

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

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

dazbradbury 15y 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://code.google.com/apis/identitytoolkit/ http://accountchooser.com/ http://accountchooser.com/ example use: http://www.openidsamplestore.com/basic/ http://www.openidsamplestore.com/basic/

Spearchucker 15y 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.
- dazbradbury 15y 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.

sunchild 15y ago

"... tell them their password is waiting for them in their inbox." Nope. That email should contain a link to password creation.

scdc 15y 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.
- sunchild 15y ago
  It's better, in that you now at least know who to contact – someone who showed enough interest to provide an email address.
  - SkyMarshal 15y ago
    And sending passwords, even temp ones, through plaintext email is just bad practice, a solved problem, and totally unnecessary.
tomjen3 15y 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.
- sunchild 15y 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...
  - 15y ago

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

sgdesign 15y 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 15y ago
  Innovation for the sake of innovation is no good.
Timothee 15y 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/ https://rpxnow.com/).

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

maxmcd 15y 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.
tomjen3 15y 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.
- AznHisoka 15y 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 15y ago

"Enter your name" reveals part of your user database to me? I will never, ever, use your website Bagcheck.

thomaslangston 15y ago
I believe (based on the article, not first hand knowledge) that it reveals the contents of your browser's cookies, not the database.
- sgdesign 15y ago
  No, it does reveal the database as far as I know. But again, it's a completely public site.
  - david_a_r_kemp 15y ago
    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.

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

maxmcd 15y 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.
- kcima 15y ago
  Good points, especially about no longer being able to log into the account with old password because of a forced password change.

Cyranix 15y 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 15y 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 15y 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 15y 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".