
Password prompts are annoying - birken
http://danbirken.com/usability/2014/02/12/password-prompts-are-annoying.html
======
crazygringo
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.)

~~~
6cxs2hd6
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.

~~~
robinson-wall
My experience with the AWS console is that I get a 12-hour session upon
logging in, and I never have to reauthenticate.

------
kijin
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.

~~~
UnoriginalGuy
> 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.

Alternatively just add a logout button.

~~~
vacri
_Why would an attacker wait to use a stolen cookie?_

Every now and then I see a sentence which only makes sense in the context of
the 21st century...

~~~
StavrosK
Well, not really, many people got mugged at stolen-cookie-point in the
twentieth century too.

------
mfkp
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.

~~~
otterley
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?

[http://edelsont.livejournal.com/14163.html](http://edelsont.livejournal.com/14163.html)

~~~
thangalin
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.

Any other ideas?

~~~
pferde
These are all ideas which would cover maybe 80% of use cases, but severely
annoy the remaining 20%. Is that a good idea?

~~~
jessaustin
The fallback can be that you have to log in with a password. Which is bad, but
apparently tolerable.

------
Spittie
Password prompts are annoying, agreed.

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?

~~~
dionyziz
This exists: [http://pilif.github.io/2008/05/why-is-nobody-using-ssl-
clien...](http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-
certificates/)

~~~
phlo
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

------
blueskin_
>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.

~~~
aptwebapps
"Not asking for a password on registration means one needs to be emailed to
the user, in plaintext."

Not really. You can just create the account without a password and let them
create it with the 'forgot my password' flow later.

------
sixQuarks
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.

~~~
danneu
For a website like a forum, you could go ahead and display the "New Post"
textarea to guests and then prompt them for registration on submit.

~~~
Someone
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, …)

------
kennywinker
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.

~~~
jessaustin
How is CL identifying you as an account-holder? Maybe you could just delete
all their cookies? If it's by phone number, I guess you're out of luck...

~~~
kennywinker
email address

~~~
jessaustin
Maybe it would be less annoying to set up a new account that simply forwards
to your current one, and post your notices using that new account?

------
4qbomb
Should use Launchkey.co and logging in is not only easy but secure!!

------
benmarks
Too bad the cited example is the result of a patent.

------
droptableusers
Requirement of email is even more annoying.

------
jchysk
You don't need passwords with LaunchKey

~~~
aroman
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.

------
pgl
Film at 11.

------
yeukhon
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.

------
Fasebook
The lock on my front door is annoying.

