Can I replace username and password with a long random text in URL? [duplicate]

Question

Scenario

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.

Question

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:

http://www.example.com?user=abcdefg12345

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.

Assuming:

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

EDIT

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

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.