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.
- 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
18from 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 ?