Simplified Sign-Up and Log-In Flows
sachagreif.com
sachagreif.com
Not any more. To post a question, a comment, or vote, you have to sign up.
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.
http://news.ycombinator.com/item?id=3059759 (top comment thread)
Nope. That email should contain a link to password creation.
Would love to see usability commentary on these sites to see if/how they've decided to use one approach over another.
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...
> 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.
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.
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.
If you actually believe this, then we will never be in agreement.
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.
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.
I like the practice of emailing a link to a page where the user can set their password for the first time.
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.
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.
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.
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!
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.
There are other similar ones like this also.
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.
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.
I checked a couple of my 1Password files and you're right: usernames & passwords are encrypted, but not the website/URL they're associated with.
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.
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).
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.
Maybe this was a problem in an earlier version and it's been fixed?
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.
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/).
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.
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?
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.
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.
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.
I will never, ever, use your website Bagcheck.
There's a reason no-one else does login like this.
http://code.google.com/apis/identitytoolkit/
example use: http://www.openidsamplestore.com/basic/
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.
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.
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...
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.
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.
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.
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?!".