We seem to have a lot of clients asking us to change the login screen in this manner:
Display a list of all available users (thumbnail picture + name)
User selects a username from the list
A password prompt appears near the username
User enters password then presses enter
This sounds remarcably similar to the Windows XP login, which is probably where they got the ideea in the first place. There are only about 4 - 5 different users that can login at any given station, so implementing that list on one screen is feasable.
So I was wondering if there are any usability experts with some word on this method of login. As far as I can tell, MS droped this behaviour in Vista/Win7, didn't they?
Providing user names should not be a security issue, think of all the email sites (hotmail, gmail, yahoo) where the email address is the username.
As for usability this is far better then expecting a user to remember their login name especially for user who are infrequent or have a lot of different user accounts.
Please remember to advise users on how to pick a secure password, the weak/moderate/strong as you type color indication while setting the password is a great device for reminding users of the strength of their password.
Windows 7, while not part of a domain, still uses this approach.
While there are few enough users that they can all fit on a screen or a scrollable list this seems like a good idea. As you get more users you may want the option of select from the list or type user name here, style login.
The downside of this approach is that it exposes the list of valid usernames to anyone who can access the login page. And also, as you've hinted at, it isn't very scalable to a large number of users. However if you've got an internal application with only a small number of users then it probably is a usability improvement. Alternatively, you could just implement a "remember me" feature so that a user's name was remembered and they just need to enter a password when they return to the application.
From a security perspective, this sounds like a bad idea. Your username is one of the unique pieces of information that identify you. Granted, with such a small group, most people already know each other's username, but still, I would think at least 2 pieces of personal info (username, password) should be required to login.
Related
Imagine you have a site that uses some oauth solution. In this case, you might have urls like signin.mycompany.com for login, then usecase1.mycompany.com for one use case, and so on... When you save your pwd, password managers (like the built-in solutions from Safari/Chrome/Firefox) will usually save the password under the name signin.mycompany.com ([email]) -or something similar.
If the user forgets the password or changes it, the chance that the form for the pwd change / reset are on different subdomains is relatively big. Is there any way to set the name the pwd is saved under to "mycompany.com ([email]), so that all subdomains will use and save the same entry? Or at least find some solution that will behave properly?
I know this might sound like a security vulnerability, but in such cases often sites have specific CORS policies to allow subdomains to access resources, so generalizing password manager (as long as it is controlled from serverside) should not be a big deal...
I recently logged into a website (student run club website which stores event and participant information).
After successfully logging in the following message appears and follows me around for the rest of my time on the site:
You are using an insecure password. The password that you entered has
been exposed in at least one data breach.
How do you know my password is insecure? This password appears in a
database of known passwords. Hackers may use this password to try to
break into your accounts.
While I appreciate the notification that my password was compromised (and should know better and will change and stop reusing passwords etc etc) I now worry about the overall security of this site.
I don't know a terrible lot about web dev but my naive assumption, given this message and the fact that it appears after log in, is that my password must have been stored in plain text for them to be able to check it against a database. Is this correct? Or is there some clever secure way this could be done?
Just because you are receiving a notification from the site doesn't mean that your passwords are being stored in plaintext. Whatever website you are using can use your password in the "Have I Been Pwned" API before encrypting them. This of course doesn't necessarily mean that they are encrypting them as there isn't really a surefire way to know how they are storing your passwords without possibly contacting the owner or if you were to receive an email at a later date with your password in it.
You can read up on the API for password checking here haveibeenpwned.com/API or you can check for the website you are using in this list here haveibeenpwned.com/API/Consumers.
I am developing the application in which i have a super user concept. Super user is the user who has all the access for the application. So what my initial thinking is in user table the user with id 1 will be my super user. but how safe is this in terms of security concern ? is there any other logic which i can use to define super user ?
I have done more emphasis in coding side. I also implemented the roles and other access permissions, But what i need to to do is something like ghost user. Whenever he logged in he could be able to access everything like he is a father of application. for his access i shouldn't need to check any role conditions or access condition. is it possible ?
Thanks.
Why not work with roles? Make a column in your user table where you have 'SuperUser', 'Admin', 'ReadOnly',... Or perhaps just 0, 1, 2... and match it with a constant/enumerable in your code. Now you can easily change your super user, make multiple super users, give someone temporary super user rights, define other roles...
From the database point of view it is valid to define two or more users and grant more or less permissions to them, work with roles etc.. But as you said - it's about the application. So in parallel to the database security you need to consider application security in terms of:
which user may get which functions, menu items, web pages etc.
how can this be configured and parameterized, etc.
I personally put a bit more emphasis on the application side and less on the DB side. So thinking of e.g. PHP + MySQL, I have 2 DB users (operator, admin), but a database table within my application for each (application) user, assigning to them the operator or admin login for the DB and defining which parts of the application they get.
As a complement to the other answers:
Don't forget you could create users and grant/revoke permissions at DB level. I would not push for a 1-1 mapping between your application users and the DB users, but you could use that to implement "roles" and enforce permissions at DB level as an extra level of protection. This might be especially interesting if you have some users with "read-only" and/or "anonymous" access. This would prevent "escalation of privilege" due to a bug in you application code.
Super user is the user who has all the access for the application. So
what my initial thinking is in user table the user with id 1 will be
my super user.
In the Unix tradition, super-user is generally ID 0. This might improve code (maybe) and more important make it more understandable by programmers familiar with kernel/security coding.
But what i need to to do is something like ghost user [...] for his
access i shouldn't need to check any role conditions or access
condition. is it possible ?
I don't think this is a good idea to somehow "deactivate" all your security checks for one particular user. In order to improve maintainability and not clutter the code with permission-checking, as of myself, I would encapsulate all the code that need to check permissions in wrapper functions or objects, then I would use that wrapper in the rest of the application. Based on that, and if you implement "roles" at application level as someone else suggested, handling the "ghost user" shouldn't be too much of an issue.
I'm developing a site that has to store a user's contact list. So it will contain people's phone numbers, addresses and also messages sent to this contact. I obviously want to keep this information secure but it seems quite easy an efficient just giving each user a json file with an array of details.
I'm not too sure if this is a horrendously dangerous and insecure idea and if I should be using a table in a database, or something else. Using a table to store messages sent between users doesn't seem too intuitive though. So I was just wanted to know what the most sensible way I would store
i) User specific contact lists with sensitive information
ii) Messages sent between two contacts
I'm sorry if this is a widely known and not even talked about topic. I just couldn't really find a clear answer anywhere.
You should definitely use a database for this. If you store these values on files, then you will have to load all of the information per user every single time you need to access something as small as a single phone number.
If I were to run a service that allowed users to authenticate via "local" username/password combinations and ALSO any number of OAuth services - what might that user data model look like?
Usually, if I were handling all logins myself, in the "user" database (assuming MySQL), the username and password fields would be required as non-null. But, if my users just wanted to log in with Facebook, I'd just store the Facebook auto token, and not have any username/password locally.
Further, what if they want to log in with Twitter creds, and then tumblr, and then whatever service-of-the-day? I could keep a field for each type, but that might get a little unwieldy. Would I be better off keeping another table of "authentication methods" for lack of a better term, so I could have a one-to-many relationship between users and how authenticate them?
Basically, I'm asking if anyone knows of an industry standard best practice for this scenario, or can point me in the right direction (or if someone has implemented something like this that works well for them). One user, multiple methods of authenticating - what's the best way to hold that info?
If any of the assumptions I've made are invalid, I apologize, please correct me.
I have no idea if my solution comes close to any sort of industry standard but I've done this in several apps before.
Identity within your application should be abstract from the authentication source.
What I ended up setting up is something like this:
User table:
id int
username varchar
email varchar
password varchar
Authentication profile table:
user_id int
service enum('website','google','facebook')
token varchar
[ For further normalization, make service its own table with service meta fields. ]
Then your auth script does something like this:
Look for username / email
Identify known authentication profiles
See if the input validates for any known authentication profiles and auth, or return invalid credentials
In cases of some services, you will either need to autogenerate some of the user field values, or prompt the user to enter during the first authentication, depending on what sort of data is available to you from the service.
I think what you want is a local authentication system (possibly for legacy reasons?) as well as support for users logging in using delegated authentication. The standard for delegated auth is OpenID. You might want to look at OpenID consumer libraries and samples, which should give you an idea of storing OpenID credentials. Unfortunately Facebook and Twitter do not support OpenID, but the flow is pretty much same, i.e. your data model will not change. We have implemented an OpenID consumer to support OpenID based login and registration. In order to support the local authentication, we have used an OpenID provider. In other words, we are both a consumer and a provider. That way, even the local auth system is standards based. Now to answer your question about schema - We have the source (local, twitter, facebook, google, yahoo, AOL) and the email as a composite key, along with the token and/or password in the authentication table. We let users change their display names, and have a unique vanity URL which is also a part of this schema. Users have an option to set up a password when coming in through OpenID, as for Mobile they'd need a password (not a whole lot of OpenID support on mobile). OAuth solves a little different use case where you're dealing with authorization more than authentication. Does this help? If you have any questions feel free to comment and I'd be glad to provide more details - I just do not want to confuse you with too much information at this point.