Is mixed password secure?

When I came up with an idea of Aksesi project, I started to think about its security. First thought was that it will be as safe as HTTP(s) protocol is. Realizing it, I stopped any considerations. Three weeks later I realized that this solution will be very safe or, at least, safer than ordinary password usage.

In this post, I’m going to cover a few reasons why Aksesi will be safer than classic authentication which bases only on passwords consisting of characters.

I would like to remind you that all of the sources are available in my Github repository. Moreover, in the README file, you can find short project description with its main assumptions.

Password length

Every time hackers massively break into bank accounts or government sites, media are alarming all of the Internet users to set long passwords which should consist of different letters, numbers and special characters. That’s all perfect but users are usually just lazy. They don’t want to set new passwords let alone long.
Applications deal with it by adding salts to a password’s string representation. Often passwords stored in a database are created with following (or its variety) pattern:

sha1(md5( + user.password + unchangeable string))

People interested in cryptography know that sha1 and md5 are hash functions which mean that there is only one way to find the input value. It’s named brute force search and it bases on providing all of the possible permutations of the input. For short inputs, it works very well but its speed decreases with the length of an input string. For more information about brute force search please visit Wikipedia.

Let’s summarize:
password -> processed by hash function -> stored in the database -> brute force used to recreate -> attack speed depends on the length of input string -> length matters

Knowing this, imagine: huge social media portal was hacked, application source code has been published, databases leaked. Attackers have the easy way to steal access to the user accounts because they know the pattern. But the red part is still missing:

sha1(md5( + user.password + unchangeable string))

The only sensible thing to do is to start brute force and wait. If you have long password, then they will spend more time trying to get access to your account. It is even possible that they’ll never get it. Again, length matters.

So the question is how does Aksesi help with this? Aksesi will make red part longer and completely transparent for the application users.
When a user registers an account, the application will convert gesture into its textual representation which length will be configurable, like below:



a(string representation of line1)b(string representation of line2)c

For the user, the password has the same length: 3 characters and 2 gestures but for the application/database it is string consisting of many characters. Having password converted application is ready to process it through hashing functions and save in the database.

By adding only ten gestures that Aksesi will be able to recognize, we get 5 times more combinations. The complexity will tremendously increase. For example:

Size of characters set: 24 Size of characters set: 24
Size of gestures string representation set: 10
Size of possible password elements set: 24 Size of possible password elements set: 34
Password length: 5 Password length: 5
Number of combinations: 24^5 = 7 962 624 Number of combinations: 34^5 = 45 435 424

Above calculations assumes that attackers know gesture textual representation.

Password captured in the HTTP request

Almost all of web applications based on the HTTP(S) protocol. It means that all of the data are going over the Internet as a plain text. If a website is using the not secure version of this protocol (like my blog xDD) it is easy to catch password part in the whole message and then reuse it to steal an account.

Aksesi makes this process harder. From the web browser password are sent as a:


If a hacker doesn’t have access to the converting application, then sets of points are useless because it is almost impossible to find missing parts.

Passwords stored in the browser

Modern web browsers want to be more user-friendly and they ask you if you want to save submitted password. Probably some of you know that we can steal password saved in the browser with ease. For those who don’t know short video:

Easy, right?

In the post Stop making those weird gestures, start typing! I described that if a user will draw a gesture then a new character will be appended to the text input.

What will we get if we will save password passed through the Aksesi form? Something like:


Equation with two unknown values. Same like in the previous paragraph. Due to the number of combinations, it is very hard or almost impossible to guess them.

Non-trivial conversion mechanism

Mechanism of converting gestures can have a lot of implementations and use many different types of gesture patterns. It can even use artificial intelligence for recognition purpose. This wide stack of possibilities improves the complexity of converting gestures into the textual representation.

As you can see, it seems that Aksesi is going to increase the security of the applications which will be using this mechanism. Of course, there are some limitations, e.g. it will be impossible to store a password in the web browser storage if a gesture will be used. Limitations like this can be resolved by writing a highly specialized plugin for browsers.

You may also like