What is he talking about? Amazon.com prompts me for my password all the friggin' time. Every time I click "check out". Every time I click "my orders". It asks me again in the same session if I go back to add something to my card, and click "check out" again.
(I agree with the rest. I just think Amazon's a bad example here.)
As noted in the post, I believe Amazon has some extra anti-fraud stuff going on. I actually went through the purchase flow sans password as I was writing the post, so it certainly is possible. However, other times I have gone through the checkout flow and have been prompted for a password.
They clearly value security/privacy over convenience for other aspects of the site (past orders, etc).
Have you enabled "1-click" ordering? That doesn't require a password (for me). Whereas doing a checkout cart flow, does.
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.
I'd prefer the lot-more security that using https would provide. I cannot believe that Amazon is served almost entirely over plain-text http, with only the initial log-in done over https. At least that's on the various European versions of the site, perhaps the US one is more secure (I doubt it).
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?
Using long-term cookies to keep people logged in all the time can be dangerous in certain circumstances. After all, there's a reason why we used to tell people to log out when they're done, although Google and Facebook are doing their damnedest to make people forget this ancient wisdom.
- 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.
> There are many more opportunities for an attacker to reuse a stolen cookie.
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.
I think that #3 (Log users in from emails clicks automatically) is the most important here. I hate it when I click a link in an email, then immediately have to log in. Half the time it's not worth the effort and I close the tab. I would guess that conversion ratios can be improved by a large amount by automatically logging users in via a token in the email link.
OKCupid puts login tokens in their links used in their notification emails, so that when you click on them, you're automatically logged in. Convenient, right? But what if a novice user copies the link and sends it to a third party ("hey, take a look at this match!"), not knowing the significance of the extra data in the URL?
Authentication tokens should expire after first use; other sanity checks:
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.
Use a persistent identification cookie even when the "remember me" checkbox isn't used. By themselves, neither the cookie nor the email nonce are enough to authenticate. But if you have both at once, you are authenticated.
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.
2 Won't work any more now that Google have led the charge with downloading images in email messages to their own servers and serving them to users themselves.
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.
This is most annoying when they're asking me to write a review or respond to another customer's question. They're already asking me for free labor. They want to add their security to my list of chores. They must invision a bot which intercepts emails for products and writes positive or negative reviews depending on who is paying the bills.
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.
How long would you consider reasonable before requiring the user to enter a password when clicking through an email? Basically, how long should the token be valid from a user perspective?
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.
In this situation the user would already be logged in from opening newer emails, so opening the older emails would use their existing session, even though the token has expired.
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?
StartSSL (a reasonably priced Israeli PKIX CA) does. Some Banks do too, but tend to wrap it all up in a hardened browser instance or app.
As for why no-one else does:
* 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
>This convenience is possible because this is hard to abuse. If a malicious person gets access to my computer, the worst thing they can do is order a whole bunch of stuff to my saved address, which I could easily cancel or return.
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.
500px.com does something very interesting. They allow you to start a live account using a temporary "guest" account. No email, no passwords, no nothing. After you start, you realize, shit, I want to save this stuff, so you create an account and you've already started. Brilliant.
If you do, make it very clear that you will ask for a password after submit, and what kind of password that is. There's nothing as annoying as thinking "these guys accept feedback", spending time typing feedback and then getting some weird options ("log in using Facebook, Disqus, …)
The craigslist flow also has plenty of annoying edge cases. I ended up with an account at some point... I can't recall why exactly. I was maybe posting to a category with a lot of fraud in it so they made me? Anyway, now every time I post the process STARTS as an accountless posting, but ends up linked to my account.
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 did some freelance coding over Craigslist, and their account system is optimized for people who run serial ads. To make a new ad is the same, and its kind of a pain, but after that you can repost, cross post, edit, etc. with ease.
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.
Yeah, but then you'd need LaunchKey, which is worse. Nothing against them personally, but handling your user account protection with a for-profit third-party seems far worse than having a password prompt.
Controversial. First, it's nice to have new thoughts. But I am not a closed-mind person, plus I am new to security so I am fairly open to new ideas.
> 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.
(I agree with the rest. I just think Amazon's a bad example here.)