Can use this security system on websites?

Question

I have created a password security system. I wanted to get your reviews about it and its technical problems.

In this system, users create a dynamic password that will change every time they try to log in based on their unique formula they wrote when registered.

Example of password created: apple{{A+2}}{{B+C}}{{D*E}}green

When user wants to log in on the browser, the server sends 5 random one digit values like:

 1,2,3,4,5

corresponding to A,B,C,D,E respectively.

and now user has to enter his password like :

apple3520green

This protects the password from being exposed , as it can't be compromised because it will change every time.

I have created a demo version of this implementation on http://advpassword.com And I love to have your comments about it on the website ( Good or Bad )

Answer 1

Don't forget AviD's Tenet of Usability:

Security at the expense of usability comes at the expense of security.

This is what makes this scheme unusable, for any security properties it may have over any other form of password. It would be simply inconceivable to expect for people, who have as many issues as we have with simple passwords, to try and cope with random new algorithmic password schemes that require not only remembering a password, but remembering an algorithm associated with the password, and plugging in a new set of variables every time you need to use the password, and calculating it correctly. The entire idea is a disaster of complexity.

Ultimately, this is a (relatively) solved problem. Multi-factor authentication is the solution. It's secure above and beyond simple passwords, and far less novel and complex than what you propose.

There are very specific scenarios where this scheme might be useful, but common services are not one of those scenarios.

Answer 2

There are following problems with this approach:

1. The passwords with formulas seem to be stored in plaintext. So this would be better if it's split into two parts - first part known, and second part being formula. This way the first part can be stored as hash.

2. Similar mechanism is used by crypto tokens, where you enter password followed by number from crypto token (like "password" + "123456" which is "password123456"). Crypto token is small hardware device which shows number after pressing button. Every crypto token hardware has different key so everyone needs to use their own token. Now the thing is, that the problem is that formula is very easy to reverse if it's very simple. In fact, it should be some sort of strong encryption which person cannot perform in memory.

Anyway, you seem to be on good track and what you are trying to do can be achieved in following way for example:

1. Create software crypto token application, so this app will simply agree the secret key with your server during installation and will be able to generate crypto tokens in offline (or even online) mode.

2. Your website can read the password and remove last 6 numbers, then check the password with stored hash. (the 6 numbers change very 10 secs or minute or so, so the time synchronization is important, but if it's none, it's possible to synchronize by checking past / future tokens and do the adjustments).

3. Then your website can contact API and check if the crypto token for given username matches.

Now the thing to know is that crypto tokens work on time and secret key. So that token generated in one minute isn't valid in different time.

However the main challenge would be to protect the security of your crypto tokens. You could provision dedicated cloud server for each customer using it for example, permitting access only from his servers and maintain extreme update schedule for security patches, multi-layered defense and good software architecture where all libraries are actively maintained and the source code is audited.

Such solution would be eventually good not only for websites but for any corporate system including Active Directory. However to sell it to customers you'd need to comply with official security policies once and secondly have it reviewed by educational / government institutions which I am sure will be helpful.

The overall proposed scenario is good because on your side you do not risk much really - if crypto tokens are stolen, then the passwords are not known anyway, and you can issue update to the soft crypto token or force reactivation of these.

The downside is that it requires dedicated soft crypto token to get onto some single service which would be using it. So the hardware crypto token is a lot more handy, but the soft one is still good for demoing and development.

Regarding "enter letter 1, 3 and 5 from your second password" is somewhat weaker but a lot cheaper compared to tokens. However to produce token is not hard today given it's long life and a lot stronger security.

The business model of this is based on maintaining both secure method of communication and proper secure storage of crypto tokens, so the whole business on your side has to properly focus on it, so it's job for 3rd party companies and not banks themselves. This way attack surface is reduced the way that the tokens are stored and verified by 3rd party company.

Answer 3

I don't think it's a good thing. The calculation thing and translating letters into digits is simply too complex for most users. They want it to be fast and easy. In addition, the fact that the rule needs to be stored in cleartext mandatorily in order for the scheme to work is a major security design flaw.
And which problem does this solve that hasn't already been addressed? Why not a simple 2-factor auth with TOTP? Reinventing existing things in a slightly different way usually doesn't make things better.

Answer 4

It's not user-friendly and incompatible with password managers, so any normal user will keep their formulas as trivial as possible.

That means any attacker who intercepts multiple number / password pairs can reverse-engineer the formula quite easily. Doing this interception on your example implementation is easy because it doesn't support https.

Answer 5

I do like the idea although, I feel you might have missed the target.

Explanation

I do agree with others on statement roughly telling that this kind of sophisticated mechanism seems to be pointless at client-server authentication. There I would agree with the recommendation to use some kind of hardware token. ...but still there is a room for your proposal

How to authenticate on a hardware token

...or mobile phone lock-screen etc.

Imagine a case, that someone might try to force you to unlock your phone. If it was protected just by a pin code (kind of password), than you will need to disclose it. When any kind of dynamic password is used... let say date based and with the challenge appearing on a screen. He or she will not be able to reuse it.