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).

Note that:

  • 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).

  • 4
    Vulnerable to sniffing if it isn't done over https (and you don't have complete control over that, actually). More vulnerable to theft if the users computer is infiltrated (well-implemented "remember me" functionality is more secure), and then you somehow have to re-issue. If people aren't remembering passwords now, wouldn't they already be writing them down on post-it notes? I seriously doubt a 30-character one is going to help there... Dec 3, 2015 at 13:14
  • 1
    How about a system to request for a password reset where the website sends an email with a session token and allows the user to set a new password based on certain authentication questions like SSN? it is in fact a somewhat slower process for the end user but since they dont use it so often it may be ok
    – Purefan
    Dec 3, 2015 at 13:32
  • 1
    @Purefan I may like it but I saw those users. They're (in average) old and non-technical, they must use this service but they see it as a waste of time and they want to be done with it...using mouse and keyboard as little as possible. That's why they would appreciate a single-click solution (no questions, no e-mails to check). Dec 3, 2015 at 13:43
  • 1
    It is but it's not for customer (SMS aren't free). HOWEVER your idea to send a session token can be applied: in their first notification e-mail they receive that link, if they remember password then they're done but if they don't they can use that link to create a new one on-the-fly... Dec 3, 2015 at 13:48
  • 4
    Besides concerning "Users may decide to save this ID where they prefer": If "remember me" is forbidden by law, encouraging the user to self-implement something similar is not forbidden? IMHO it's the same level of insecurity...
    – glglgl
    Dec 3, 2015 at 16:05

4 Answers 4


Even though the entropy in a large random token suggests that the token would be a secure mechanism of authentication, there are many problems associated with it:

  • The token is fixed per user, so a user can't change the token if they suspect it is compromised.
  • The token could be used unlimited times, which increases the opportunity for compromise.
  • Based on your description, the customer may know the tokens for his or her employees. While the data may be the same (or have the same access restrictions) for each account the customer manages, this compromises non-repudiation. The customer could use an employee account and no one would be the wiser.

There is a Process Problem

As you have pointed out, having customers call customer service to change a password has two significant problems:

  • First, it is inefficient for your business, and is costing your business and your customers money.
  • Second, it is dangerous from a security perspective.

Consider how allowing customer service to reset passwords affects the application security:

  • Any customer service representative can reset the password (and based on how you describe it, actually set the password) of any customer account, and can therefore access the confidential information of that customer's account.
  • Depending on the procedures for the phone-initiated password reset, the process could be susceptible to social engineering.

Use the Random Token to initiate a Password Reset

Customers who need to change their password should use the existing web application to request a password reset. This could ask for an email the account is registered to, and optionally, a set of security questions (depending on your own risk assessment). Next a password reset link with a random token is emailed to that email address. This link should only be valid once, and should expire after a short time if not used. When the user clicks the link, they are authenticated. Most web apps will have the user set a password at this point. In your case, you may want to allow the user to skip setting a password, since they will forget it anyway.

Customers who call customer service to reset their password should be instructed to use the password reset feature. The customer service rep may remain on the line and walk the customer through the procedure, but the key point is that the customer does the reset themselves. Once a customer resets a password themselves, they are less likely to call in again.

  • @MichaelKjörling I tried to make the same point as well. When I say "Most web apps will have the user set a password at this point. In your case, you may want to allow the user to skip setting a password, since they will forget it anyway". This technique would allow for both a user not wanting to set a password, and a user who still wants to set a password.
    – amccormack
    Dec 3, 2015 at 15:22

This is almost equivalent to passing the password as a GET parameter, which is bad. It's discussed here: Is there a difference between GET and POST for web application security?

Also, in your example URL you are not using HTTPS. Sending your password in plaintext over the network is also bad for obvious reasons.

Next, can a user change their token in the case it's compromised? Are you sure they won't lose this token? I mean, they could also just write down their password.

As an alternative, you could use basic authentication over HTTPS. This is a standard authentication technique and it can be written in form of a URL such as https://user:[email protected]/. I doubt it will be saved as a bookmark, but most browsers should offer a "remember these credentials" function.

  • My bad I used http in example, it's actually https but I get your point. Customer would even keep his own list of (unchangeable!) tokens to batch send e-mails to his users (just before they have to use this service). He has not access to their passwords but if token is fixed...Anyway I get your point! Dec 3, 2015 at 13:19

Your proposed scheme basically corresponds to OWASP 2-nd most dangerous web application security issue: broken authentification and session management. OWAPS site explains the issue well enough:

Airline reservations application supports URL rewriting, putting session IDs in the URL: http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii

An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.

Also consider that each URL typed by a user may be send to his browser maker and/or preferred search engine (cf. Google Chrome privacy policy).


This is an expansion on amccormack's answer.

Allow the customer to initiate a login by entering their email address. When they have entered the email address, use that to validate that the user is allowed to log in, then send a one-time, short-lived token to the user's email address. This could be in the form of a web link with suitable nonces, or a key that the user needs to copy into a field on the next form (wizard style login). Validate that the token entered matches the one sent for that email address, and that it is still valid. Make sure to allow a few hours initial validity in case of greylisting, but also only single use so a token cannot be reused.

In this case, the user won't have to remember anything special for your service (only their email address, and access to that email account, is needed), and the scheme is likely no less secure than any other pure reset-password-by-email scheme you can come up with.

Also, in the future, you can extend this by allowing for token delivery over SMS (or any other delivery channel you can think of), with minimal changes to everything but the token delivery code.

Not the answer you're looking for? Browse other questions tagged .