The real point is: don't do two-level ACL on websites.
At my previous company we had these "auto-login" links in emails and they are extremely powerful.
But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we were getting absolutely ridiculous user engagement from emails because of this feature and this was too valuable to give up.
Before I left the solution I had started to push was to introduce a new intermediate user level - "logged in but not trusted" - to the standard logged out/logged in two-level ACL. The basic implementation would have looked like this:
1) A logged in but not trusted cookie is set on both manual login or auto-login from marketing materials. It allows us to assume that this is user X and they are taking action Y on website Z. It also allows the user to receive the user logged in view where that UX has been tweeked to minimise effort for logged in users.
2) A logged in and trusted cookie is only set on an explicit manual login, and is required to perform _any_ write operation as well as to read certain sensitive information.
Where the practical implementation gets difficult is you really need to refine when to require the trusted cookie - at what point in your UX - to keep the engagement high. It will almost definitely go down, you just want to minimise that.
For an example, say you're a service like LinkedIn. You send emails to your users whenever they get a private message and you want to make it easy as possible for that user to reply because recruiters getting candidate engagement happens to be one of your key metrics. User clicks on the message in their email and instantly gets a login page, they might have been 50/50 about engaging with this recruiter so now that you presented an obstacle they just close the tab and get back to what they were doing. Alternatively, you show them the message from the recruiter and allow them to type up a reply and only ask for a password confirmation when they hit send, and it's possible your engagement will go up.
It requires more thought and is surprisingly tricky to implement once you get past the really easy "read-only" versus "write" type security checks, but it seems to be the way things are going.
amazon does that. you can browse the site and it identifies you and your preferences, but when you go to check out or modify account settings, you have to enter your password.
... and it feels really natural. Amazon identifies me easily, but if I do anything that feels like I need my password, it asks for it. Apple's App Store has similar logic, although it bothers me in one place where they ask for your password when downloading free apps.
And then there's Windows Live. Click on anything remotely related to Passport? You need a password (followed by 17 redirects, which is hilarious when managers have sound turned on and you here the "click click click click click" as IE bounces around).
followed by 17 redirects, which is hilarious when managers have sound turned on and you here the "click click click click click" as IE bounces around
I wonder if someone added a few extra redirects just for that reason. Seems like a quick and easy way to remotely identify coworkers that don't customize or disable their sound scheme and use IE.
I saw one of Amazon's UX team at a talk a while back, and the way he described it is they have a set of actions/permissions for people who are totally logged out, a set for people who are "sort of logged in", and then a set that require full login.
It's definitely tricky to implement (how do you determine whether a user is "sort of logged in"?), but once you get over the conceptual hurdles it's a pretty awesome user experience.
However, I would argue that like much of what Amazon does, it's not necessarily appropriate for the majority of sites.
The not-fully-trusted user paradigm is actually pretty common in websites for changing your password (enter old password, new password, and new password confirmation). The main reason, as I understand it, is to limit the damage made possible by session hijacking.
Session hijacking and the wrong person auto-logging in are actually the same thing on a technical level; the difference is semantics. In both cases, a logged-in user is not the owner of the account.
A good take-away from this might be "don't do two-level ACL until you have user traction".
DavicMcLaughlin says, "we were getting absolutely ridiculous user engagement..." When you are starting a site, you want as little resistance to usage as possible, and this helps with that. It makes it one step easier for people to use your site. It helps reduce the typical chicken/egg problem, or any other "it's hard to get users" problem.
Once you have the users, and security becomes more of a concern ("But security should always be a concern", yeah I know.) then you should start to think about something more secure. Until then, do all you can, within reason, to get users.
> Once you have the users ... then you should start to think about something more secure. Until then, do all you can, within reason, to get users.
Worked well for Sony!
Seriously, that is an egregious abuse of both ethics and morality, the latter because you are implicitly abusing your users' trust (unless your welcome screen says "NOT YET SECURE" in huge font). If implementing reasonable security before you enter beta testing is such a resource burden that your product will go under before it can get its footing, then your product goes under. Ethics do not go away when your profitability and success are on the line -- that is the specific moment when ethics come into play.
I realize you have already thought through this and have a different POV. Newbies are liable to see this kind of talk however, and think it is an accepted industry-wide practice to treat security as an afterthought until you have scaled, when that is in fact a profitable but unacceptable antipattern.
P.S.- This is like a new small-town restaurant saying "Refrigerators are expensive, so we can't afford to refrigerate our eggs and milk until we get more customers. Otherwise we might go under from the increased operating cost, and then our customers wouldn't get to enjoy our restaurant!" Draw your own conclusion.
I think you're overblowing his point a little, and attacking a straw man. I don't think he's talking about not-using-refrigerators/storing-passwords-in-plain-text type of insecurity, just worrying less about loopholes that are non-critical and unlikely to be exploited anyway until you have lots of users. He did say "within reason".
Here are two suggestions that we would have seen, if the underlying assumption was not that {increasing the derivative of user count per day} justifies {poor security}:
1.) Implement bulky external security measures -- like client-side certs or VPNs -- and replace them with more scaleable solutions as the user count grows.
2.) Inform your users that they are interacting with an unsecured fledging service, such that they do not have an expectation of privacy. At the very least, warn them not to use this service on an unsecured coffee-shop WAN.
At my previous company we had these "auto-login" links in emails and they are extremely powerful.
But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we were getting absolutely ridiculous user engagement from emails because of this feature and this was too valuable to give up.
Before I left the solution I had started to push was to introduce a new intermediate user level - "logged in but not trusted" - to the standard logged out/logged in two-level ACL. The basic implementation would have looked like this:
1) A logged in but not trusted cookie is set on both manual login or auto-login from marketing materials. It allows us to assume that this is user X and they are taking action Y on website Z. It also allows the user to receive the user logged in view where that UX has been tweeked to minimise effort for logged in users.
2) A logged in and trusted cookie is only set on an explicit manual login, and is required to perform _any_ write operation as well as to read certain sensitive information.
Where the practical implementation gets difficult is you really need to refine when to require the trusted cookie - at what point in your UX - to keep the engagement high. It will almost definitely go down, you just want to minimise that.
For an example, say you're a service like LinkedIn. You send emails to your users whenever they get a private message and you want to make it easy as possible for that user to reply because recruiters getting candidate engagement happens to be one of your key metrics. User clicks on the message in their email and instantly gets a login page, they might have been 50/50 about engaging with this recruiter so now that you presented an obstacle they just close the tab and get back to what they were doing. Alternatively, you show them the message from the recruiter and allow them to type up a reply and only ask for a password confirmation when they hit send, and it's possible your engagement will go up.
It requires more thought and is surprisingly tricky to implement once you get past the really easy "read-only" versus "write" type security checks, but it seems to be the way things are going.