
A Modest Proposal for Improving Website Authentication - kijin
http://www.kijinsung.com/id/7108a50c-3523-489c-a318-63a23094a937
======
Terretta
Cool idea, though I haven't had 1Password miss a login form in a couple years
now, and this doesn't resolve custom auths like banks that ask for single
keystrokes among nth letters of your password. So the only forms 1Password
can't handle, are still an issue.

Technically, you can already implement built in browser auth UI without
changing today's browsers, by having the protected path return an http not
authorized code triggering the browser chrome login dialog.

 _Note:_ "A modest proposal" in a title indicates the suggestion is satire.
The original "modest proposal" was to eat babies.

"In English writing, the phrase "a modest proposal" is now conventionally an
allusion to this style of straight-faced satire." —
<http://en.wikipedia.org/wiki/A_Modest_Proposal>

~~~
sixbrx
For whatever it's worth, I took the "modest proposal" at face value and have
never heard of the satirical association. Also I do rather like the idea of
word groups basically meaning what the individual word meanings would
indicate, as far as possible, though that's probably a losing battle.

~~~
jimwhitson
Not only a losing battle, but one lost many centuries ago.

~~~
whistlerbrk
*citation needed

~~~
frenchy
I think this passes under the rule of "common knowledge", at least for anyone
in the field of linguistics or literature. The writing in question, A Modest
Proposal, was written centuries ago, if you read the Christian Bible you can
see examples of satire that are thousands of years old.

------
neil_s
The reason I prefer this idea over something like Persona is I hate the idea
of giving all websites a single email address to contact me. At present I use
Gishpuppy to create a new email address for each domain that'll forward to my
main inbox. If any site starts spamming or has their database accessed by
spammers, I simply delete that email address and immediately get rid of the
spam. This is a basic ability I lose with centralised systems like OpenID or
Persona, who could implement this feature but haven't.

~~~
callahad
> _This is a basic ability I lose with centralised systems like OpenID or
> Persona_

I'm confused. Neither Persona nor OpenID are centralized, but that might be
beside the point. What sort of concerns do you have with Persona's
architecture?

> _I hate the idea of giving all websites a single email address to contact
> me_

Then... don't? Persona lets you use as many addresses as you want. It already
works with _any_ valid email address, which means you can keep using all of
your existing GishPuppy addresses. You can keep using your one-address-per-
domain scheme with Persona. No problem.

~~~
neil_s
It does work for the use case for a handful of different email addresses(work
and personal for example), but not when you're using a new email address for
every single domain.

The ideal workflow for me would be to sign in to persona using my Gmail
address as my single identity, and then have it auto-generate (or retrieve by
posting details to a Gishpuppy URL) an email address for that specific domain,
and only pass that on to the website. In the current model I still need to
confirm each new email address by clicking on a link, which reduces the value
of a single login greatly. Also, I don't want to be choosing between 900+
Gishpuppy addresses when signing into a site again.

This might not be the ideal workflow for everyone, but its a feature I can't
include, because of the lack of API hooks or extensions. Using 'the modest
proposal' on the other hand, I could chain together browser extensions
sufficiently to add the functionality I need, to get new email addresses from
Gishpuppy and existing credentials from LastPass. I guess the word I was going
for was not centralised, but inextensible.

~~~
callahad
> _In the current model I still need to confirm each new email address by
> clicking on a link_

That problem would go away if GishPuppy supported the Persona natively -- do
you have contact info for someone at GishPuppy? I'd be happy to work with them
to make that happen.

> _I don't want to be choosing between 900+ Gishpuppy addresses when signing
> into a site again._

Persona locally remembers your last-used address, so this _shouldn't_ be a
problem, though we could probably improve the UX. We're currently trying to
figure out how to sync this data in a way that's opaque to Mozilla.

> _The ideal workflow for me would be to [...] have [Persona] auto-generate
> [...] an email address for that specific domain_

I agree, but we're totally in the minority. Since you've already talked about
chaining together browser extensions, you could easily do the same thing with
Persona. It'd only take a small Greasemonkey script on the login.persona.org
origin to make that work.

Thanks for the feedback!

------
EvanAnderson
I wish web sites just used HTTP authentication over HTTPS. I'd love to get all
the hours back that I've spent writing scripts to automate operations against
web sites with home-grown forms-based authentication.

~~~
tptacek
There's a reason HTTP Authentication isn't widely used. It's significantly
harder to style, which means it's hard to work password reset into it. It
doesn't easily admit to "logout", which is an important security mechanism. In
2013 applications use sessions for far more than just authentication. It
doesn't gracefully handle token authentication. It doesn't make play well with
single sign-on. It doesn't even make sense in a world where your phone or
fingerprint authenticates you to an app.

The right way to think of HTTP Authentication is as an experiment that failed.

~~~
wtbob
> It's significantly harder to style, which means it's hard to work password
> reset into it.

Couldn't that have been fixed with a new parameter in the Authentication
header?

> It doesn't easily admit to "logout"

I think it easily admits logout—the browser should have a piece of UI which
reads 'logout'...

> It doesn't gracefully handle token authentication.

It could be extended to do that, with a new authentication type, right?

------
tomkludy
IMO the root problem is that A) we have too many identities, B) those
identities are rarely protected properly (sites don't hash/salt, don't have
password expiration policies, don't use 2-factor auth), and C) managing those
identities over time is nearly impossible.

I use lastpass, and it's great. But I didn't always use it; before I started,
I used a couple of passwords everywhere. Recently some site which I haven't
even used in years was compromised, and as a result, one of my "frequently
used passwords" was potentially compromised. I had to spend hours going to
dozens of websites and changing my password. Every site has a different way to
change your password, and different policies for acceptable passwords, and
most don't even make it easy/obvious.

I think something like Mozilla Persona is a good start, but not quite
complete. Give me one, central place to manage my identity. The ability to
control which sites have access to my identity. The ability to allow, or not
allow, different sites to correlate my identity with each other. The ability
to have my identity independent of my email address. Good two-factor auth for
establishing identity, and good password management policies. Single-sign-on,
even across independent sites, with just a click.

So the problem is that a proposal like this encourages people to do the wrong
thing; i.e. ask me for a username and password - without two-factor auth,
without considering whether I will be able to manage yet-another-password,
without considering whether they should even be in the business of
authentication themselves.

~~~
kijin
The assumption is that the login button in the browser will be accompanied by
features such as random password generation and automatic sync in the cloud
(LastPass does this to some extent), so that the user doesn't need to manage
yet another password. The proposal is to make this happen _without_ waiting
for websites all over the world to standardize on a single third-party
identity like Persona (or heaven forbid, Facebook Connect).

I don't think there's anything in my proposal that makes 2FA impossible. That
can be written into the spec. Enter your tokens into a little textbox that
your browser pops up when you click "Login" on a website that requires 2FA.

Although many people seem excited about single sign-on systems like Persona, I
respectfully disagree, for reasons I wrote about in a different post [1]. You
ask whether individual websites should be in the business of authentication,
but I'd rather ask why anybody should be in the business of authenticating
anybody else to third parties. I'm not opposed to keeping all my credentials
in a single location, but I want that location to be inside my own devices.
I'm not opposed to sync, either, but I want sync to involve full client-side
encryption. I have a great deal of trust in Mozilla, but precisely because I
love them, I don't want them ever to put themselves in a position where a
three-letter agency can ask them to hand over any information about me, even
if it's just a list of email addresses that I use with Persona.

[http://www.kijinsung.com/id/610a7b92-3d4e-4c44-b231-0f5e4d1a...](http://www.kijinsung.com/id/610a7b92-3d4e-4c44-b231-0f5e4d1a23d2)

------
StavrosK
Hmm, as a rule, I prefer centralized logins (Mozilla Persona, in particular),
but this could be a nice way to standardize logins. However, the fact that it
should be implemented as an HTTP header strikes me as out-of-place, since I
think it would be much better as something more standard, like:

<form method="POST" action="/login/"> <input type="credentials"
elements="email,password" /> </form>

This is pretty much exactly the same as the proposal, only it's in HTML rather
than HTTP.

~~~
da_n
Why not have both? If the browser is capable (theoretically) of handling
logins from an http header this would be awesome in my opinion. Personally I
would much rather have the browser be responsible for logins after seeing more
and more forms use funky JavaScript which breaks standard functionality.
Persona could just be built-in or a plugin, you could just say 'log in with
Persona'. You could have account profiles, with varying levels of privacy, you
could maybe allow the end-user to decide if 2-factor auth can be used where
previously not available, there are a lot of possibilites to me and it would
standardise the process. Of course, this may just be pie in the sky but
overall I agree with the author on this.

~~~
StavrosK
We're agreeing on standardizing logins, my comment was on the implementation.
The only part of your comment about that that I can see is the first sentence
("Why not have both?"), so I will answer it: It's more complicated.

------
tptacek
I've always wished that HTTP would give a similar hint to browsers for
pagination, so there could be universal next-page keystrokes.

~~~
papsosouid
Opera has had that for years, firefox/chrome still haven't picked it up?
Between rel=next/prev and some simple heuristics, it is pretty effective right
now.

~~~
pessimism
Indeed; it’s been around for ages in Opera, and all you have to do to use it
is press Space at the end of a page to go to the next one. I think they
planned to use the attributes to support native swipe gestures on touch
devices, but that never took off, unfortunately.

You can try it on my blog at <http://pygm.us/vwR2WSYJ> or a thread in NeoGAF:
<http://www.neogaf.com/forum/showthread.php?t=559996>.

Something Awful used to support it, but they broke it by making the Last Page
button the designated `next` destination, unfortunately.

It’s really the only way to go through pagination-heavy content. Anything else
is way too tedious.

 _Everyone_ with a blog should implement this. It’s just silly not to.

------
X4
I had roughly the same idea and I got told it's impossible. Thanks for proving
that naysayers, will always be wrong! My idea was to add http-header or DnS
records that tell browsers the auth-method, path and state. The browser would
do the required HTTP Request to login. The user would have to set a key+master
password to secure his "browser wallet".

You could even solve that issue without waiting for browser vendors by adding
browser addon that does queries to supporting sites by showing a lock icon in
the url bar. When you click that lock icon, you do your initial setup with
master password and/or key(s). After that you can click the button and toggle
your login/logout state with a single click.

The Website only needs to add one php/ruby,python or .htaccess file that adds
those http-headers. For DNS you need to add some Resource record fields.

I still don't get why Opera or Firefox didn't think of it, I mean Opera has
"Unite" and Firefox has "OpenWebApps" which are in desperate need for a final
solution to "Cross-Site Authentification" using built-in secure password or
key stores..

~~~
kijin
Password manager add-ons like LastPass have already solved the wallet problem.
All they need is a reliable method to log into each site, without relying on
the user to configure the login URL. This post is an attempt to describe one
way of doing so: let website owners publish their own URLs. Another viable
solution would be for password manager vendors like LastPass, 1Password, etc.
to maintain an up-to-date database of accurate login methods for the 1000 most
popular websites as well as every well-known CMS. The database would be
periodically updated, just like AdBlock periodically updates its blocklist.
This method would require even less effort on the part of website owners.

The real reason I think browser vendors are uninterested in solutions like
this is because they are already trying very hard to push their own identity
providers: Google wants everyone to use Google accounts, Mozilla wants
everyone to use Persona, and Microsoft wants everyone to use Microsoft
accounts. Conflict of interest.

------
zero_intp
As a rule, unless you are Swifting, never start your idea/blog post with 'a
modest proposal'.

It is a set of keywords for satire.

~~~
rmrfrmrf
For those who may not know: the original "A Modest Proposal" was a 'solution'
to Ireland's poor economy that suggested selling infants to the rich for food
as a way for the poor to earn money.

------
dmoose
I clicked the lost password link on a site handling legal documents the other
day and they sent me a plaintext copy of my password via unencrypted email.

There may be issues with a central identity provider, but given the wide range
of horrible choices implemented by so many different websites I think the
assumption that keeping identity between you and the site owner is a better
choice than trusting a central provider is true only in a limited number of
cases.

If I hadn't hit the lost password link I never would have known that they keep
an unencrypted copy of my password. Finding one trustworthy central provider
at least protects you from unknowingly trusting a large number of incompetent
providers.

~~~
kijin
It's been a while since I gave two damns about websites keeping passwords in
plain text, because nowadays I use a different randomly generated password for
each website. If someone compromises a website's database, my password won't
work on any other website, and the only website where it works is already
under the attacker's control so there's not much additional damage done.

If we made it very easy for everyone to do the same, I think that the problem
of insecure storage can be circumvented for the most part, even without moving
to a centralized account management system. My proposal is basically to
facilitate widespread adoption of password wallets like LastPass. Since such
tools are already used by millions of people and does not require much effort
on the part of individual websites, I think it has a better chance of success
than trying to move everyone to use Persona.

------
__nobody
I would much rather run my own identity provider where I can control exactly
what it takes to authenticate (multi-factor, etc.) and only need to keep that
secure (which is a lot easier, because it can be some locked down server)
instead of needing to keep my passwords on my devices I carry around.

One of the major benefits of identity providers is that we eliminate the need
for a million passwords for all the sites you use, the only thing this does is
provide a perhaps more convenient way of living with the problem instead of a
solution to eliminate the problem.

Also, <http://xkcd.com/927/>

~~~
kijin
Sure, but one of the major drawbacks of identity providers is that the vast
majority of websites will never integrate with them, period. We need a
solution for those websites, too, and what I'm proposing is one attempt at
finding such a solution without telling every website owner to rewrite code.

------
jackalope
_I also considered using a DNS resource record (like SPF and DKIM), but HTTPS
is more secure._

What is the reasoning behind this statement? Resolving the hostname for the
HTTPS site still requires DNS. Is it because DNS isn't encrypted, so a MITM
could change the POST URL? That's an issue with unencrypted HTTP, also, so you
couldn't safely send this header on non-SSL pages. You'd need a login link
that goes to an SSL-protected page first, in which case this just adds an
extra (no longer useful) step.

~~~
kijin
Yes, I was referring to the fact that DNS responses are trivial to spoof.

HTTP isn't much better, either, but at least an HTTP website can be turned
into an HTTPS website without too much hassle. DNS on the other hand looks as
if it will be stuck in its current form for many years to come. With HTTP(S),
you can choose to be secure. With DNS, you're insecure and you have no choice.

------
mixedbit
The mechanism would need to somehow accommodate a login cross site request
forgery protection.

Maybe following headers:

    
    
         Auth-Spec: type=plain; csrf_token='xyz'; action=https://www.example.com/login; method=POST fields=email,password,csrf_token
         Set-Cookie: csrf_token='xyz'; HttpOnly
    

Could do the job? The submit button would need to copy csrf_token value from
the Auth-Spec to the login request.

~~~
kijin
CSRF attacks should be relatively harmless if directed at the login page. They
would have zero effect unless they got the credentials right, and an attacker
who has access to your login credentials has no need for CSRF attacks, they
can just log right in.

Edit: I'm wrong. See below.

~~~
mixedbit
Login CSRF attacks are known to be harmful:
[https://en.wikipedia.org/wiki/Cross-
site_request_forgery#For...](https://en.wikipedia.org/wiki/Cross-
site_request_forgery#Forging_login_requests)

The attacker doesn't brute force someone's credentials, but uses own
credentials to log the victim as the attacker.

~~~
kijin
Ah, didn't realize that. Thanks for pointing it out. I suppose the header
should contain some sort of nonce, then.

To keep things as simple as possible, I propose:

    
    
        Auth-Spec: type=plain; action=/login; method=POST; fields=email,password,nonce:8977340152
    

The "colon syntax" could also be used where the name of a required field is
different from the defaults (another problem that I overlooked). For example,
WordPress uses "log" for the username and "pwd" for the password, so it would
be "fields=log:username,pwd:password".

It wouldn't be possible to _require_ a nonce, though, because it would break
backward compatibility with sites that are already vulnerable anyway. As an
option for new or updated websites, though, it would be a good idea to add a
nonce field.

------
bluesmoon
There are a few reasons why this won't fly with website owners:

    
    
      - No ability to put in an anti-CSRF token
      - No ability to add an anti-phishing token (like a login image or phrase)
      - No ability to style/brand the login page
      - "Forgot Password" needs to be added somewhere

~~~
kijin

        - No ability to put in an anti-CSRF token
    

Yes, that was an oversight on my part. See my reply to mixedbit downthread for
a proposed solution with a slight change of syntax: just add another field
that contains a nonce.

    
    
        - No ability to add an anti-phishing token (like a login image or phrase)
    

The phisher can fetch those images for you, making them more or less
ineffective. Besides, the whole point of embedding a login button in the
browser toolbar and making it pick the correct credentials is that the button
will not work on any other domain. I'm trying to be backward compatible with
as many existing websites as possible, but I can't achieve perfect
compatibility with banks that won't listen to reason.

    
    
        - No ability to style/brand the login page
        - "Forgot Password" needs to be added somewhere
    

Logos and links can be added to the real HTML login page, which will continue
to exist. The API will not replace the login page. It's just another way to
send the POST request. If you don't know your password you obviously can't
tell your browser to remember it, so the login button will not work and you'll
have to visit the real HTML login page anyway.

