I'm writing CLI application secured with strong password. The users supposed to run it on a server inside of secured perimeter over ssh. My users complain it's too annoying to enter the password every time.
I'm trying to figure out if it's possible to use user's ssh keys to authenticate them in my app instead of inputting application password. I can't rely on $USER because I want bind authentication to user's ssh keys.
I considered ssh-agent but it runs on user's machine afaik. I'm considering PAM now, but not sure if it's possible to check the keys the user used to authenticate.
Could anyone suggest if it's possible and where to research?
As Martin Prikryl commented, there is no robust solution other then install custom OpenSSH server. More over, there is probably no way to prove cryptographically that the user utilized certain key to log into the system.
Setting up environment variable (in any way) is not sufficient to prove the user actually owns it.
Related
While I understand the various options available for server to server authentication between REST services, I could use some clarification on the security implications of each approach.
I want a service to verify that a request received does originate from a legitimate calling remote service. No interactive users involved, assume the request happens as the calling service starts up. The three approaches usually mentioned are:
Use a fake user account and authenticate the client against the existing auth system
Use a shared secret / API key and sign the request
Use a client certificate (verifying the server is not a priority) 3.
The part I am missing is that it seems that all three methods depend entirely on the calling service's host (the client in the call) not being compromised. In the first approach this would give away the fake user password, but in the two other approaches an attacker could obtain the shared secret or the client certificate and impersonate the calling server just as easily as with approach number 1... so in what respect are 2 & 3 considered more secure?
If the host is compromised, the game is already over. You cannot hope to use network security techniques to provide guarantees about the end systems, that is not what they're meant for. Consider passwords, for example. When a user types in a password, the guarantee you have is that the entity that entered the password knows the password, that's all. Designing to be secure against compromised hosts is like trying to build a password scheme that only authorizes you if you're the real person - you're expecting a guarantee that the mechanism is not built to provide.
If you want to check the calling server is not compromised you might want to use TPM based verification of the calling server in case the machines have TPMs on them. Once it has been verified that it is not compromised any of the above 3 methods would be secure.(ref: http://en.wikipedia.org/wiki/Trusted_Platform_Module)
When I use the appcmd list appool <ApplicationPoolName> /text:* command, it shows me the application pool identity passwords in clear text. I am able to view the passwords in clear text using Get-WMIObject in PowerShell as well. This can be a serious security threat as a user with correct access credentials can easily view the passwords.
The Application Pool in IIS (v7.5) is configured using domain user account/password. In the applicationHost.config file, the password is encrypted using IISWASOnlyAesProvider encryption provider. Still, the password is shown in clear-text when I use any of the above two methods.
Is there any way to encrypt passwords in such a way that they are not shown in clear-text when I use the above two methods?
Unless something has changed, the answer is no. The principal is best stated by Raymond Chen:
'It's like saying that somebody's home windows are insecure because a burglar could get into the house by merely unlocking and opening the windows from the inside. (But if the burglar has to get inside in order to unlock the windows...)'.
The point in summary, is that anyone that can get to your IIS server or can execute a WMI command remotely against your server, or can execute a powershell command against your server has access.
They are assumed to be admins, and are assumed to be trusted, as occassionally admins would need to pull passwords for recovery purposes, or adding nodes to a shared pool if proper notes or password management wasn't done [mainly needed when doing basic authentication on a domain cluster needing shared passwords].
The passwords are only decrypted if you run appcmd as Administrator. If you run as a normal account, you get back the encrypted string.
This will be something like [enc:IISSomethingProvider:…:enc], just as you find it in applicationHost.config.
I'm trying to write a script which takes a username via argument and password via stdin. I'd like the script to contact the kerberos server and verify the password. I'm going to use this to authenticate perforce users via an auth-check trigger. I'm not too wedded to any particular language although bash and perl are already installed on the (centos 5) system concerned.
Any hints/suggestions would be much appreciated.
Thanks,
Fenster
This Perforce article has some useful links to get started.
http://kb.perforce.com/article/74
I think Kerberos saves a ticket on the machine you're authenticating on, so perhaps Perforce's SSO framework would be better. Check out this project:
http://www.assembla.com/spaces/sso-p4/wiki
Be aware that effectively verifying a password requires more than just doing kinit (an AS exchange). That is open to a KDC spoofing attack: the attacker hands you a password, then redirects your KDC request to his own KDC which says the password is OK.
The usual way to guard against this is for the verifier to have a service principal of its own; it kinits the user's principal, then uses the acquired TGT to obtain a service ticket for its own principal and verifies that ticket. This ensures that it is talking to the same KDC.
Just come across pwauth on google code. It can be configured to verify system passwords using the pam interface. It looks like its been designed with apache in mind but should work for any scriptable situation. Going to try and set this up this week. Will report back when i've tried it.
NB there are risks with exposing your system accounts so the link directs you to the risks page first.
Hi and thanks in advance,
I am looking for industry best practice or a ready made app to store and share passwords for for network resources.
My current situation is that I have a number of people that need to access applications as a specific superuser in order to access some features of these applications. The applications are third party build and cannot be changes to grant access to the required features for anyone but the superuser account. Normal admin accounts have elevated rights but things like creating accounts have to be done via the superuser account.
For security reasons I would like to periodically change the superuser accounts' password. Because of the number of people that need to be able to log in as superuser changing the password would be problematic and a logistical nightmare.
I'm looking to purchase or create an application that would:
Track who is looking up the password and to what resource
Allow me to specify what passwords a user can retrieve
The data should be stored and transmitted ultra securely
Preferable this would be an on-line application (I have Mac and Windows clients)
Keypass is great for this kind of thing. It provides a strong encrypted database of passwords and secure information. This can be accessed share via svn/dropbox/fileshare implementations using a master password.
This is more for a master database of secure data you can set up additional databases, maybe per user, but it starts to get a little away from what it's deigned for.
I would do a C# app that checks with a web service if the user can run the app and with what permissions, it would then be sent the encrypted credentials for a 1 time run, the service would log the request. This would all have to be done securely, so the service would use SSL and preferably certs between the systems. You have a good bit of research here to figure this all out, and you might have to use Java if you want mac... but I dont know how well that can launch apps as other users.
Solution #2 would be to use KeePass. You will have to be creative.
I have a Silverlight 3 app which connects to a server to perform various actions. My users log in using Forms Authentication but the actions they request are run on the server using the AppPool account so when they go in the audit logs they're recorded against the AppPool account. PCI DSS regulations now require that the user's own ID is in the audit logs which means the action must be taken using the user's creds. Now, I can save the user's creds when they log on and submit them with each request and the actions being taken by the server can use those creds. But the PCI regs say that if creds are saved they must be encrypted (to avoid someone taking a memory dump of the PC and getting the password).
The only way I can see of doing this is to get a public key from the server and encrypt the password with it, then submit the encrypted password and decrypt it on the server using the private key. But Silverlight doesn't have asymmetric cryptography.
I guess I'm too close to the problem and there must be another solution but I can't see what it is. Can anyone help?
CLARIFICATIONS
It's an internal application. Up until now, I've been using IIS Forms AuthN over SSL to Active Directory - I'm not worried about protecting the password in transit, just whilst it's held in memory on the client. As I understand it, because I'm using Forms Authentication, impersonation is not possible on the server unless I use LogonUser, which means I need the password on the server, so I need to transmit it each time, so I need to hold it in the client, in memory, until the app closes.
Are you saying you need to store the password for re-use in the silverlight app? If you are concerned about the password appearing in memory un-encrypted then Silverlight then I think you're in trouble.
The .NET framework does have a SecureString class for exact purpose you outline.
Unfortunately the Silverlight version of the framework does not have this class. Hence even if you were to keep the logical storage of the password encrypted at some point your code would need to decrypt it before using it. At the point there is memory allocated containing the string in unencrypted form.
I don't know much about Forms authentication but if you can map the User principle to a domain user (which you seem to indicate you need) then you will want to use impersonation when running your code on the server.
Alternatively stop using Forms authentication and use Windows integrated authentication where you definitely can use impersonation server-side.
Encryption should never be used for passwords. When you encrypt something then it follows there should be a way to decrypt it. One way hashes should always be used for passwords. md5 and sha1 have been proven to be far too weak for any secuirty system.
Sha256 should be used, and in silverlight this library will take care of it:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha256%28VS.95%29.aspx
In fact storing passwords using "encryption" is recognized by the vulnerability family CWE-257. The use of a message digest is the ONLY way to safely store passwords. I didn't just make this up, this is coming from NIST. There are many other vulnerabilities that come up when storing passwords. Here is THE LIST that NIST has put together: