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.
Related
I wonder if I might ask for opinions on a simple authentication system I'm thinking about for a pet web site project where the overriding requirement is that the system should have no way to tell who the user is, i.e. have no way of identifying or contacting them.
The system does need to distinguish between these anonymous users of course, and prevent users pretending to be other users.
Perhaps in a strict sense it's not an authentication system at all, more like a distinguishing system.
A simple solution would be to assign a Guid to new users, which gets stored in a cookie/local storage/whatever and used to distinguish them.
Then give the user the facility to copy the Guid, and/or generate a URL that they can bookmark or otherwise store locally, which re-supplies the Guid to the site and stores it as a cookie again - to be used if the cookie is deleted or they want to authenticate from another machine - by using the generated URL or pasting the copied Guid into a 'login' page on the site.
This means there can be no 'I forgot my password' facility; if the user loses their credentials, they are forever lost, that's accepted.
Additionally, if the credentials are stolen, or the user's cookies are compromised, then the credential is stolen forever, there is no way for the real user to lock out the thief, that's also accepted.
Clearly the user would need to make damn sure they store this URL/Guid somewhere safe, that's accepted.
As an aside, there could be a feature that allows the user to regenerate the Guid, which might be used if they accidentally broadcast their Guid somehow, but that also means if somebody steals their Guid and uses the regenerate feature before the 'real' user realises, the real user will be locked out forever - maybe best it's unchangeable so at least if the Guid is compromised, the thief cannot lock out the real user - but this is an aside.
Given the requirement for complete anonymity / non-contactability, and accepting that losing the Guid is like losing a dollar bill, you lose it forever, it seems a reasonable and pleasantly simple solution.
This is essentially the same as having a user/password combination with no email address or other contact details, but more secure than user: sally123, password: mydogsname1968 or whatever just by virtue of it being a Guid, not something the user can remember or easily scribble on a post-it note and stick to a monitor.
It also has the advantage that a user who uses the same machine all the time (and doesn't delete cookies) never has to login or think about credentials at all.
The Guid could actually be two Guids stuck together or three of them interleaved byte by byte, whatever - a unique auto-generated chunk of data that reflects how unnecessarily paranoid the developer is feeling.
Can anyone tell me why this wouldn't be a good solution, given the anonymity/non-contactability requirements and the drawbacks accepted above, or perhaps suggest a better solution.
If it makes any difference to anything, it'll be a Net Core 5 / Blazor Web Assembly / MongoDb application, it's a pet project so doesn't have to pass muster with any client requirements or existing systems etc.
Thanks for any advice/help.
Is it because of portability? I think that it'd be better if they did, permission and group management would be safer in my opinion.
What I generally saw and did was to create a user account in the DBMS for the system, store that user name and password in a configuration file and accessed the database through it. The authentication module/plugin [always!] works independently the DBMS's user table.
Is there a reason for it?
Am I doing it wrong? :/
If I understand your question correctly, the reason is that if the plugin did that, then the user would be able to get access to your table using the user credentials, which is gigantic potential security hole. You want to give the user access to your app, not to the system running the app.
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 have an Android app that I allow users to have a password in and "lock" the app so their friends can't look inside without their password. It doesn't use a web service or anything, and the password is stored in a private file within the app. Problem is, the users like to forget their password, then email me asking me to do something about it. Right now I can't. So what I want to do is have something that creates, and consumes a random password. The user could email me, and I could give them some random key the app could recognize, and let them in so they can change their password.
It doesn't have to be anything super secure. Any help is appreciated.
I don't think its a good idea to implement a "backdoor" in your application. THis will create a very bad taste.
If i understood correctly, you want to "unlock" the application, not knowing if the user doing this is in some way authorized. I steal a device, send you an email and you take care i can see the data. Sounds bad...
All (good) safes i know rely on the user to take care of their keys. They want security and they are responsible.
EDIT
You can provide a "security question".
Anything else i tried to construct for an "autonomous" password reset raises sever security questions (what are the authentication/authorization mechanics)
EDIT
How far are you willing to go? Assuring the possession of something (like an SMS or mail account) may reduce the issues and give some impression of security. So you can intercept SMS or mail from a PREDEFINED (application settings) account with lets say the key word "unlock". If not set, this feature is disabled. SMS interception should no be that hard.
Why don't you just build password reset functionality in the app itself? If it's not using a web service, why do you or your server need to be involved at all?
If they don't remember their security passwords, for example, your server could store an md5 hash of their password to match up their mobile device with their record on your server so you can send them a key to reset the app.
Couple of thoughts:
Is there any sort of registration process? If so, at registration time you could randomly generate a second password that you don't tell the user but just keep on file for such contingencies. Or similarly, you could offer users a "password recovery" option -- click this button to generate a backdoor password.
You could have some algorithm that generates a password from the machine id of the device and that works as an alternate password. If you were a big organization with millions of copies of your app out there, or if the information in your app was super secret, this would be a super bad idea, as sooner or later hackers would figure out the algorithm and then they could break into any machine they wanted to. But if you're a small target, it's likely no one would work hard enough to crack it.
Do you necessarily know anything about your users? Like could you generate a password from their credit card number or their address or some such? Of course this makes you vulnerable to any hacker who could discover whatever information about a potential target.
Anything like this you do you are going to create a big potential security hole: What if someone steals someone else's device, then emails you and says they lost their password? How do you know it's the rightful owner of the data? If anybody can call or email and say, Hey, I lost my password, please let me in the back door, then you have no security any more.
This is not a technical question. How do small organizations keep sensitive information that must be shared among several individuals safe, such as root passwords to production servers? Not all people that need to have access work in the same location.. new passwords can be distributed by phone, but what rules should be enforced for team members in the storing of the passwords?
UPDATE: this question is not about the proper usage of root passwords -- that was just meant as an example. Maybe a better example would be the SSL passphrase or any other password that must be shared among people performing administrative tasks. The fact is, root passwords and the like need to be generated and stored and usually more than one person needs to have access, sometimes those people work in different locations. The question is about storage protocols. Thanks.
You shouldn't be handing out (or using) root passwords to any servers, production or otherwise. You shouldn't be sharing passwords.
People should log in as themselves (authentication) with their own user ids passwords; that's one half of the picture.
When properly logged in they should be given rights (the authorization side of the picture) as appropriate. You can use things like sudo for general OS purposes, and the rights mechanisms inside databases, etc.
These are two separate issues. Don't cross the streams!
I personally recommend to people facing similar problems to use something like keepass or roboform to store passwords. These programs encrypt your passwords on a thumbdrive using a master password that the individual remembers, so that they need only remember the master password. In the event that someone looses their thumbdrive, they will have a window of time in which they can report the compromised thumbdrive, and allow you to change passwords. It will take a little bit of time, depending on the master password's strength, before the person who stole the thumb drive would be able to brute force the master password to get at all the other stored passwords.
Additionally, avoid having any account shared by more than 3 people, if at all! Instead, consider creating each individual an account with equivalent access. If a malicious employee has access to an account which they know is shared, it might be more tempting for them to do malicious things since they know you could not hold them accountable, since it could have been any of several people sharing the account.
This also means you don't have to change the password every time someone quits. Instead, you just disable/delete their account. So although you have more accounts to manage, you have less overhead when someone leaves since you don't have to notify everyone of a changed password.
Edit: Oh Roboform also has a online password sync service over SSL. So you could just have people retrieve passwords via syncing. It's kinda cool once you get used to it.
With the advent of sudo we seldom need to use a root password any more. In my old shop, the root password was written on a card, sealed in an envelope, and locked in a drawer in the sysadmins' area. Those who needed to know had keys to the drawer.
Anybody opening the envelope was required to change the password and put the new password in a new sealed envelope. The envelope was not opened often.
This system is probably really bad professional practice, but in a small shop where everybody knew everybody, it worked well.
In a prototype & R&D lab where I formerly worked, there were 'standard' lab passwords for things like root, administrative access to consoles, switches, etc. These are simple, easy to remember, and shared verbally with anyone who needed them. In general, if you could physically get into the lab, you were authorized to have these passwords.
In the manufacturing facility, new systems were built and configured for customers. The customer got to choose all the passwords, and they were printed on a set of forms that were attached to the rack with the systems. Remote access was provided as required, and the passwords were sent in an e-mail, or given over the phone. It was fully expected that the customer would change these passwords as soon as the system was delivered to them.
For the IT & Production labs, almost no one had root access. Almost everyone did have sudo access with somewhere between no limits and only the ability to mount virtual filesystems...depending on the person and the system. It was very rare to get sudo access to launch a shell as root. This left a very clear log trail of all the commands you ran as root. That log was used to tar & feather more than one person over the years.
At a help desk / support role I had many years ago, each tool expert picked their own administrative passwords. These were recorded in an envelop that was locked in a safe in the machine room. If someone needed admin access, they could open the envelop, read the password, and note in the log that they knew the password and then re-seal the password in the envelop. It was up to the tool owner to decide if the password needed to be changed. This system was used for more than 5 years...and in one case actually helped the project to survive the "bus test" (heart attack) for one team member.
Different standards for different kinds of systems and labs. That is reasonable. I find that when passwords need to be shard, it is best if the password is simple, short, and communicated verbally (either in person or over the phone). I find that the only password that should never be shared is the one for my personal account. Any root/admin/tool specific passwords should be backed up in at least one other head...if not recorded in some manner.
you can use a program like anypasswordpro to share passwords. It is encrypted and has levels of access :)
Be realistic. Whether you like it or not, people in small teams are going to write passwords on sticky notes, IM them, or be tempted to email them, especially when they perceive no threat.
One measure I've found useful with small groups is to establish an obfuscation protocol.
For example, all passwords communicated or stored via voicemail, email, IM, or paper will have
1) the order of their characters reversed
2) a random character or word placed in between each password character
3) phonetically pronounced password characters.
For example:
Password: VMaccp#ss1
Obfuscated: one 2 es df es 23 at sd pee fd see dfs see fxz ay df EM sd VEE
The key is to establish some kind of encoding that is virtually impossible for someone to figure out without knowing the protocol, which is easy to remember.
Keep in mind this is for small groups without life-or-death security. Obviously for larger groups or those protecting extremely sensitive financial data stronger more cumbersome measures are appropriate.