Passwords and Password Resets – It’s Time to Get Rid of Passwords

passwords It seems we hear about database breaches way too often. In some cases, the only things compromised are the passwords. We need to get rid of passwords.

What if I told you passwords have been unnecessary for years? There’s a much easier way to authenticate, which only drops the convenience level a little.

User Names and Passwords

While I’m focusing on regular websites, the concepts are still viable for online applications.

When is a user name and password combination considered secure? When the password is so complex you can’t hope to remember it. You need a password manager to manage all your passwords.

Would you believe the best way to authenticate is without passwords? I’m not talking about multi-factor authentication either.

It revolves around web browser cookies and one of the oldest web protocols, e-mail.

E-mail and Cookies for Authentication

I’m not an expert. Feel free to argue with me. I’ve tested this and I know it works. What’s interesting is that the e-mail doesn’t have to be secure as long as the website is secure (using SSL/HTTPS).

A secure website can create secure cookies, cookies that can’t be used if intercepted. The procedure would go something like this:

  1. The user enters an e-mail address at a website to log in.
  2. The website sets a secure cookie in the user’s web browser and stores a matching token at the server. The website then sends an e-mail message with a random link. The link expires in an hour.
  3. The user receives the e-mail message, clicks the link and heads to the log in page at the website.
  4. The website checks to make sure the secure cookie matches the stored token. It checks to make sure the link is valid and hasn’t expired.
  5. The website logs the user in, starts the session and puts the user on the right page.

To make this as convenient as possible, the cookie has to have a long life. It should last for at least a day and should only be destroyed sooner if the user intentionally logs out. Don’t confuse this cookie with a session cookie.

This cookie should start the session, letting the secure session cookie take over once the website logs the user in.

A Matter of Convenience

The most convenient way of logging in is to enter a user name and an easy to remember password. It’s also the least secure. Are you willing to trade security for convenience?

E-mail clients are available for just about every computing platform we use, from cell phones to desktop computers. Web browsers are available for just about every computing platform we use as well. If an e-mail client isn’t available, using web mail is a good alternative.

There are other ways to authenticate without passwords. I don’t think any of them are any better than this. You don’t have to buy extra hardware or software to do it this way.

If a password isn’t used for anything but your e-mail account, you only have to remember that password, not dozens, hundreds or thousands for all the websites you have to log into to use.

I have choices to make with the CMS project I’m working on (off and on). If I make it for offline use only, uploading completed pages, authentication isn’t really necessary. If I make it work online as well, authentication is definitely necessary. The e-mail method is the only method I’ll use if I set up authentication.

July 17, 2017

Web Development

Previous and Next Articles:

« »

You May Also Like:


Your comment will appear below the form when it's approved. When the page redisplays after hitting the send button (it can take a few seconds), your comment has been sent.

When replying to someone else's comment, please start the comment with "@" and the name so I can put it in the right place.

Gentleman Jack Darby (2017)

Since you said it's OK, I'll argue with you:

I think the first weakness in the scheme is assuming that there is such a thing as a secure website;

If ONLY an e-mail address AND NO password is required to log into the website that generates the secure cookie, a bad guy who knows an e-mail address or could guess it (I have a relatively common name, so I tend to get a lot of spam simply by spammer trial-and-error), would have the keys to the kingdom;

It is pretty easy to make a fairly secure password with a minimum of effort - all that is required is ensure one's password is composed of characters from all groups on a keyboard, ie; some capital letter, some lower-case letters, some numbers, and some special characters. For example, a fairly secure password would be:


By using all the characters I mentioned above, and the convention of enclosing the password in double quotes, using () instead of zero, using two word each beginning with a capital letter and separated by a period and appending the "<>xxxx", where "xxxx" would be an easily remembered numeric string, such as an old address or telephone number, military enlistment date (my personal favorite), a hacker must search through a much larger universe of characters to guess the password.

Of course, websites must co-operate by allowing the larger universe - a lot of sites limit the characters that can be used in a userID and password.

As well, sites need to get away from using an e-mail address as a userID - it's convenient, of course, but it's a major weakness.

or my money though, nothing beats two-factor authentication, especially when coupled with a serious password manager, such as LastPass, which can generate extremely secure (unable to be memorized) and also includes TFA. I can't think of anything more secure than TFA since it couples something one KNOWS (userID and password) with something one HAS (cell phone one-time PIN generator such as Google Authenticator, Yubi Key, or even OTPs printed out on paper) and it's almost unthinkable that a bad guy will ever have both. As well, with TFA, one's userID or password or both can be easily remembered (weak) since the OTP (2nd factor) compensates for that.

RT Cunningham (2017)

A good argument, Jack, but you don't understand the problem. Technology isn't the issue. People are and it doesn't matter if we're talking about the end user or the system administrators. What I wrote is quite similar to how most password resets work, except password resets don't use secure cookies to validate the confirmation links.

Yes, there is such a thing as a secure website but it requires the website to be 100 percent secured with SSL. Some websites do the half and half thing (secure on the back end but not the front) and that isn't secure enough. Shared hosting, even secured with SSL, isn't secure enough unless the site administrator knows how to keep the web space secure, including the session files. Normal sessions use the /temp directory, which is shared by all the users on shared hosting.

Again, people are the problem. Most hacks come from social engineering and phishing. Even SMS is vulnerable because of lazy telecom customer service agents. If you have enough information on a person, it's not difficult to impersonate that person over the phone.

In the scenario I listed, the e-mail address shouldn't be the user name. If the user name isn't exposed and it isn't the same as any display name used, it shouldn't be guessable. Of course, there are always exceptions. Item 4 is open for interpretation. If something, anything, has to be validated on the login page (that has to be entered manually) and it isn't something that can be guessed, any attack can be defeated. Like current username/password logins, an attacker shouldn't be allowed to try more than few times before getting the IP address blocked.

I'm not saying that routine would be perfect. Some things will probably have to be tweaked. I'll be doing some more testing when I make time to do it. Until then, I'll still be using LastPass to store the password for the site I'm working on. The biggest weakness with passwords occurs when registration occurs on unsecured sites. If e-mail can be intercepted, a would-be hacker just needs to wait until the appropriate time to login as the registrant.

The reason we still use passwords is because no one has thought of a better way that can be done on a computer with what's already available. I'm working on that better way.

Gentleman Jack Darby (2017)

Oh, I do understand the problem and I agree with you 100% that the problem is people.

One of my major job responsibilities for most of my career has been managing an IT department and it's unbelievable what I've seen end users do when it comes to security in general and userIDs and passwords and phishing e-mails in particular.

When we upgraded the IT environment at my current shop, I made sure that our web presence was handled by an outside firm using their infrastructure - totally separate from our internal system. I mention that to illustrate that I don't know much about running a website, but if I understand correctly, SSL applies to the transmission of data between a website user and the website.

When I made the comment about no such thing as a secure website, I was thinking more along the lines of security vulnerabilities introduced by the things that it takes to make a server, in this case a web server, run - things like the OS, the underlying database, application programs, etc. I guess I would be concerned about a rogue program that co-opts the cookie and link process on the server end and because users are not entering something only they should know (a strong password) and something they have (OTP), it's my opinion that users would be way too trusting.

I re-read your original post and if I understand your scenario, if I'm a bad guy and have your e-mail address and enter that into a website, the web server will set the secure cookie. So I guess I'm stuck on these questions:

If the only authentication is entering an e-mail address at a site, how does the website know that it's really you (good guy) and not me (bad guy)?

Or, do I still have to have a userID and your scenario simply provides, in essence, a one-time password?

And, since the website would have to have both the users "registered" e-mail address a la password recovery and a userID, it seems that a server security breach that compromises these things plus the ability to generate the secure cookie (password) would be catastrophic since, in my opinion and experience, almost all people use the same e-mail address all the time and most people would probably use the same userID on most sites (so they could remember it easily). I'd think that this would allow the bad guys to try the compromised credentials on other sites, since they won't have to worry about the secure cookie (password) (if your scheme was widely adopted) or an OTP in TFA.

E-mail addresses by their very nature are not secret and I think asking most users to remember both a user name and a display name and and keeping them straight is probably asking a bit much.

Anyway, that's why I visit and enjoy your site - it makes me think.

RT Cunningham (2017)

You got the idea. It's a one-time password, every time, for logging in.

Again, I have to do more testing. It works as is, but only if the right ingredients already exist. For example. If I want to login to my test site, I enter my e-mail address and click. Then, I check my e-mail account for the confirmation link and click it. I don't see it, but the cookie was set on the first visit and it's being checked on the second visit.

The e-mail message sent from the server is secure (using TLS). Gmail web mail is secure. No one will intercept the message and get the confirmation link.

If someone else enters my e-mail address and tries to log on, that's as far as they can go without the confirmation link. The cookie contains a token that matches the confirmation link. A token on the server matches the cookie itself. Everything has to match on the second visit.

With a secure website, secure e-mail from the server and secure e-mail where it's received, it's 99.9 percent impossible for anyone else to impersonate me. As long a my e-mail account is secure, my website login is secure.

The problem I have to work on, and that's where a user name or security question comes into play, is when their e-mail messages can be intercepted. Some people refuse to use Gmail, Yahoo Mail or other secure web mail providers.

Subscribe to Articles by Email

RSS Feed Link

Books by William James Asberry

Comments Policy
Privacy Policy

RTCX established February 28, 2011