The Problem

Modern web application usually supports a number of authentication methods. But almost all web applications still support authentication using login-password pair. It is usually named “simple” by developers. So the article is about it.

User should not use one password for different web services. It is recommended for security reasons. However, it is almost impossible for human to remember a number of passwords for a number of web services. Fortunately, there are applications, so known password keepers, which help to use different strong passwords for different web applications.

This is how typical password keeper works. It keeps all user’s credentials in a storage encrypted by master password. The user have to remember only the master password to be able to access the storage. Whereas all other passwords can be long randomly generated strings, because the user never enters them manually, password keeper does that. So, here is the problem. Authentication and registration web forms are designed for human. Thus, password keeper have to use a tricky algorithm to recognize such forms. Even though it works well in the most scenarios, there is one where password keepers are useless. It is password changing.

I keep my passwords in LastPass. After Heartbleed incident had happened, I decided to change them all. I spent whole Friday night sipping Scotch and stupidly clicking:

1. Go to a web site
2. Login
3. Change the password
4. Logout
5. Go to the next one...

It definitely should be done in one click by password keeper!

Possible Solution

I am not going to propose a detailed solution, it is a subject for big discussion. But here is a rough one. The main idea is that web applications should provide unified REST API. So that password keeper applications will be able to interact with any web application using the same API. Such API should include endpoints for: user registration, authentication (login), deauthentication (logout), changing password, and utility one for testing available user names (it will be used during registration to indicate whether a user name is already in use). Description of the API can be provided by a file hosted at the root of web application (similar to robots.txt, favicon.ico, and sitemap.xml). Let it be simpleauth.json. Here is an example of one:

{
    "endpoints": {
        "login": "https://example.com/simple-auth/login",
        "logout": "https://example.com/simple-auth/logout",
        "register": "https://example.com/simple-auth/register",
        "testusername": "https://example.com/simple-auth/testusername",
        "changepassword": "https://example.com/simple-auth/changepassword"
    },
    "password": {
        "min": 6,
        "max": 255,
        "chars": ["a-z", "A-Z", "0-9", "!@#$%^&*()-_+=|\/?.,<>"]
    },
    "username": {
        "min": 3,
        "max": 30,
        "chars": ["a-z", "A-Z", "0-9", " _-."]
    }
}

It describes endpoints and restrictions for password and user name. So that password keeper will be able to automatically interact with web application using this information.

The goal of the protocol is improving of security. For instance, you can tune your password keeper to change password after each login. So that, you will use new password for each session. Of course, there is a possible problem, that the protocol can be used for bruteforcing. But I think, it is solvable by restriction of number of unsuccessful requests.

In conclusion. If you think, it is worthwhile, share it, because without buzz it will be just idea. Again, we need efforts of the whole community, to make it real. Proposals and criticism are welcome too.