Different password for each login - based on some variable

Question

This might sound a silly question, but I was thinking this as and extra option(which is not required) mainly for advanced users, who want to protect their accounts even more. Lets consider that other security measures exist(e.g. protection against online brute force attacks, requiring strong passwords when registering/updating the password, warning the user for possible failed login attempts, requiring some extra info when logining in from unknown IP or between two distance locations within short period of time, showing the list of active sessions (like in gmail), 2 factor auth etc.). So, this is like trying to add extra layer of security.

Here is the idea. When the user activates this security option, he has to choose the variable type that he should concatenate to his usual password when trying to login. E.g. the user can choose the current (day + 7). So, if my password is myPassword, and today's date is 11, then I have to type myPassword18. Which means that if I have to login on another day I will have to insert another "total" password - based on that day. Of course the date is an example, it can be different variable type, e.g. the first 3 letters of my current ip address (in case if the user frequently logs in from different locations), maybe smth associated with a browser(and/or its version), so the idea is to have smth that constantly changes, but the user can easily identify that change and make the right input.

Though this will create issues with browser's password autocomplete, but who do not need that autocomplete, I guess it will be no problem from that viewpoint.

Validating the user's password during login: I am using password hashing/validation as it is described here https://crackstation.net/hashing-security.htm#properhashing

so, the hashing part looks without issues, and I am hashing only the myPassword part of course. During validation when I fetch the user's data from the database I can check and see that that option is enabled, and based on the user's choice I can calculate what should be concatenated to the "main" password, so it will be checked and if valid, will be cut from the string for validating the password.

So,

• If that security option is disabled it will be a usual password validation
• If enabled, lets say the user chose current (day + 7) option, then I know that the password should end with 18, if it does not - then login failed. If its correct I will delete that 18 from the password provided by the user and check the remaining string's validity comparing it with the password's hash that was fetched from the db.

I admit that overall this makes the login process more complex (which is bad), but on the other hand I guess it might be helpful if someone saw your password (directly or maybe through keylogger, or just when you accidentally clicked save in a non-trusted computer), because next time that variable part(possibly) will be changed and that last number/string will be already smth else, and if the malicious user tried to login, the account owner will be notified that someone tried to login from whatever ip/location, providing a valid password (the first part), though failing to give the correct second parameter(variable part), which might help the user to change the "main" password and/or the password variable part.

Any ideas whether this might boost the security or there are some flaws that I did not consider that will have the opposite effect ?

Thanks

Answer 1

While this is an interesting idea, I would suggest keeping it normal as you have it but give users option for 2 factor authentication in their account settings.

In this when a user successfully enters their credentials, they would be emailed a link to click / follow. Once followed their session would be started.

You have to assume your clients are stupid, over complication login features with variating passwords will confuse them.

as for extra features for security many websites use features such as:

1. approved devices
2. 2 factor authentication
3. advanced logging
4. IP restrictions
5. fail2ban (x amount of tries = lockout)
6. advanced analytics suggesting the real person isn't using the account (common with banks)

I hope some of these features give you some good ideas.

WARNING:

Your idea might interfer with password security, adding data onto the end of a hashed password could cause numerous errors, you should never be able to decrypt passwords and to do this something like this right you would want to change the password hashes in the database to have that number added onto it. I see you did mention hash and therefore you cant reverse the obfuscation. Though once again I do suggest that you avoid your idea as if this is a feature everyone knows about it.

anyway I imagine you would do this number feature would either be:

1. Predictable and therefore pointless (if i was a hacker I would simply expect this)
2. dirty coding forcing the feature rather than applying extra security

Answer 2

The biggest problem I see is that it doesn't help against offline attacks, or it hurts them.

You had better be salting and hashing the password, or else you're dramatically weakening the password security. And if you're doing that, then this has to be done by an external call, and all that remains is security by obscurity.