The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.
By jakeg on
When people first register with a drupal site, they often find the logging in process difficult because the password is so confusing and sometimes copying and pasting it adds an extra space etc.
On sites I've made before, I've made the login process for people easier by providing them with a link in the initial email to them which gives them a link such as:
http://www.mydrupalsite.com/?l=username,password
In other words, by clicking the URL they're automatically logged in, ideally to a page for them to change their password to something they'll remember in the future.
They key to getting this right is to make the URL as short as possible so it won't get wordwrapped half way through in people's mail clients. So:
http://www.mydrupalsite.com/user/login/firsttime/username/password
is less desirable than:
http://www.mydrupalsite.com/?l=username,password
Thoughts?
Jake.
Comments
Too easy to copy space at front of passwords in welcome email
In the welcome email that goes out, one problem is caused by users accidentally copying a leading space around the email. The email goes out like:
password: somepassword
and the accidentally select ' somepassword' then paste that in to login.
One solution would be to change the default welcome email to:
password:
somepassword
i.e. on the next line down, without a leading space.
Another solution would be to do as i suggest in my post above.
Another would be to automatically strip leading and trailing spaces from passwords. However, this may of course cause problems if leading/trailing spaces are allowed in users passwords. Are they?
Security concern and solution
If you're concerned about the security implications of using this type or URL to login, one idea could be to give new users a grace period in which to use the special URL of perhaps 12 hours. In other words, the URL will work (as many times as its clicked, not just once) perfectly for the first 12 hours, after which time it doesn't work, and gives the user a page which asks them to login manually instead.
Users would be highly encouraged to change their password on the page the link leads to.
This is a good idea
You could format the URL in such a way that the username, timeout and a hashed version of the password are all passed. This way you can avoid long URLs AND have added security.
http://www.mydrupalsite.com/?l=username&t=A0A0A0A0&h=A0A0A0A0
This example comes to 60 characters... assuming people don't choose obscenely long domain names and user names, this shouldn't get truncated.
l= the username
t= the timeout as a unix datetime represented in hex (less space)
h= a hash using MD5, SHA, unix crypt, whatever... you hash the combination of the username, timeout, and the actual (or hashed, I dont know what Drupal uses).
When the server gets the message, it hashes together the same information and compares it to the hash passed as a part of the URL. It should be the same. You can check the timeout as well to make sure it hasn't passed by already.
Wherever possible you want to avoid passing around passwords in emails, etc. anyway.
overkill
kilna, thanks for the input. but...
- the timeout should be stored in the database and not in the url string. it makes no sense in the url string at all. someone could just enter a new one in it if they wanted.
- user login isn't normally over a secure server. people enter their password in plain text in their web browser. so why hash the link in the email? also, the idea is to get them to change the password as soon as they're logged in. i see no reason for hashing it. also, the plain text password is given elsewhere in the email anyway. of course, you can change the whole thing so that the email is just a verification link such as you suggest, and then the user sets their password. that is also a great way of doing this... though my method should involve less change to the core code.
Login-less URL in signup email, using digests / hashes
Seeing as you think someone can spoof the timeout in the example I gave, I'm under the impression that you don't actually understand how digests/hashing works.
If you change one bit of information in the stuff that creates a hash, and the hash comes out 100% different. If the timeout is included in the hashing, and the hashing is checked on the server, then the user cannot change the timeout. The reason the timeout has to be passed seperately is that we need to know it to re-hash on the recieving end to know that the authentication wasn't spoofed. This is also why you need a secret string set on the server side that does not change, that is also included in the hashing.
Emails are often stored forever on the user's drive, so putting a plain text password in it is inherently less secure. Yes, I know that passwords go over the wire in plain text in most installations, but it isn't in ALL. For a user running a Drupal site over SSL, sending plain text passwords over email is a huge hole. Maybe being secure is 'overkill' for you, but it isn't for everyone.
You can do this without extra database tables, and have it be inherently more secure than sending plain-text passwords.
just for the heck of it
Think you could tell us how to do just the username and password in the url, even though it may not be secure. I have a different issue - but this would solve my problem and I don't have the security issue. So, how about it?
This doesn't work, but would something similiar?
http://www.drupalsite.com/?l=name&p=pass
--Ryan
Ryan Cross
James Cross Construction Services
Project Management Software
you can't with drupal out of
you can't with drupal out of the box. thats just in my own non-drupal site. however 4.7 now seems to have a loginhash feature which does the same thing, which is great!
password trailing space confusion
I found that the problem is actually a trailing space in the 'Body of welcome email'. e.g.:
Password: e3lbowlowb
has a space at the end of it. So if someone tries to copy and paste it they more often than not pick up the space as well.
NOT GOOD!!!
Has anyone else had this problem? Any fix?
TRIM()
I never understood this whole trailing or leading space issue...
As a standard, a simple trim function make complete sense to me. I always include that in any password field as well as most GET/POST variables just in case someone starts a field with a space by accident. Am I alone out there?
Unless I am missing that one personal out there that somehow makes their pasword start with a space. The solution should always be on the server side and not dependent on the client.
I encourage you to check out this post: http://drupal.org/node/18719
We have been dealing with this whole thing for some time now.
David McIntosh
neofactor.com
yes i agree, you should use
yes i agree, you should use trim(), that's what I always do on other sites. But the question is this - does drupal allow spaces in passwords? if it does, and it allows them at beginning and end of passwords, then this'll obviously cause a problem! (remember, the passwords are stored as hashes, so you can't trim those hahses too, it doesn't work like that).
whenever i setup passwords and usernames, i *always* on the server side do a trim() and a strtolower() before putting usernames and passwords into the database, and also when a client tries to login.
Trimming
Spaces are not present in stock Drupal passwords.
The user_authenticate() function could easily pass the password through trim functions.
strtolower() is not desired.
See discussion here.