This question already has an answer here:
One customer is facing a problem with his users: they use a (web) service a few times per year and they forget their credentials very often. There is a standard password recovery procedure but many of them simply call customer service every single time (asking them to generate a given password). This has few bad implications:
- Customer service staff knows all their passwords.
- Users keep customer service busy (and when it's not working time these calls are expensive for customer).
- Users can change their own credentials to something meaningful but they simply don't care because they use this service only two or three times per year so they want to get things done as quick as possible.
- To add a "remember me" checkbox is not an option because it's (in this case) prohibited by law.
- Site stores very sensitive medical information.
- Customer wants to save money so hardware devices (such as smart-card readers and/or fingerprints readers) are not an option.
To solve these issues the customer is asking me to generate an unique ID for each user, this ID may be added to the URL to automatically authenticate that user. For example:
Users may decide to save this ID where they prefer (link on desktop, browser favorites, write it down on a post-it) but the customer himself is not responsible for that (remember we can't provide a "remember me" feature because of law).
I'm not talking about an authentication token (stored as cookie instead of username+password tuple, like discussed Why use an authentication token instead of the username/password per request?) but an URL parameter.
- This auto-generated token is long enough (let's say 30~60 characters) and sufficient random (mixed case alphanumeric string).
- Basic security measures are used (very long delays for unknown tokens and IP blacklisting).
- I'd store these IDs separately from normal credentials, hashed (of course) and with a different algorithm/parameters than passwords (because of its length it may even be simpler or do I still need Bcrypt?!)
- Parameter is removed from the URL after authentication and user is redirected.
Is there any other security concern that I don't imagine? Does this make authentication too weak?
Possible issues I can think about is that URLs are stored in browser history...
Little bit more context: customer would keep his own list of fixed (not changeable) tokens associated with users. Just before they need to use his service he would send them all an e-mail with mentioned link (batch generated e-personalized e-mails). In my example the protocol is HTTP but in reality it's HTTPS (even if I don't have any control over this).
Additional question: Will making this token temporary help? Each time a new e-mail is sent then a new token is generated (with a relatively short expiration time, one or two weeks).