(I agree with the rest. I just think Amazon's a bad example here.)
They clearly value security/privacy over convenience for other aspects of the site (past orders, etc).
However I agree with you that there are some flows on Amazon.com (or especially AWS Console) where you're seeing that sign-in form every 10 minutes, it feels like.
Fortunately you get prompted regularly to enter the password again - presumably renewing the cookie/session - if you want to access more private stuff. So a MITM would have to be listening all the time to view your purchases, etc. and there's no way to change an address without entering the password (I think). But still.. haven't they heard of firesheep?
- There are many more opportunities for an attacker to reuse a stolen cookie.
- There are many more opportunities to exploit a CSRF vulnerability if users are always logged into the target site.
- Users might be under the impression that when they close the browser, they'll be logged out. Breaking this expectation can have privacy implications. For this reason, I think it would be good to have a "Keep me logged in" checkbox, even if it is checked by default.
- Many people, especially the poor, still use computers that are either shared (with family and/or friends) or public (schools, libraries and Internet cafes). Although these people probably only make up a small minority of your userbase, I think it's important to afford them no less security than you do your other users.
Why would an attacker wait to use a stolen cookie? Does this actually increase the attack surface, or simply just put the bad guy on a shorter timetable?
Also every time someone visits your site you could delete their old token and save a new one. That way stolen cookies only last as long as until the page is re-visited.
> There are many more opportunities to exploit a CSRF vulnerability if users are always logged into the target site.
That argument is valid for most sites, even sites who's sessions only survive until the browser is closed. At this stage in the game it is barely a real argument as so few sites log you out within a reasonable time frame.
> Users might be under the impression that when they close the browser, they'll be logged out. Breaking this expectation can have privacy implications. For this reason, I think it would be good to have a "Keep me logged in" checkbox, even if it is checked by default.
Aside from banking sites, how many sites log you out right now when you close the browser? I cannot think of many. I'm all for having a logout button. I would expect public computers to be set up to clear the browser's history, cache, and cookies when it is closed like every modern browser supports.
> Many people, especially the poor, still use computers that are either shared (with family and/or friends) or public (schools, libraries and Internet cafes). Although these people probably only make up a small minority of your userbase, I think it's important to afford them no less security than you do your other users.
Most shared/public computers are set up specifically to delete browser information upon exit for this very reason. If you are going to design every website on the internet for the one or two places who have their machines set up horribly poorly, then you really are targeting the lowest common denominator.
Alternatively just add a logout button.
Every now and then I see a sentence which only makes sense in the context of the 21st century...
1. Tokens should expire after no more than five minutes.
2. Embed a 1-pixel image in an HTML-based e-mail also contains the token. When the e-mail is first opened, the server associates the IP address from the e-mail with the token. Only subsequent authentication requests for that token/IP address pair pass validation.
3. Log IP addresses used by an account. Additional new IP addresses outside the usual geographical area (GeoIP) should fail validation. This assumes that the first person to click the link is the intended recipient.
Any other ideas?
This will cover almost everybody, it will have almost no false positives (forwarding an email to somebody who uses the same browser on the same computer is the only one I can think of off the top of my head), and the fallback of requiring explicit authentication in other cases seems acceptable.
I expect all email providers to follow Google's lead on that tbh because it's really quite good.
3 is a bit of a problem with residential broadband as IP address get re-assigned a fair bit.
One that I find a bit annoying is clicking a link to reset a password, then having to login again with that same password. Seems a bit unnecessary.
The problem is exacerbated by the fact that I'm usually checking those emails on the phone where it is often a PITA to enter passwords.
From a developer perspective I think unless you are comfortable with a 1-2 week token* (or longer depending on customer base) you could actually decrease conversion rates because you remove the features consistency.
Ex: a user is cleaning out emails, starts with the most recent and works their way back. Opens OkCupid message from 3 weeks ago because it was interesting, but the link doesn't work.
*I would appreciate further insight as to what is a normal length of time for tokens to be valid and the impact increasing the token expiration time might have on security.
Or if the user visits an old email without looking at a new email first, the user can just log in as usual.
I like the idea of delaying it as long as possible, even if sometimes it gets annoying. If I have to go through several steps just to register to a site, then I'll probably not register.
But remember that e-mail is not a secure protocol. Anyone could be sniffing your traffic to find a random generated password, an url that automatically log you in, and similar content.
I'd love to see a solution based on certificates, like how ssh works. Your browser and the server agree on a key pair over a secure (https?) connection, and then you use it to login.
This add a whole layer of complications to the browser, like how you sync those, take them into another browser ecc... But it would sure be a very cool way to totally remove the password prompt, while staying secure.
By the way, Amazon ask for my password every time I try to place an order, even if it's with a saved credit card and with on a registered address. Maybe it's an American thing?
* installing a client cert is way too complicated for "average" users
* being directed to change settings you don't understand may appear scary
* moving a your client cert from one box to another is unnecessarily complicated (browser sync may help there)
* if more than one person uses the OS account, they'll need to mess around in the browsers config option each time they authenticate
* not having to provide a password will "feel" insecure to many users
* running a PKI is hard[er than storing passwords]
* I'm not sure we want people installing any kind of certificates as a normal part of their workflow -- more often than not they might stumble upon a malicious CA cert
Based on the number of services who will reset logins given only the last 4 digits of a card, this person is hopelessly misinformed.
Not asking for a password on registration means one needs to be emailed to the user, in plaintext. Given users' habits, a vast majority of them will then not change from that one - a security disaster, and likely to land you on plaintextoffenders.com .
As for this three flows, 1 is someone who wasn't interested, fine - but he advocates spamming people who haven't double opted in, which is just about the worst thing you can do from an email perspective.
Oh, and email click logins are another terrible idea, as intercepting an email then gives account access - even partial access means your security model has failed.
I'd rather have regular password checks with the 3 seconds it takes to input it from KeePass than lose an account or personal details.
Not really. You can just create the account without a password and let them create it with the 'forgot my password' flow later.
It ends up not saving any steps. I create a posting, get a POST/EDIT/DELETE email, click that, log in using my username/password (or more realistically: reset my password, then log in).
Craigslist's accountless posting is a great thing, but managing a hybrid approach as they have ended up having to do seems messy and confusing for those of us who get accounts.
I'm not 100% sure I'm remembering this correctly, but I believe it forces you (or at least is very insistent) to register an account after you've made a certain number of posts over a certain period of time.
I agree that the current paradigm is flawed, especially when PSK authentication is so easily implemented.
> It might seem strange, but a sign-up flow in which people set the password as late as possible (or never at all!) are generally going to convert at a higher rate.
I am not interested in conversion rate. Amazon does not lock you in to sign up if you are just browsing. If you want to purchase, you might. I am sure there are sites out there do guest checkout or add to cart and sign in later. That's great. So about the number of users who are going to sign up and not sign up depends on the situation.
> simply keep a user logged in for a very long time (1 year+), but require a password to change key account information. Simple and effective.
We trade too much security for convenience. Having long time session for Amazon-like site? That's a bad idea. Imagine me telling you your computer will now log in Citibank for 365 days. And we tell people don't save password for such high-profile site? If you lose your computer and the theft was able to access your browser, that cookie can do a lot of harm.
> But my favorite site is craigslist.
As you noted later, your solution works for certain types of website. Using Amazon to establish a story and propose a solution makes the solution weak and confusing.
> I realize that there are also security trade-offs, but it isn't a coincidence that the #1 online retailer, the #1 classified ad site, the #1 daily deal site all trade-off a slight amount of security for convenience.
You are talking about a site which handles transaction with banks and merchants, vs a site that handles text ads display.
In your final lines:
> An email/password prompt should not be the first thing on your sign-up form.
Sorry, what? You just said it would be nicer to just send an email to the user. Now you are suggesting, let's not. Also, the downside of providing a password later is that people will not do that later. You can, of course, force them to provide a password when they do critical things like "to checkout, please provide password." So why save that headache? Is the use case about "I want to save my watchlist on Amazon but I don't yet want to provide my password to Amazon?" This is the only usecase which I think is fair but severely limited and thus may well be considered unimportant in the end.
> Use long term cookies to keep people logged in. Like Amazon or Groupon, if somebody has logged in once on a computer, let them do common hard-to-abuse things without a password.
> Log users in from emails clicks automatically.
No. How can you verify it is ME clicking it? Because i am the only one who can access the email? So if such link is leaked (or the link generation is hacked), I can log in as anyone without even trying to hack your database.
If my email is doom password reset is doom? Okay, fine. But we are all advocating to implement better, more secured multi-factor authentication, why are we now falling back to minimal authentication again?
While I agree password cannot verify one's identity entirely and email is also hackable, I think simple design like AUTHENTICATION all the way is simpler. There might be cases in which authentication is unnecessary - but I probably won't recommend myself even thinking about this new idea.