Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Browsing through Coding Horror, I saw this article on removing the user field from a login dialog.
It's an interesting concept albeit an old one from 2005. Nevertheless, I started thinking about it and wondered:
How would you be able to do this in a secure fashion?
If you identify the user by their password that means all passwords must be unique - yes?
If all passwords must be unique, what do you do when someone enters a password that's already in use?
You can't tell them it's already in use because that would give away someone else's login.
I can't think of a way one could implement this in a secure fashion...any ideas?
You do not identify users by password, you identify them by user name. You authenticate users by password. Just think a bit what does it mean to identify by password. I join the system, he asks me to enter my new password. I say 'foo', he says 'foo is already in use'. I say 'tyvm'', and open the login window. When prompted I simply enter 'foo' and he says 'Welcome Mr. President'...
No, there absolutely cannot be a requirement to have passwords unique, that would be a huge security hole in any system because it relies on information disclosure to function: by reveling a duplicate you disclose somebody's password. Even with name/password combinations, once you disclosed that 'password is in use' all I have to do is iterate through the list of accounts trying the password you just revealed to me, and one combination will succeed.
My first thought, which is also alluded to in the article, is to increase the password complexity requirements to avoid collisions.
16-byte GUIDs avoid collisions (every star can have 6.8×1015 GUIDs) well enough, so it shouldn't be too difficult. Obviously human-generated input isn't quite as random, but if you add in enough requirements like lowercase/uppercase/numbers/symbols/length, it might work well enough.
Well, I suppose you could look for some other piece of "uniquify-ing" data, to use in combination with the password. For a web app, this could be a hash inserted in a cookie, from a previous visit. It'd be hard to guarantee uniqueness (multiple users from a single profile on a single computer, for instance).
My bank takes essentially this approach, with my public IP address. It's a little annoying, actually. Every time my DHCP lease expires, my bank's website "un-recognizes" me, and asks one of several security questions, before I get the standard username/password screen.
Multiple-factor security uses something like this (a hardware key or hardware-provided identifier, in combination with a password).
This approach strikes me as overly clever, and clever's rarely the right way to approach security systems.
I believe you cant.
By entering your username you are providing your identity, by entering your password you are providing a means for the server to verify this identity.
Both are inherently required unless you have some other means of determining identity (IP, keycard, etc.)
Basically you cant expect anyone to believe you are who you say you are, when you don't say who you are!
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I just want to know if having 2FA on your login can actually mean that you don't need to worry about it if someone steals your username and password?
I know there is a problem if someone steals your phone, and can access an authentication app like Google Authenticator or Microsoft Authenticator and just enter the app and read the generated codes. But what are the odds of anyone actually being able to get access to your phone and accessing that such an app?
I am using 2FA in most of the services I am using because I feel much safer that way. But is it worth implementing it in your own services if your encryption system is not so good? Will it be critical if someone manages to break into my service and read everyone's usernames and passwords in the hypothetical situation where everyone is using 2FA and unique passwords anyway?
A few thoughts:
Security tends to be better when there are more "layers" of it. A combination of username and password is one such layer. 2FA is another. Adding 2FA will no doubt improve your security, but you should still strive to keep your username and passwords secret. Consider what happens if someone steals your phone, but is unable to get hold of your password. Use both.
Related: Logging into a system is not the only threat; information about an account is too: What if a user does not wish it to be known that he has an account in your system? If someone can access your database of usernames and passwords and the data is published, the whole world will know who your users are; perhaps this is not critical in your case, but it can be in certain other cases, and it`s a good principle to adhere to in any case. So strive to keep both usernames and passwords secret, if possible.
I realize you already know this, but your hypothetical situation is just that - hypothetical. You should never assume that all your user's passwords will be unique to your service. Some users will do stupid things. That may not be your fault, nor your responsibility, but it is still considered good practice to do what you can to help them stay safe.
If you are aware that your encryption system is "not so good", then you should obviously try to improve it.
2FA may not always work, or may not be an option for everyone in all cases. If it is not critical to your service, you might consider making it possible to opt out of. For some customers, choosing to accept a little more risk may be worth it for a slight reduction in "hassle" when logging in. For others, this minor "hassle" may be an insignificant price for better security. In any case, you should offer 2FA as a possible improvement in security, and not as an excuse for lax security in other areas.
I've done some work at a few places now where passwords are salted and hashed in the database, but the answers to the security questions are stored in plain text. Just now, I signed up for the online portal for my hydro company, and in the account management section, the security question and answer are displayed to me.
Given that security questions and answers often allow a user access to an account in a workaround way, without requiring the password, why are they allowed to be stored in plain text? Especially since people often have a limited pool of security questions to choose from, so they likely use the same answers across many sites.
The problem with security questions is that they are by design completely insecure. The reason that they are stored in plain text is that they occasionally need to be looked at by humans and used by humans to verify that an answer is correct. If a user’s answer to their favorite food is “popped corn”, and they answer “popcorn”, that’s a valid answer.
Hashing the answers to security questions would require that the user know their previous answer exactly, just as if it were a password, and we already know that the user forgets their password (in those cases where the user is the one trying to access the account). The point of security questions is that they are real things that can be remembered and don’t have to be treated by the user as passwords.
Similarly, because these are not arbitrary answers in the way that passwords are, they are sometimes, as you noticed, displayed back to the user. This is so that they can change the answer when it is no longer correct. A password is an arbitrary response, but security question answers are not arbitrary. People’s favorites and even what or who they think inspired them can change over time. A user who is asked their favorite movie might choose the one they saw last night, and completely forget a year later that they ever rated it so highly.
For that matter, hashing the answers to security questions is of limited utility (mainly to security geeks who know to answer them randomly). Their very nature is that they are public. Hashing the model of the user’s latest car doesn’t keep the hacker from just reading their Facebook feed.
The secure answer to security questions is not to use them. Technically, they should be treated exactly like passwords, because for all practical purposes they are passwords. But if we hashed the answers to security questions, required users to choose strong answers, and didn’t allow them to use easily-guessable answers, then there would be no point to them.
Remember, the purpose of security questions and answers is to bypass not knowing the password. The more they’re treated like passwords, the more useless they become for that purpose.
There's no answer to "Why don't the answers need to be stored securely?", because they should.
A password is actually an answer to a security question too ("What is your password?"), so you should always hash answers to security questions too as it's a way to authorize a user.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
An application I maintain offers a standard password reset script. My employer wants to add a tool for our support reps to set the password manually to something they pick themselves, and give the password to the customer over the phone.
Security in my application is expected to be top notch, so this sets all sorts of warning bells in my head.
Aside from the obvious no-no of allowing support staff to know customer passwords, What other security implications should I be aware of in this scenario? In the case of fraud, would this increase our legal liability?
My take on this is that you have to offer customers the ability to reset their password. Customers will forget their passwords and need them reset. Meeting the customer in person and confirming their identity is presumed to be out of the question, so it might as well be done over the phone after a human has verified the customer's identity (in some way that's deemed sufficient). Any written form of communication such as email is almost guaranteed to be archived somewhere, so having the password in that form is a bad idea. A phone conversation might be recorded too, but at least it's not searchable. YMMV.
That being said, the thing that you give out over the phone should most certainly be a temporary password that needs to be changed the first time the customer logs in with it (and preferably is only good for a short amount of time). Otherwise your staff will know the customer's password!
I can't speak to legal liability.
Since transmitting a strong random password through phone without errors is hard, support staff might gravitate towards choosing weak passwords (such as a dictionary word plus some letters) if they get the chance to do so. Also, they might write passwords down in case the customer misheard and calls back, which might result in even more people knowing the password.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm a full time software developer, but on the side I'm teaching a university course on web services. I'm going over security right now and was wondering if any of you all have had any security breaches that you could tell about (details obscured as needed) that I could share with my students. Real life stories are a lot more meaningful than made up scenarios...
Here is a story from me:
I once was customer of an online audiobook store. Beside authenticating myself with username and password, I also needed my browser to accept cookies. This wasn’t unusual. The cookie is probably needed for storing the session ID.
But I got confused since the session ID was also transmitted in the URL and I didn’t saw a reason for why there was a need for cookies. So I took a look into my cookie jar to see what oh so important information have to be stored in cookies.
Beside a cookie for the session ID there was another cookie named customer_id that obviously was designated to identify me by my customer number. I thought: “Come on, no one can be this stupid!” I altered the value for fun by changing one digit of the number (e.g. from 12345 to 12346) to see what happens.
Now guess what: I now was logged in as a different user without any further request for authentication just by changing the cookie! The customer_id cookie value was abviously not just for identification (Who am I?) but also for authentication (Am I really the one who I pretend to be?)!
The moral of this story: Always separate identification from authentication.
This may not be what you had in mind, as there was no information compromised, but it still very much a web security issue.
http://www.crime-research.org/library/grcdos.pdf
That is the classic story of how internet security guru, Steve Gibson's, site was attacked by a botnet. It is a very interesting story and would certainly keep the class engaged. I know this story got me more interested in web security.
I could not find the original post of that pdf on Steve Gibson's site (grc.com), but I had a copy on my computer and was able to search for it and found it at the given location.
I also recommend going to grc.com and listening to the "Security Now!" podcasts:
http://www.grc.com/securitynow.htm
You will almost surely hear some stories in some of those podcasts.
Hope this helps!
The European Identity Conference (EIC 2009) in Munich will be featuring a case study on SOA security that will have the information you seek.
I'm working on a web applications where - believe it or not- the users aren't required to provide their email address to sign up. These requirements can not change. The users will login to the system with an id and password just like any standard web site. The problem I'm facing has to do with user's that have forgotten their password. When they want to generate a new one, how do I verify their identity?
Initially, I was going to make the users choose a security question (from a list of 5) and provide an answer. If they ever entered the Forgot Password page, they would then have to enter their login id, as well as the answer to their security question. This seems slightly insecure, as the answer to these types of questions (mother's maiden name, birth town, etc.) are generally not that hard to acquire.
So here are some of my questions:
Are security questions the best approach to this problem?
If so, what are the best questions?
How many questions should a user be required to enter the answers for?
Is it necessary to put a CAPTCHA on the Forgot Password page?
Is it better for users to generate their own questions?
Any help/comments/literature on this matter would be greatly appreciated.
I can't recall the location, but if you do a google search on knowledge based authentication, you'll ifnd that Q&A authentication is very weak. One significant problem is entropy (possible randomness) of potential answers and of actual answers. If you ask for a favorite color, there's really only a very small list of colors that most users will select. This might be worth 1 bit of entropy. Then, if you asked a second question, such as the city where you grew up, this might get you another bit or two of entropy (in Mexico, there's something like a 30% chance for each of 3 cities for this answer).
One estimate that I saw was that, to get equal strength to an 8 character password, you'd need about 26 questions.
That said, you might be able to do other things to contact the user. You could try sending a text message to the user, instead of an email - does the user register a phone number? You might have the user store a certificate on their computer, which they can upload along with the password reset request (you'd have to make effort to ensure this cert was tied to the computer). You might do a post-signup thing, where the user could submit an email address.
Good luck!
Are security questions the best approach to this problem?
Since you cannot use any other means of authentication (such as email address, OpenID, etc.) this is the best you can do really. However, you could always add a "password hint" to the signup process.
If so, what are the best questions?
Is it better for users to generate their own questions?
It's much easier if you let the user write his/her own question as opposed to the stock "first car" or "first pet". This is a good failsafe as it (usually) provides a very difficult question/answer combo to randomly guess and is likely as secret as a password.
How many questions should a user be required to enter the answers for?
Allow for one question/answer combo.
Is it necessary to put a CAPTCHA on the Forgot Password page?
Well, there has to be some attempt to guard against brute-force attacks, especially from bots. I would use the same technology that SO uses: reCAPTCHA
Are security questions the best approach to this problem?
Absolutely not.
Password recovery needs to work for legitimate users and to fail for the bad guys. Secret questions do the opposite: hackers are really good at guessing them, yet legitimate users cannot remember their own answers. Research has proven this. And this is exactly why NIST is saying do not use secret questions -- i.e. knowledge based authentication.
You are trying to make it easier for the user in the event that he forgets his password, but unfortunately secret questions do the opposite. Users hate them, and they forget their answers, which only frustrates the user more.
By design, you do not have a way to recover the account when the user forgets his password. Don't make it worse by using secret questions. If you really want to make password recovery possible, then why not instead of forcing the user to choose and answer secret questions, instead require them to provide an email address or phone number and do password reset the exact same way that all the good websites do it?