Our Perforce server is set to security level 0, meaning that most users don't require passwords. This is fine (and necessary for our legacy tools). However I recently discovered to my horror that some admin user accounts don't have passwords set. This is obviously very bad.
How can we configure Perforce to require passwords for superuser accounts, but not for regular accounts?
I seem to remember this was the case by default, but someone seems to have defeated it, and now I can't find any mention of it in the Perforce manual.
We cannot change the server to require passwords from all users without breaking the whole company. Setting the server security level to >1 globally is not a workable answer.
Nope, this was never a feature.
My solution to this has historically been to have a script that tries to run a command as each user. In your case you want to only look at users with admin-level permissions, so have the script run a command that only admins should be able to run:
p4 -u $USER protect -o
If this succeeds (despite the lack of any password being provided), deal with them as you like. In my case I wasn't targeting admin users specifically so I just had my script set a random password and email it to them with instructions for changing it.
Given your scenario, my recommendation would be to just revoke admin access, since someone who's not savvy enough to secure their own account probably shouldn't be trusted with the ability to grant access to others, install triggers, permanently delete data, etc...
Related
This question is going against the grain of every best practice I've been taught, but it's a larger issue with my current organization. The crux of it is, I need to see what a users password currently is, not just reset it. There are a few reasons for this.
My organization has an active directory, but it is used solely for remote terminal services. There is propriety software in place that does not sync with anything and we manually create user accounts within these various programs/databases, and just manually set their credentials to the same ones they use to login to their office 365 account. The online exchange is the heart of our business, not the active directory.
Due to this, passwords are set to never expire, and a masterlist is kept of all users and their passwords. All of this is transparent to the end user, as far as they are concerned, they only have one account across everything because they're logins are the same for everything, but that is because we manually set their credentials as the same. Now when a user forgets their password (especially our mobile guys as they receive their phones/tablets already logged in and rarely know their passwords) we consult the master list. However, in this circumstance, the user, for whatever reason, is not in the masterlist.
This has probably been the case for months but was only just noticed when I had to set them up with a new tablet. The user does not know their password, and without the masterlist I can't see what it is. The only other option I see available to me is to reset the users exchange password (I'll explain the process I follow below) and have the user call me every time he is unable to login to something, go to it, and reset his password or (in some cases) create him a new account (which is not at all ideal as he will loose all of the linked data he has built up over the years) and start again.
I am well aware how poor these practices are and have been pushing hard to get them changed, but that is another matter.
Now the way I currently reset a users password (as the office365 webapp does not allow manually setting of passwords) is to run powershell off my IT laptop with the exchange, azure admin and azure sign in assistant plugins, and enter the following commands:
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -credential $UserCredential -Authentication Basic –AllowRedirection
Login with my domain admin account
import-pssession $session
and
connect-msolservice
This gets me to the online exchange powershell session where I can run the password reset command
Set-MsolUserPassword –UserPrincipalName TYPE_USERNAME_HERE –NewPassword TYPE_DESIRED_PASSWORD_HERE -ForceChangePassword $False
However I need to see what the password currently is. In my searching I have found many resources explaining how to get information about when the password was last set, if it's set to never expire, that sort of thing. However so actual answers on how to retrieve the users current password (and display it in a readable format as, presumably, it will be encrypted). I have, however, been led to believe it is possible by this post I found:
Powershell Scripting example link
So I basically need to know what powershell commands to run to retrieve and decode a users current password. I am my organization I.T. Admin and have full admin rights. Also, this is my first stack exchange post so let me know if there's any additional information you need. I appreciate the help.
Short answer: It's not possible.
Passwords are not directly stored in Active Directory, they are hashed and it's that hash that is stored. When you enter your details, the system hashes the password you entered and compares it with what it has stored. The algorithm used to make that hash is one way only and as such, the only way to get back to a password is to brute force crack it.
Long answer: It might be possible if you change an AD setting which changes how passwords are stored (i.e. reversible encryption) but to do that would be pretty crazy.
We have a little problem. The company I'm working for now has one main admin account. This is a problem as some contractors knows the password and then login using the admin account and not there own.
The problem is that if we do change the password, the account will be logged out as there is about 200 contractors.
I need to restrict those 200 contractors from sing the admin account. But everyone not part of the list of 200 should still be able to use the admin account for remote desktoping.
Any help would help a lot.
you NEVER allow ANYONE who is not the admin to use the admin account.What you are going to need to do is create elevated privileged accounts for your contractors that can do what they'll need to do, then tell them to log into those accounts and once every contractor has logged out/in, change the admin password, be polite but firm, you can add permissions to any contractor that needs it but none of them get the admin account anymore. It's just too dangerous for everyone. they are not idiots, they'll understand.
edit: as for everyone else who needs remote access make accounts for them too, hell if you trust them, you could make sub-admin accounts, but just don't let everyone use the admin account. It WILL end up biting you in the end.
I'm not too sure about local networking, I've only had experience with ssh networking, but have you thought of using private keys? Again I know this works for my purposes, not certain for local.
Here's a good guide to a linux setup. Don't know about other OS's.
There should also be some sort of disciplinary action to stop people logging into wrong accoutns, especially admin ones.
I have a sudo account (not root) on several CentOS servers. We would like to share the cluster with other uses who do not have an account for research purpose. (By share I mean users can reserve a time slot to use the cluster exclusively.) But setup an account in the OS for each user is too annoying. Is there a good way to grant them authority to read/write/execute their own files during a certain period of time? I am thinking something like temporary username and password that they can use to login through some interface (like a webserver) I offered. And the username and password will expire after when their reservation. Any idea?
You can share your unix user account among several users, by using SSH key authentication.
In a nutshell, each user generates a public/private key combination. The allowed public keys are then listed in the following file on the shared unix acount:
$HOME/.ssh/authorized_keys
I'm not aware of a mechanism to control when users are allowed to login. Presumably one could have a cronjob that swaps different versions of the authorized_keys file, dependent on the time of day. (Seems like over engineering the solution, users can easily over-ride this kind of restriction).
Articles:
http://wiki.centos.org/HowTos/Network/SecuringSSH
http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/pka-putty.html
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
I'd like to know what people consider best practice for securing the Admin sections of websites, specifically from an authentication/access point of view.
Of course there are obvious things, such as using SSL and logging all access, but I'm wondering just where above these basic steps people consider the bar to be set.
For example:
Are you just relying on the same authentication mechanism that you use for normal users? If not, what?
Are you running the Admin section in the same 'application domain'?
What steps do you take to make the admin section undiscovered? (or do you reject the whole 'obscurity' thing)
So far, suggestions from answerers include:
Introduce an artificial server-side pause into each admin password check to prevent brute force attacks [Developer Art]
Use separate login pages for users and admin using the same DB table (to stop XSRF and session-stealing granting access to admin areas) [Thief Master]
Consider also adding webserver native authentication to the admin area (e.g. via .htaccess) [Thief Master]
Consider blocking users IP after a number of failed admin login attempts [Thief Master]
Add captcha after failed admin login attempts [Thief Master]
Provide equally strong mechanisms (using the above techniques) for users as well as admins (e.g. don't treat admins specially) [Lo'oris]
Consider Second level authentication (e.g. client certificates, smart cards, cardspace, etc.) [JoeGeeky]
Only allow access from trusted IPs/Domains, add check to basic HTTP pipeline (via e.g. HttpModules) if possible. [JoeGeeky]
[ASP.NET] Lock down IPrincipal & Principal (make them immutable and non-enumerable) [JoeGeeky]
Federate Rights Elevation - e.g. email other admins when any admin's rights are upgraded.
[JoeGeeky]
Consider fine-grained rights for admins - e.g. rather than roles based rights, define rights for indicidual actions per admin [JoeGeeky]
Restrict creation of admins - e.g. Admins cannot change or create other admin accounts. Use a locked-down 'superadmin' client for this. [JoeGeeky]
Consider Client Side SSL Certificates, or RSA type keyfobs (electronic tokens) [Daniel Papasian]
If using cookies for Authentication, use separate cookies for admin and normal pages, by e.g. putting the admin section on a different domain. [Daniel Papasian]
If practical, consider keeping the admin site on a private subnet, off the public internet. [John Hartsock]
Reissue auth/session tickets when moving between admin/normal usage contexts of the website [Richard JP Le Guen]
These are all good answers... I generally like to add a couple additional layers for my administrative sections. Although I've used a few variations on a theme, they generally include one of the following:
Second level authentication: This could include client certificates (Ex. x509 certs), smart cards, cardspace, etc...
Domain/IP restrictions: In this case, only clients coming from trusted/verifiable domains; such as internal subnets; are allowed into the admin area. Remote admins often go through trusted VPN entrypoints so their session would be verifiable and is often protected with RSA keys as well. If you're using ASP.NET you can easily perform these checks in the HTTP Pipeline via HTTP Modules which will prevent your application from ever receiving any requests if security checks are not satisfied.
Locked down IPrincipal & Principal-based Authorization: Creating custom Principles is a common practice, although a common mistake is making them modifiable and/or rights enumerable. Although its not just an admin issue, it's more important since here is where users are likely to have elevated rights. Be sure they're immutable and not enumerable. Additionally, make sure all assessments for Authorization are made based on the Principal.
Federate Rights Elevation: When any account receives a select number of rights, all the admins and the security officer are immediately notified via email. This makes sure that if an attacker elevates rights we know right away. These rights generally revolve around priviledged rights, rights to see privacy protected information, and/or financial information (e.g. credit cards).
Issue rights sparingly, even to Admins: Finally, and this can be a bit more advanced for some shops. Authorization rights should be as discreet as possible and should surround real functional behaviours. Typical Role-Based Security (RBS) approaches tend to have a Group mentality. From a security perspective this is not the best pattern. Instead of 'Groups' like 'User Manager', try breaking it down further (Ex. Create User, Authorize User, Elevate/Revoke access rights, etc...). This can have a little more overhead in terms of administration, but this gives you the flexibility to only assign rights that are actually needed by the larger admin group. If access is compromised at least they may not get all rights. I like to wrap this in Code Access Security (CAS) permissions supported by .NET and Java, but that is beyond the scope of this answer. One more thing... in one app, admins cannot manage change other admin accounts, or make a users an admin. That can only be done via a locked down client which only a couple people can access.
If the website requires a login for both regular activities and admins, e.g. a forum, I'd use separate logins which use the same user database. This ensures that XSRF and session-stealing won't allow the attacker to access administrative areas.
Additionally, if the admin section is in a separate subdirectory, securing that one with the webserver's authentication (.htaccess in Apache for example) might be a good idea - then someone needs both that password and the user password.
Obscuring the admin path yields almost no security gain - if someone knows valid login data he's most likely also able to find out the path of the admin tool since he either phished it or keylogged you or got it via social engineering (which would probably reveal the path, too).
A brute-force protection like blocking the user's IP after 3 failed logins or requiring a CAPTCHA after a failed login (not for the first login as that's just extremely annoying for legit users) might also be useful.
I reject obscurity
Using two authentication systems instead of one is overkill
The artificial pause between attempts should be done for users too
Blocking IPs of failed attempts should be done for users too
Strong passwords should be used by users too
If you consider captchas ok, guess what, you could use them for users too
Yes, after writing it, I realize that this answer could be summarized as a "nothing special for the admin login, they are all security features that should be used for any login".
If you do use only a single login for users who have both normal-user privileges and admin privileges, regenerate their session identifier (be it in a cookie or a GET parameter or whatever...) when there is a change in the level of priviledge... at the very least.
So if I log in, do a bunch of normal user stuff and then visit an admin page, regenerate my session ID. If I then navigate away from an admin page(s) to a normal user page, regenerate my ID again.
Have a good admin password.
Not "123456" but a sequence of letters, digits and special characters long enough, say, 15-20 characters. Like "ksd83,'|4d#rrpp0%27&lq(go43$sd{3>".
Add a pause for each password check to prevent brute force attack.
Here are some other things to consider:
One option to consider, especially if you manage the admin's computers or they are technically competent, is to use something based on SSL certificates for client authentication. RSA keyfobs and whatnot can also be used for added security.
If you're using cookies at all - perhaps for an authentication/session token - you probably want to ensure that the cookies are only sent to the admin pages. This helps mitigate the risks posed to your site by stealing cookies, by either layer 1/2 compromise or XSS. This can be done easily by having the admin portion being on a different hostname or domain as well as setting the secure flag with the cookie.
Restricting by IP can be smart as well, and if you have users throughout the internet you can still do this, if there is a trusted VPN that they can join.
We use Windows Authentication for admin access. This is most practical way of protecting admin areas while keeping the authentication seperate from what applies to general end-users. The system admin manages the Admin user access credentials and enforces password policies on the domain user account.
The strict way is to have two complete different "farms" including databases, servers and all and move the data from one farm to the other. Most modern, large scale, systems use this approach (Vignette, SharePoint, etc.). It's normally refered to as having different stages "editing stage" -> "preview stage" -> "delivery stage". This method lets you treat content/config the same way you treat code (dev->qa->prod).
If you are less paranoid you can have a single database but only have your admin section available on the "editing" servers. I mean, only have the editing scripts/files placed on the editing server.
Naturally the editing stage should only be available on a local intranet and/or using a VPN.
This may seem a bit of an overkill and may not be the easiest solution for all usage cases, but it is definetly the most robust way of doing things.
Note that things like "have strong admin passwords" are nice, but still leave your admin open to smart attacts of all sorts.
It very much depends on what kind of data you want to protect (legal requirements and such).
Alot of suggestions is about authentication.. I think you just should consider using OpenId / Facebook authentication as login. (They will most likely spend more resources on authentication security then you)
Save changes as well as updating values in the database. That way you can rollback changes from user X or between date X and Y.
I didn't notice anyone mention storage/validation of the admin password. Please please please do not store the PW in plain text, and preferably not even something that can be reversed - use something like a salted MD5 hash so that at the very least if someone happens to retrieve the stored "password" they don't have anything terribly useful, unless they also have your salt scheme.
Add a password field and a security question that the Administrator will know, e.g. what was your first girlfriend name, or randomize the questions everytime viewing the admin panel.
Perhaps you could always put the administration section in a big directory, e.g.
http://domain.com/sub/sub/sub/sub/sub/index.php
But that's not really good hah.
Perhaps you could include a query string in the home page, like:
http://domain.com/index.php?display=true
When it does, the username and password field will appear.
When supporting a new web app in an enterprise environment, it is often necessary to log in as a specific user in order to diagnose a real or perceived problem they are having. Two opposing issues apply here:
Best practice is to use hashed or encrypted passwords, not clear text. Sometimes, there is a third-party SSO (single sign-on) in the middle. There is no way to retrieve the user's password. Unless the user provides it (not encouraged), there is no way to log in as that user.
Many web app's have personalization and complex authorization. Different users have different roles (admin, manager, user) with different permissions. Sometimes users can only see their data -- their customers or tasks. Some users have read-only access, while others can edit. So, each user's view of the web app is unique.
Assume that in an enterprise environment, it isn't feasible to go to the user's desk, or to connect directly to their machine.
How do you handle this situation?
Edit: I want to reiterate that in a large financial institution or typical Fortune 500 company with hundreds of thousands of employees all of the country, and around the world, it is not possible for a mere developer in some IT unit to be able to directly access a user's machine. Some of those are public-facing web apps used by customers (such as online banking and stock trading). And, many of those are intranet applications rely on Active Directory or an SSO, meaning that user credentials are the same for many applications. I do thank you all for your suggestions; some may be highly useful in other kinds of environments.
A number of these ideas inconvenience the user, either by forcing them to change their password, or by occupying their desktop for your debugging session.
Markc's idea is the best: augment your authentication logic to allow superusers to log in as a particular user by supplying not the user's credentials, but the user's name plus their superuser credentials.
I've done it like this in the past (pseudo-ish python):
if is_user_authenticated(username, userpassword):
login the user
else if ':' in userpassword:
supername, superpassword = userpassword.split(':')
if is_superuser_authenticated(supername, superpassword):
login the user
In other words, if the username and password don't authenticate, if the password has a colon, then it's actually the admin username and admin password joined by a colon, so login as the username if they are the right admin username and password.
This means you can login as the user without knowing their secrets, and without inconveniencing them.
For our web applications we use a process that for lack of a better term is defined as 'hijacking' a user's account.
Basically, administrators can 'hijack' a user's account with a simple button click. In the code, you simply use a unique identifier (user id works in a less secure environment) that then establishes the necessary credentials in the session so that they can then work within that user's profile. For a more secure environment you could use a unique hash for each user.
In order to ensure that this hijack method is secure, it always first verifies that the request is being made by an authenticated administrator with the appropriate rights. Because of this it becomes necessary for either the administrator's session to be hijacked or for their authentication credentials to be captured in order for someone to ever exploit the hijack function within the application.
I had 4 ideas. While I was typing 3 of them were already suggested (so I upvoted them)
Variant on idea 3 - impersonation:
To make this as "identical as possible" to a normal login with minimal code changes, you might add the ability to impersonate directly at login by supplying Admin credentials plus an alternate username, e.g. login as Admin:user, adminpassword. The system would treat this exactly as logging in as user with userpassword.
Idea 4: Can you access the password store? If so, temporarily replace the user's hash with the hash of a known password. (the passwords are often stored online in a database. A SQL Query tool can do the swaps )
An administrator should be able to change a user's password. Change the password for the user to something you know. You can then log in as that user.
Tell the user to reset his/her password after you are done debugging.
Usually by some sort of remote control software that can be used to view their desktop. If they're on a Windows terminal server, then the built in admin tools can be used for that. Otherwise I'd use something like VNC across an internal network, or an external service like LogMeIn (http://www.logmein.com/).
Could you have a testing environment where there is a regular cut of live data copied to (obviously sanitised to meet any security or data protection issues). A user similar in setup to the one having trouble could be used to troubleshoot or indeed the very user if this is allowed.
Use a remote desktop client as mentioned in other answers, but again this may not be practical for you. If you have these rights within the domain, I have heard of error handling even doing a screenscrape and including this in logs! but this sounds a little odd to me.
Could you have an admin tool to clone a user into a demo account?
The solution we have used in our web apps is to have the authN/authZ return the desired user as the effective user. We do this by having an admin feature to setup a masquerade, and then when we ask for the currently logged in user (current_user), we handle the masquerade:
def current_user_with_effective_user
if masked?
current_user_without_effective_user.masquerade_as
else
current_user_without_effective_user
end
end
alias_method_chain, :current_user, :effective_user