For context, I am currently developing a bit of software for a machine, when this machine is left by the operator (i.e. running without supervision), its door must be locked. This is all fine.
When the operator gets back and wants to unlock the software again, they must enter a simple 4-digit passcode. Then the door unlocks again.
Additionally, a supervisor or manager (or operator with the code I suppose) can enter another 4-digit passcode to enter a settings page. They could also change the operator passcode, etc.
Lastly, there's an Admin level. They can change actual parameters that shouldn't be touched by any other than the owner of the machine/someone with thorough knowledge of the system (like a service-person). This admin level can also be entered with a(nother) 4-digit code.
Problem: The problem arises when a supervisor changes passcodes. If they enter a password that happens to be identical to that of the admin, the software throws an exception.
How do I actually handle this exception?
I obviously cannot say "password in use, please use a different one"... That would give the admin password away. Should I let them choose their new passcode, and change the admin passcode one value higher? Admins would know of this behaviour, so if the default admin passcode doesn't work, they simply try passcode++.
Any suggestions would be greatly appreciated.
I'd prefer to handle the exception properly, not change the way the login works. As this has already been deployed. (though I can see whether I could do so in future versions)
Related
We're dealing with an unusual situation involving dovecot that perhaps requires an unusual solution.
We recently required all of our POP/IMAP users to change their passwords, and in almost all cases, they dutifully did so. However, one user has several devices and machines which are repeatedly querying for email, and due to circumstances beyond anyone's control, one of his computers cannot be accessed for at least another few weeks, and therefore, the dovecot password for that user's email access cannot not be changed until that time passes.
Therefore, that computer keeps querying dovecot for email for that user with the old, now invalid password, and those queries fail.
Furthermore, due to various circumstances which are also beyond our control for the time being, we can't have that one user change his password back to the old value on the other machines and devices that he uses.
What we're wondering is whether there is some way that dovecot could be set up to recognize and accept both passwords for this one, specific user. In other words, can we somehow set up a secondary password for this email address so that both the old and the new password will allow this user to access his email?
We are using auth sql by including auth-sql.conf.ext in 10-auth.conf. Perhaps the solution to this problem would to restructure the database we are using for SQL authentication and add one or more columns, and then somehow change the SELECT statement that is used in auth-sql.conf.ext to choose between one of two passwords.
We are willing to attempt this procedure if it's the only option available, but we aren't even sure how it can be done. And in any case, we're hoping that there might be some feature of dovecot that we are unfamilar with which would allow us to set up this one user's dovecot email account to allow two different passwords for authentication without any database changes.
Is there any chance that we could do this?
Thank you in advance.
The link supplied by Allan Wind helped me (thank you!), as well as a couple other things I saw in those dovecot docs which I had overlooked in the past.
It turns out that I can supply a second userdb and passdb block in auth-sql.conf.ext, and they serve as secondary fallbacks if the primary SQL query doesn't return a match. I set up a passwd-file that is usable by both of these which contains the hash of the user's old password, and now, both passwords are working.
For example, the secondary userdb block (which should appear right below the original sql-based userdb block) looks like this:
# Fallback ...
userdb {
driver = passwd-file
args = scheme=md5-crypt username_format=%u /etc/dovecot/extra.userdb
}
The secondary passdb block is identical, except for it being named passdb instead of userdb. It must appear right after the original passdb statement in that same file.
So, all's well that ends well.
Onward!
I have designed a standard login screen in ASP.NET like below:
As usual when operator selects “Remember me”, we expect system to not ask operator for credentials anymore and go directly to default (home) page.
My business team saw something on internet and they believe that when “Remember me” has been selected we need to pre populate the username and password and wait for customer to press “LOG IN” button:
I haven’t seen this practice so often and I am not very comfortable to do it. Although, I don’t have a good technical argument to explain and change their mind.
I am basically looking for good argument to explain cons and pros of above scenario.
Never ever should you pre-populate a passwords edit field. If you do so, everybody is able to read the plain-text password, if he can open the login form on this computer. A few minutes on an unlocked office computer would be enough to check the browser history, afterwards the attacker can login whenever and whereever he wants.
If you have a remember me function, and the user has logged in using this function, then there is no need to display the login form at all. You can just display the content. In this case, an attacker can do things with the account, but he cannot login unnoticed later from somwhere else.
I think (hope) you saw the pre-populated password field, because the browser filled in the content, and not the website did it. Maybe there is a password manager installed.
I have an corporate intranet project that needs logins, but doesn't need high security. Impersonating a different user is not useful or very desirable. In similar intranet systems, everyone has the same password as setup by the admin.
I'm hoping to get some suggestions on what password alternatives I could consider. My first thought is to show each user 8 images and have them click on one to be their password. Would this be too annoying or problematic in someway? What other ideas would you suggest?
Why not just use a text based password? It sounds like you are over-complicating things by including images, especially if, as you stated, don't need "high security". I wouldn't consider a text based password "high security" but it does meet your requirements of a login on the intranet. A lot of products have built in functions for passwords so it would be dead simple to implement into your project if you have this available. I'm suggesting you keep it simple and don't assume that impersonating a user isn't something that won't happen without at least a password. You'd want to know who made changes or have some logs that identified who was the user at the time of a certain event.
Remember, security should be baked in, not sprayed on!
I know the title is a little off, but it's hard to explain the problem in a short sentence.
I am the administrator of a legacy webapp that lets users create surveys and distribute them to a group of people. We have two kinds of "users".
Authorized licenseholders which does all setup themselves.
Clients who just want to have a survey run, but still need a user (because the webapp has "User" as the top entity in a surveyenvironment.)
Sometimes users in #1 want us to do the setup for them (which we offer to do). This means that we have to login as them.
This is also how we do support: we login as them and then follow them along, guiding them.
Which brings me to my dilemma. Currently our security is below par. But this makes it simple for us to do support. We do want to increase our security, and one thing I have been considering is just doing the normal hashing to DB, however, we need to be able to login as a customer, and if they change their password without telling us, and the password is hashed in the db, we have no way of knowing it.
So I was thinking of some kind of twoway encryption for the passwords. Either that or some kind of master password.
Any suggestions?
(The platform is classic ASP... I said it was legacy...)
Both options you present sound unattractive to me.
A master password is probably even more dangerous than what you are doing right now
Encrypting (instead of hashing) passwords in the database is not good enough either IMO, as it takes only a break-in on your end to get hold of all passwords. They really should be hashed.
I assume the product, being an old legacy app, is impossible (or not economically feasible) to change in a way that administrator accounts can impersonate user accounts, which in my opinion is still the best approach to this in a real-world scenario (not everyone shares that opinion, discussion on the issue here).
How about introducing a second password column (password2) containing a hashed password that you enter? The login process of the app may be easy to tweak into looking in a second column as well. It might be easy to implement, and I can not see any additional security problems coming from it (correct me if I'm wrong of course.)
What I would do is to let the support staff login with their username/password but to chose a user to "impersonate". So in your session you will have:
logged_user - the actual user who typed in his/her username and password
impersonated user - the user (1) is acting on behalf of
Everything you do is done with the impersonated_user's permissions and preferences.
If you are not impersonating anyone impersonated_user=logged_user.
This way you have to always log any operation with both "actual" username and "impersonated" username; for example:
2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie'
sounds like you want to decouple your authentication from your identity a bit. Maybe something like an administrator override page, so that after you log in as the administrator, you have a choice of which user identity you wish to assume. After selecting an identity, you continue to use the app without further authentication.
I like the solution offered by Manrico Corazzi. It reminded me that when you need support from Microsoft, there is way to hand over the control of your machine to a technician. That could be another way to achieve the impersonating mechanism. In order for an administrator account to log in, an authorized license-holders would have to explicitly allow him to join his session and act with all his privileges.
I've been thinking about this quite a bit lately, and I would like some feedback from this wonderful community. Is it safe to assume that a user wants to be remembered when they login? And if they are using a public computer, is it safe to assume that they are smart enough to logout before leaving?
I don't really think it's safe to assume anything about the end-user.
Plus, it's easier for a user to just close the browser rather than to log out of every website, so providing a remember me checkbox defaulted to false is user friendly and less hassle for them over-all.
No. In this age of too-little privacy, any potential hole for a breach should be closed. Sites should be getting more secure, not less.
No, it is best to assume nothing, especially something like remembering the user.
What if they are at a friend's house or on a public computer and forget to log out?
No. Never assume that your users will do things that you want them to do if you don't explicitly tell them (i.e. force them) to do so.
The "Remember me" checkbox is an excellent example of how ignorant users can be - even when the checkbox is there, the fact that users are kept logged on on public computers is a problem. It won't help if you start assuming...
Now that most browsers can remember passwords anyway, there's little point in setting a remember-me cookie as well, so you can get rid of that option. Then users can no longer complain if they clear their cookies and then wonder why your site doesn't know them from Adam...
However, do not assume the user will log out. They don't, and with tabbed browsing, your session cookie could stick around for a very long time - maybe several days if they keep using hibernate/sleep mode and only restart their browser when it crashes. Therefore you need to set a reasonable inactivity timeout and require them to log back in once it expires.
No. Don't forget the old phrase:
When you make an assumption, you make
an "ass" out of "u" and "mption".
Thought I would update this discussion for anyone who finds this from Europe, where the EU Cookie Law will come into effect May 25th 2012. The law will require all European websites to obtain informed consent from visitors before they can store or retrieve any information on a computer or any other web connected device.
As the "Remember Me" almost certainly necessitates using a cookie, you absolutely CAN NOT assume that users will want to be remembered, and in fact doing this will become illegal from May 25th unless you somehow otherwise gain consent for cookie use from your users.
There are various strategies for how sites will comply with the new law, a popular choice currently is to have a site wide cookie Opt-In prominently displayed on your site, which disables all cookie operations until the user activates them. That's a discussion for another thread though, the message here is that you can't assume if you your web site operates out of Europe.
If your website is not security-relevant (that is: You're not a bank, medical or insurance company), then I would reverse the checkbox. Make "Remember me" the default and have a checkbox "This us a public computer, do not store my password". That would be my wish as a user, as I hate "Remember me" checkboxes, also because they don't work most of the time.
Is it safe to assume that a user wants
to be remembered when they login?
I would say that yes, in 80% of the cases (total guess on my part), the person connecting to your website is not through a public computer, and they would rather not have to retype their information every
time they come to the website.
And if they are using a public
computer, is it safe to assume that
they are smart enough to logout before
leaving?
No, that's not safe to assume. And smartness isn't even the proper term - it's more a question of remembering or even being aware I would say.
So I say go the safe route. Provide a "Remember me" checkbox, and leave it unchecked by default. People are used to this scenario. It's not that big a deal and it's much less likely to cause you trouble than checking it by default, or even worse not providing it and doing it silently.
I think it should be there on non-vital sites, but never checked by default and never automatically assumed to be wanted. If people don't want to remember their logins or retype them, let the browser's password manager or whatever deal with it, not the site. Users generally don't logout - to many, just closing the browser counts.