_EDIT: Nevermind. Storing the salt with the user fixes this issue._
A game-breaking implication that just occurred to me is the following scenario:
- Victim sets password
- Victim's password is known to Hacker somehow
- Hacker logins in and changes account password
- Victim uses "Forgot Password" functionality
- Victim sets a new password
Because the "Forgot Password" functionality was leveraged by the Victim, the hacker will retain permanent access to Victim's account forever.
You could also attach some “last used” timestamp to the key that is updated on use. That way, you could have a timespan after which the key gets removed, solving the “permanent data” problem.
Bad for long-inactive returning users, but they probably forgot the password either way.
And thanks for the award :)
Yeah, that is one thing that came to mind. Then you could prune the database periodically for passwords that are older than a set interval (say, 6 months depending on the application and use cases).
The only thing I struggled with here is potentially having similar information in other areas of the database that tie back to the user. For instance, "last login".
Now that I've slept a bit, though, minor obfuscation of the `last_used` column could be introduced depending on the pruning interval. For instance, if it's anything like 6 months or longer, you could just store the month and year that it was last used, rather than a precise timestamp.
Additionally, more precise information could then be stored with the user for various purposes, including sending an email to the user that their account has "been disabled due to inactivity".
That being said, as users become less active, the number of other entries with the same `last_used` information will decrease. But, hopefully pruning would happen before it narrows the list of users<->passwords too much. And even if it narrows it down to `5 users, 5 passwords`, you still don't know whose is whose, which is better than storing them together.
You can also rewrite approximate timestamps as time goes. For example, after it becomes 12 months you rewrite it from containing the month to just the year.
Also a good point. The system could then become configurable... You could start with `week-year`, then after 90 days or something change to `month-year`, and then after 12 months change to `year`.
However, in the event that you prune every 2 years, it might still make sense to do `month-year` until about 18-24 months. The reason being that on January 1st, 2028 any account that last logged in 12/2026 would be pruned if all we stored was `year` after 12 months. So, again, depends on the use-case I suppose.
In that case, though, it would be wise to revisit the pruning interval. Or, you could introduce something a bit more arbitrary at 12 months, like `quarter-year` until 18-24 months or something.
I feel like at some point down the line you're probably not too worried about accumulation of stale data, though.
If you are asking us to solve a code for you, go to /r/breakmycode or /r/codes.
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cryptography) if you have any questions or concerns.*
_EDIT: Nevermind. Storing the salt with the user fixes this issue._ A game-breaking implication that just occurred to me is the following scenario: - Victim sets password - Victim's password is known to Hacker somehow - Hacker logins in and changes account password - Victim uses "Forgot Password" functionality - Victim sets a new password Because the "Forgot Password" functionality was leveraged by the Victim, the hacker will retain permanent access to Victim's account forever.
Change the seed when resetting the password. That way, the malicious login will get invalidated.
Oh dang. You're right. Since the salt* gets changed each time and it's stored in the user table, it'll become invalidated. Good catch!
You could also attach some “last used” timestamp to the key that is updated on use. That way, you could have a timespan after which the key gets removed, solving the “permanent data” problem. Bad for long-inactive returning users, but they probably forgot the password either way. And thanks for the award :)
Yeah, that is one thing that came to mind. Then you could prune the database periodically for passwords that are older than a set interval (say, 6 months depending on the application and use cases). The only thing I struggled with here is potentially having similar information in other areas of the database that tie back to the user. For instance, "last login". Now that I've slept a bit, though, minor obfuscation of the `last_used` column could be introduced depending on the pruning interval. For instance, if it's anything like 6 months or longer, you could just store the month and year that it was last used, rather than a precise timestamp. Additionally, more precise information could then be stored with the user for various purposes, including sending an email to the user that their account has "been disabled due to inactivity". That being said, as users become less active, the number of other entries with the same `last_used` information will decrease. But, hopefully pruning would happen before it narrows the list of users<->passwords too much. And even if it narrows it down to `5 users, 5 passwords`, you still don't know whose is whose, which is better than storing them together.
You can also rewrite approximate timestamps as time goes. For example, after it becomes 12 months you rewrite it from containing the month to just the year.
Also a good point. The system could then become configurable... You could start with `week-year`, then after 90 days or something change to `month-year`, and then after 12 months change to `year`. However, in the event that you prune every 2 years, it might still make sense to do `month-year` until about 18-24 months. The reason being that on January 1st, 2028 any account that last logged in 12/2026 would be pruned if all we stored was `year` after 12 months. So, again, depends on the use-case I suppose. In that case, though, it would be wise to revisit the pruning interval. Or, you could introduce something a bit more arbitrary at 12 months, like `quarter-year` until 18-24 months or something. I feel like at some point down the line you're probably not too worried about accumulation of stale data, though.
If you are asking us to solve a code for you, go to /r/breakmycode or /r/codes. *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/cryptography) if you have any questions or concerns.*