Tag “Design”

It is not my regular article, it is the appeal for IT community. If you think, the thoughts stated below are worthwhile, please share them. To make it real we need efforts of whole community. Thus we need to make some buzz.

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.

So, a product owner created a ticket with the text from headline of the article. You got it into sprint and started to work on it. How will you implement it? Usually we think that e-mail notification is something asynchronous. We can send it anytime. Commonly at night, when our server is under low load. User will read it in some time, but not right after you have sent it. It was true before we have gotten smartphones. Nowadays most of e-mails come instantly with loud notification sound. And user will not pleasured to hear this at sleep time. Therefore I think it is not a good idea to send e-mails at night. So next time you will implement such feature think about it.

P.S. Thanks to LinkedIn for this article. I am very happy to get notifications at 3AM when someone from my connections is celebrating a work anniversary. That is completely what I need to have a good night. And guys... I pointed my location in the profile. It would help to detect my time zone.