The reason why DPAPI doesn't require administrator rights is
Is it because it uses the user's password as the key value?
If I am mistaken, please comment.
Sorry for My English skills.
Have a nice day!
DPAPI encrypts some secret value using a key that is ultimately derived from your credentials in Windows (can be a domain secret too, or some public key certificate even, but on a typical computer knowing the password (or actually its SHA1-hash, or in a domain its NT hash) is enough. It's often even tied to specific computers, but can be set up so as to allow domain-credentials to work on every machine you have logon rights on for that domain. It's quite flexible.
Related
I would like to choose a password manager to generate postgres users and passwords on demand with limited TTL. In addition I would like this password manager to have high-availability (cluster of 3?). I prefer this utility to be opensource and free.
If you are using one and having good experience, I would appreciate getting your recommendation.
Thanks!
Use Kerberos or LDAP authentication and manage your password there. That allows you to enforce fancy rules on passwords. The only downside is that you have to write something that keeps the PostgreSQL users synchronized with the users in the identity management system.
With passwords stored in the database, you cannot have password expiration (which is considered bad security anyway).
Can you explain me the exact reasons and benefits of using hashes of password instead of the passwords themselves?
Because parcticly if you got hash of user you can authenticate as that user, and anyway the password is invisible.
It's more secure to store a hash of a password rather than a password itself (e.g. in keytab).
Kerberos only transfers over network encrypted Authenticator with its own copy of a secret key. Authenticator contains unique information about the client (for example, client name, client realm, the time on the client, and so forth). Each Authenticator is unique, because of the time information it contains.
So information transferred over network can't be reused (replayed later by an attacker), as Authenticator is unique and depends on time.
Hope this helps. With Kerberos you don't have password stored nor transferred over network. Which makes it more secure.
Consider the following interaction:
A user stores their username and password on a web server. For the sake of security, the server records a hash of the password plus some unique salt.
While the user is using a client application, it makes a request to the server submitting their username and a hash of the password plus some other unique salt.
So you have the following information on the server and need to know whether or not the request is authentic:
The server's salt
The server's hashed password
The client's salt
The client's hashed password
Again ... client sends: clientSalt + MD5(clientSalt + password). Server has serverSalt + MD5(serverSalt + password). I don't want to know the password, I just want to know if the hashes were calculated from the same password.
Without knowing the password that was hashed, is there any way to verify that both hashes are of the same password?
My goal is to allow some form of secure authentication in a client-server environment without ever exchanging the actual password over the wire. This is just one idea I've had, but I don't even know if it's possible.
That would require unhashing the password, which is not possible. If the server receives: salt, md5sum, it can't see what went into the md5sum.
A challenge-response protocol would work instead. The server should generate a random value nonce and send it to the client. The client calculates md5(md5(password) | nonce)) and returns it to the server. The server verifies by checking md5(storedpassword | nonce).
No, you can't do this.
Once you add a salt into the mix it becomes practically impossible to compare hashes. (To do so would require "un-hashing" those hashes somehow before comparing the "un-hashed" data.)
Challenge-response authentication is probably the way to go, possibly using Kerberos, depending on your tradeoffs. One of the tradeoffs being the possibility for attackers controlling the clients to use compromised hashes to authenticate themselves.
Don't invent your own cryptographic protocols. Use one that is well-known and well tested. If possible, use an existing (vetted) implementation.
My goal is to allow some form of secure authentication in a client-server environment without ever exchanging the actual password over the wire. This is just one idea I've had, but I don't even know if it's possible.
For this, I advise looking into Kerberos: Official Site and Wikipedia
It's impossible. If you don't store password on the server, user must provide it.
OR
If you store password on the server, user can provide hash calculated using requested salt.
You will not be able to verify the hash with this setup.
If you don't want someone to see the password go over the wire, SSL is the easier way.
If you don't want to use SSL, you could check out SRP.
Additionnally: don't use MD5+Salt to store your password, use key strengthening functions like bcrypt or scrypt.
There are several applications that use your domain credentials for login. Eg: Custom Corporate apps. How do you ensure that such applications don't store your password?
The reason I am asking this is: If you are designing an app which does the same thing, how do you convince the user that your app can be trusted not to store the password?
If you really want the user to be sure your app is not keeping their password, don't use their password.
Microsoft Active Directory Domain Logon uses Kerberos. Kerberos is an SSO solution; an application may make use of a user's Kerberos credentials without requiring that the user enter their password a second time. The credentials obtained by the application may only be valid for as long as the user's Kerberos ticket - probably at most a week.
If you have a web application, it too may take part in the warm goodness via SPNEGO. You may have seen this in the form of Sharepoint sites that don't require a login if you are on the company domain.
If you have used standard AD-based Windows authentication they shouldn't have your password but they could certainly perform actions using your user context.
If you provide a username/password to login using standard Windows authentication then there is no way for you to be sure they haven't saved that.
If Windows auth issued login tokens that expired this might be a different story, but I do not believe that is how it works and certainly would still be useless with the second case.
I'm creating application that will create certificates for users. I want to mark somehow those certificates so that later I can search them in windows user certificate store by following categories:
application GUID (or name - I want to know that this cert is for my application)
certificate role (administrative certificate or user certificate)
user email
I know that for the last one I should use "E = J.Doe#mail.com" or OID number "1.2.840.113549.1.9.1 = J.Doe#mail.com"
But I don't know which OIDs to choose for application GUID and certificate role.
Or maybe I should use "Key Usage" field?
I don't know if it's important, but certificates will be used to authenticate to my application and to decrypt data in database.
Are there any standard ways to do it ?
Hmm... so what I'm thinking is that you plan to issue certificates to each user and you plan to make a different certificate for each application. So if you had 10 users using 3 applications each, you'd be making 30 certificates.
And then the certificate also describes the user's role within the application, and the users's email.
To tell you the truth, I wouldn't put all this information in a certificate. PKI is hard to provision - users generally have difficulties setting up certificates, and reissuing certificates is a pain. Generally, PKI deployment strategies try to minimize the number of certificates that must be issued, balancing that with risk.
The most typical scenario I've seen is that a user is given a single certificate which he uses to identify himself. The certificate includes the user's name, and his email. But it doesn't usually include the user's role or the specific application. Instead, this information is managed on an access control server, that is queried when the user accesses the system. That way, the roles and applications available to the user can be changed without having to reissue the certificate. Products like Active Directory, or Select Access do this sort of thing.
The reason to separate into a separate cetificate per usage is to specifically control some type of risk. For example, if a single user where doing a high-risk operation on one machin and a low risk operation on another, more potentially risky machine, there would be a case to have two certificates (one for each machine) so you could revoke the low-risk certificate without disabling the high risk functions. If you plan to store all the certificates on the same machine, it would be easier to only distribute one certificate per user.
That said - if you still see a need to issue 1 cert per user per application per role, I'd recommend finding a way to jam the application GUID, role and email into the Distinguished name.
You won't get much mileage out of Key Usage or Extended Key Usage - these have very specific value and I doubt that they will convey the information you want to describe. Also, they are used in particular ways by various other applications, so if you need to integrate with other things, that could get tricky.
OK, after few hours I came with something like this.
All Certificates will be recognized by Subject field.
For Administrator certificate it will look like this:
CN=<My application Name> Administrator,OU=Administrator,OU=<My application Name>,O=<My company Name>
and for users
E=<User email>,CN=<User email>,OU=User,OU=<My application Name>,O=<My company Name>
If someone has better idea, I'm open for suggestions :-)
Your task is a quite complex task. To solve it the best way is to put on work a little internal certification authority with openssl. Keep in mind that PKI assigned to the entities you referred the following rule:
Distinguished name: it is used to identify the user or entity to witch the certificate is issued. It's no properly correct to use it for identify two different entity within a single certificate: your user and the application. The two entities shuold be identify in two distinct place.
Key Usage is a bit field with 8 digit that defines the usage of the key. Every bit has its predefinited meaning and cannot be used for other purpose.
I suggest to you to:
Put the application GUID as x509 extension. You can assign and personal OIDs to that exension and query for it. If you OIDs is use internally you can utilize whatever value you want. If you plan to distribuite your certificat eyou can obtain your own OID from IANA
Put the mail in the fields subject alternative mail, as suggested by PKI.
For the aministrative or user you can add a second x509 extension or create a tree of certificate. The main CA certificate, the admin CA certificate and the user CA certificate. Every certificate for admin will be signed by the admin CA, every user certificate by the user CA.