Author Topic: Registrations on Websites: User Chosen Password vs. Assigned Password? (Read 19,067 times)

mouser · « **on:** February 15, 2011, 02:54 PM »

I'm not sure exactly where to look but I'd be interested in reading anything about the pros and cons, or hearing people's opinions on the issue of whether a website should ASSIGN users a password (by email) when they sign up, vs having the use type one in themselves.

I've seen both on the web. Forums tend to almost exclusively be set up to have user choose their password.

I see some serious pros and cons:

When user chooses their own password:

The main advantage seems to me that you never have to transmit by email their password, which means little risk of it being discovered by someone malicious through email sniffing, etc. (not sure how much this happens in real life as opposed to a theoretical risk)
And a minor advantage is user can pick one they can remember.

But the advantages to emailing them a generated password seem very substantial:

Site can insure that every user has a strong password -- this eliminates the very real world attacks where people's passwords are guessed because they are too simple.
While you can write code to insist on strong passwords, you cant stop the very real and most dangerous kind of real world attack, which is where people use the same login and password on multiple sites. This is one of the most serious ways that security is breached in the real world and we've talked about it in the past on the forum.
Users dont have to come up with passwords and remember them -- so registration is simpler, less error prone, and they have their password mailed to them which means they can always find it later if they forget it (another real world problem that happens frequently).

So you might have guessed that i'm starting to learn towards the idea that the risks/benefits favor having a site automatically generate and email a password to a user at signup, rather than asking them to enter one manually during registration. It seems to me that if you allow them to optionally change their password once they log in, that might be the best compromise and give people who are concerned about email sniffing an option.

Thoughts?

Paul Keith · « **Reply #1 on:** February 15, 2011, 03:26 PM »

Quote

Site can insure that every user has a strong password -- this eliminates the very real world attacks where people's passwords are guessed because they are too simple.

Most people would just change it to something simpler. Bad habit but convenience > theoretical security.

Plus it is perceived as more like an unlocked code.

Quote

While you can write code to insist on strong passwords, you cant stop the very real and most dangerous kind of real world attack, which is where people use the same login and password on multiple sites. This is one of the most serious ways that security is breached in the real world and we've talked about it in the past on the forum.

Most popular sites tend to do the opposite now. Allow for Twitter, Facebook and Google logins. (if they have no OpenID)

Let those sites be attacked and hacked first. Chances are if that happens - there would be a universal pattern of behaviour as opposed to an isolated case where one forum is manipulated at times.

Quote

Users dont have to come up with passwords and remember them -- so registration is simpler, less error prone, and they have their password mailed to them which means they can always find it later if they forget it (another real world problem that happens frequently).

Again, one user account logins work better. They still have to remember their e-mails which is...well worse than at least knowing the e-mail and the site could be separate. Personally in this day and age, outside of spam, I don't even get why e-mail activation is beneficial to the user now that there are password managers in browsers.

app103 · « **Reply #2 on:** February 15, 2011, 03:30 PM »

If they are going to end up changing their password once they first log in with the one you assign them, it kind of defeats the whole purpose of it all. You will still have all the negative aspects of allowing users to choose their own passwords.

mouser · « **Reply #3 on:** February 15, 2011, 03:43 PM »

I guess my thought was that 98% of users would *not* change their passwords, but perhaps the 2% hardcore users who are security conscious would want to be able to..

40hz · « **Reply #4 on:** February 15, 2011, 03:51 PM »

I think it's kind of moot if you allow them to change it.

Most people opt for simple, obvious, and readily hacked passwords.

If you don't allow them to change it, they either forget and constantly keep requesting it be resent or reset - or - they write it down somewhere handy. Usually a post-it stuck on their monitor. And so much for security.

It's a no-win situation either way.

We need to look outside the box. Passwords aren't that workable a security mechanism for most people or applications.

Time to rethink...

f0dder · « **Reply #5 on:** February 15, 2011, 03:55 PM »

I'd never choose "generate password for user". Either let them pick one themselves, or go with OpenID.

JavaJones · « **Reply #6 on:** February 15, 2011, 07:15 PM »

Agree with f0dder and 40hz. Generated passwords are usually forgotten or changed (if allowed). And hey, email *sniffing* may not be that common (i.e. plain text packet detection, SMTP relay hacking, whatever), but hacking of *email accounts* is quite common, and if you're worried about a central place where all passwords are stored that can be hacked, well email would be it if you assume users keep their generated password emails in there for reminder. It's really not an improvement IMO, and possibly worse than just requiring a certain level of password complexity (and not too insane a level either, I say 8 character minimum with at least 1 capital letter and 1 numeral, nothing more, forget special characters).

- Oshyan

barney · « **Reply #7 on:** February 16, 2011, 01:08 AM »

You might consider suggesting password [generation] software during the registration process.
Yeah, there are pros and cons, and both sides have their points. But, as an example, I've been using Key Maker (v2.0) for years. It generates complex passwords from common inputs - and regenerates, later, the same password from the same input.

Unlike most of the generators I've seen over the years, I can come back to a place I've not visited for a couple of years, enter the - [possibly] unique to my mind - text and get the same password. Didn't have to store it, didn't have to write it down, don't have to have it in the cloud, don't have to be on a particular machine (so long as I can download/install it - works under Wine in Linux distros). For my usage, it's near ideal. There are some insecure elements - for instance, you can set it to remember your creation phrase - but it satisfies most security requirements for a majority of users w/o them using Post-It notes (or software equivalents) or maintaining a clear text password file.

Given a properly phrased option to download it, along with your personal requirements (length, admissible characters, ...), that could well obviate most simple intrusions.

Of course, the subscriber would have to buy into the idea ... how good a salesman are you

?

mouser · « **Reply #8 on:** February 16, 2011, 01:15 AM »

It's interesting that everyone seems to have come to a different conclusion than the one I seem to have reached.

I guess in my mind i judge the real-world risk and inconvenience of having users create and remember custom passwords for a site seems to be significantly worse than the risks associated with just generating and emailing them a random one.

Another thing worth mentioning is that the worst case scenario when you mail them a random password is that someone will get access to their mail and get their login info for the site, and will be able to log into the site as them. The worst case scenario when letting users choose passwords is that they will have reused that password on other sites (bound to happen some of the time), and open themselves up to having someone be able to log in as them on lots of other sites if even one of their site credentials leaks out.

If users were perfectly behaved, then yes having them create their own strong unique passwords is a clear win. I'm just thinking in the real world it still seems to me that autogenerating a random password and emailing it is a win, for all but high security sites where the risk of email leakage is just too high to chance that.

Deozaan · « **Reply #9 on:** February 16, 2011, 01:24 AM »

It's not your job to make sure users are smart enough or care enough about their own security. Your job is just to make sure that you do what you can to ensure their data is safe on your end. If their account gets compromised due to their own stupidity or mistake (e.g. being duped by a phishing site/e-mail), well, that's their own fault.

I'm no security expert, but to me this means a few things, and probably a few more things to an expert:

1. Make sure you store their password using a known-safe encryption algorithm.
2. Don't transmit the password back and forth in plain-text (use https or a hash or token or something).
3. Allow secure passwords. You wouldn't believe (or maybe you would) how many sites limit the length of your password to only 8-12 characters, which can only be alphanumeric. Not that hard to brute-force...
4. Put measures in place to prevent brute-force, such as temporarily locking an account or requiring additional verification after x attempts in y minutes.

Once you've done all you can on your end to ensure that people can't get the password from you, then that's all you are required to do, as far as I am concerned. Although, I suppose at that point it would be safest to assign a password for the user but allow them to change it if they choose to do so.

Another, third option would be to e-mail them a temporary password and require them to change it or assign a different permanent one when they first login. That way even if the e-mail gets compromised, the password will definitely not be the same if the user has ever logged in.

I used to use the same password on just about every website, but then once Gawker had their data compromised due to a stupid security flaw on their end, many of my accounts became compromised.

That's bad on me because I used the same password on many sites, but terrible on their part because it was them that allowed my password to get leaked, not me. Nobody brute-forced it or guessed it or based on information that I made publicly available. It got into the wrong hands because Gawker didn't store it securely.

barney · « **Reply #10 on:** February 16, 2011, 01:28 AM »

mouser,

The first thing I do when I'm sent a site-generated password is change it, if at all possible. I don't trust the site(s) to be optimally secure. Yeah, I'm a paranoid old curmudgeon ... but my concern is whether I'm paranoid enough.

I tend to use unique email addresses for everything to which I subscribe ... you wouldn't believe how many of those addresses show up in my spam folder, usually hawking Viagra or Cialis or the like. The sites to which I subscribed didn't get hacked - those addresses were sniffed out of the ether - but it's pretty easy, if you know how, to park a sniffer on the route to a popular site - doesn't have to be every route, just one will give you significant results.

So, if I park a sniffer such that it checks all the DC outbound mail, how long would it be before I started harvesting passwords that you sent out?

Methinks the cons of that approach outweigh the pros.

barney · « **Reply #11 on:** February 16, 2011, 01:39 AM »

Quote from: Deozaan on February 16, 2011, 01:24 AM

It's not your job to make sure users are smart enough or care enough about their own security. Your job is just to make sure that you do what you can to ensure their data is safe on your end.

+1 to that. In order to protect us, you have to protect DC. Which means you also have to somehow protect DC when someone uses my password to get into an otherwise protected area. I don't have the knowledge for that, but I suspect it would involve preventing SQL-injection attacks, amongst other things. Oh, yeah, it also means alerting us that we can't talk anymore 'til we make abeyance to the rules, change password(s), and the like.

mouser · « **Reply #12 on:** February 16, 2011, 02:10 AM »

I wasn't talking about DC specifically, I was just talking about the general concept. It goes without saying that every website that has user accounts has a deep obligation to protect those accounts, protect the site against attackers, etc.

barney · « **Reply #13 on:** February 16, 2011, 02:29 AM »

Well,

Whether DC or not, the same principles apply. Assigned passwords, particularly if strong ones, provide a fallacious sense of security, and often encourage less-than-stringent security measures in other areas. If site security is good, weak user passwords don't really matter that much. If security relies upon users - you've been to some of 'em, the sites, I mean - it simply does not exist.

Security lies in the hands of the holder, not the beholder

.

40hz · « **Reply #14 on:** February 16, 2011, 02:34 AM »

In the end, I think most places that need high levels of security will opt for a combination of https and a two-step authentication mechanism.

Google already offers it as an option for GMail users. More info on Google's system here and here.

Paul Keith · « **Reply #15 on:** February 16, 2011, 06:29 AM »

Two steps don't really work.

Quoting a Hacker News comment on the link:

Quote

Devil's advocate here:

If I can trick a user into submitting their username and password on my site, I can send a request to Google using that username/password and trigger a message to the mobile application. The user continues with the flow, enters the code on my screen, and I now have access to their account, same as before.

Quote

I don't think 2-factor auth as proposed by Google is designed to prevent man-in-the-middle attacks: http://www.phonefactor.com/man-in-the-middle-attacks
In order to prevent MITM, Google would need to have out-of-band verification (not just two tokens processed on the same band).

The benefit of Google's method is that a password can't be cached for later use, which reduces the window in which an account can be compromised.

Quote

Seems to be the same thing with the BlizzAuthenticator. Good idea, but I wouldn't use it. You gotta consider what happens if you loose your phone. You can't do any emergency calls and don't even have access to your saved phone numbers anymore. You're also locked out of your Gmail Account for god knows how long. I like my phone, but a little bit decentralizing can never be wrong

Personally I'm still waiting for a three-step system using image (not text) captcha to profiles to password + interval self-made sets of security questions for certain behaviours. (like there's a secret question if you go and access a certain site or delete/view/revisit a certain amount of e-mails)

The fallback system being that if a user has lost anything or been exposed to any middle of the man attack - they can shut down the attack using their uploaded .jpg/.png image as a key to the nuke and reset button.

Gothi[c] · « **Reply #16 on:** February 17, 2011, 08:28 PM »

This one is easy:

It's just a matter of risk assessment, like anything in real-world security.

A generated password is better.

The chance is FAR greater that a person will chose a weak or reused password than that their email will be sniffed.

In a perfect world, it would be even better if the password is shown to them after signup over https and not emailed.

JavaJones · « **Reply #17 on:** February 17, 2011, 08:35 PM »

What is better in a perfect world and the real world are different.

What happens when the user forgets their password?

- Oshyan

Ath · « **Reply #18 on:** February 17, 2011, 08:38 PM »

Quote from: JavaJones on February 17, 2011, 08:35 PM

What happens when the user forgets their password?

They get slapped on the cheek, and sent to the KeePass website

timns · « **Reply #19 on:** February 17, 2011, 08:39 PM »

Quote from: Ath on February 17, 2011, 08:38 PM

Quote from: JavaJones on February 17, 2011, 08:35 PM
What happens when the user forgets their password?

They get slapped on the cheek, and sent to the KeePass website

Or slapped on the ass and sent to the KeepCheek site

JavaJones · « **Reply #20 on:** February 17, 2011, 09:05 PM »

Statistic pulled out of my ass: 90% of people don't use a password manager and never will. If someone wants to go find a real statistic please do, but I'd be surprised if it was any better than that.

- Oshyan

Paul Keith · « **Reply #21 on:** February 18, 2011, 09:55 AM »

Yep, precisely. It's not so much risk assessment as education assessment as well as victim assessment maybe. Like how knowing a virus wiped your HD makes you keep an Antivirus no matter how careful you are.

That's why a generated one click login like Facebook is better. Not to diss on Twitter and OpenID but if people think their private info is at risk, they tend to go the extra line of defending themselves in protecting that account. This doesn't mean they won't have bad security or bad decisions (hell I still don't know how my ATM money was stolen in the past) but anything with private info is much better at social engineering the casual person to have a great master password.

Note that I'm speaking purely from the model of Facebook Connect importing datas into other services and not specifically Facebook Connect which I hate since I mostly don't use Facebook. (I also ignored Google here since no one really wants to use a Doc Manager to be their credit card also. That's like using your Hard Disk as your coupon card. I use it from time to time but if I have anything important on that e-mail account, hell no.)