I know you can create new admin users via PUT $HOST/_config/admins/username -d '"password"'.
However, what if I have an existing user from the _users database and I want to add it to the
admin party?
The main problem here is that I don't know that user's password.
Thanks in advance,
Andres
Since the documents in the _users database contain password hash fields (derived_key, password_scheme, salt, password_sha, iterations) the hashes can be reused to create an admin using the raw=true parameter.
The hashed admin password format for PBKDF2 is as seen in the source code:
-pbkdf2-derivedkey,salt,iterations
For the SHA1 it is not quite clear which one is the hash and which one is the salt. Just try.
Note that the admin hashes are not stored in the _users database for a reason and reusing a password that was once exposed in this manner for an admin might be a bad idea security-wise.
Related
I have created a list of users in _Users database in couchDB, now I want to deactivate user, meaning the user cannot be logged into the the CouchDB. I do not want to delete the user from _Users database list, instead the user should not able to login. I am new to CouchDB can any one provide me the solution.
Perhaps you could change their password to a random value?
I am currently developping a platform with a PHP framework for our client.
The head of the client's IT department wants us to handle authentication with one database field containing email+password+salt (hashed) so there isn't a plain text email field in this table and the password is more secure (his reasoning). The user should be able to login with his email address and password. So the email address serves as the username.
The idea behind this is that the email addresses of the users are very important for the business of our client and the IT head wants to obscure the email address in the login table in case of a possible attack. (e.g. a hacker gets access to the login table)
This is of course only possbile, because the hashed email adress for the login is linked to his email address in the profile table.
Basically there are two tables which are required for this process to work. The tables are in the same database of course.
One login table with the hash combination field (email, pw, salt) and one profile table which contains among other things the email in plaintext in one field. Let's call it profile_email.
I have strongly recommended not to use this solution, because I have never before heard of this and I have already identified some possible problems with this solution.
So my questions are: Is this a safe and feasible solution? Can you think of any unforeseeable problems? Have you heard of similar solutions?
from an entity-relationship-point-of-view ...
you have a login table that either contains a field that is a concatination of hashes or a hash of a concatination of string values ...
you have a profile table that conatins the usual profile info, including a sensitive info (email)
if those two are linked by a key, the simple hashing of that email address is useless, since the same info is available as a clear text string from the profile table
in the other case, when in the login table it is ONE hash of a concatination of email password and salt, it is no added security, since the link to the profile table reveals a part of the hashed concatination ... since you also have to store the salt, and since that also has to be linked to the login entity or be part of the login entity, an attacker knows all parts of the concatination except the password ...
i can't see why this approach is a good idea, except if you split the database login for authentication from the rest ...
let's say you have in your login table:
s=randomSalt
e=cryptoHash(email,static_system_wide_salt)
p=cryptoHash(password,s)
id=KeyForRelationToOtherEntities
now the database rights to this table are restricted, and only the authenticator_user may access it, but nothing from the rest of the database
the email address in the authentication process is hashed and hardened against rainbowtable attacks
the password too
you can index the e colum for searching during the login process
the authenticator can not access profile information or other information that can be linked to the login entity, since the access rights restrict the authenticator to the login table
the rest of the system can't access the login table for the same reason
one additional role has to be taken into account, regarding password changes and creating new users if the authenticator may only read the login table
... just my 2 cents here ... it's just an idea, and not really complete, or guaranteed to be secure ... just an idea that picks up the general idea of separating the login table
I'm not absolutely clear about your scenario, but i guess it's something like this:
valueToStore = hash(email) + delimiter + hash(password, salt) + delimiter + salt;
This would allow to search for the email, but only if the email is made case insensitive (e.g. lower case). Otherwise you could even get duplicates with the same e-mail address.
Because the hashed email is only part of this field, searching in the database is more difficult and slower. If the user changes his email address, you would have to update both fields, the password table and the profile_email table.
Because the email is available in another table anyway, it is incomprehensible why this should be more secure. If an attacker has read access to the database (e.g. SQL-injection), there is nothing to prevent him from query the other table too.
It would be more safe, if the email would be encrypted (not hashed) in the other table too. Then you can search for the email by hash and nevertheless encrypt the email with an IV.
In every case i would not store the hashed email and the password-hash into a single field. If hashed correctly then other parameters like cost factor and algorithm are also part of the password-hash, this is enough for a single field.
Does anyone know what hash algorithm is being used by #Password formula? My client keeps user accounts in standalone LDAP server. They need to sync passwords from LDAP to Domino internet password in person documents. We are trying to find a way how to accomplish this having only hashed version of password in LDAP. If Domino #Password would use some known hash algorythm like MD5, SHA etc. we can store password in LDAP this way and simply replace it in person documents.
Any idea here?
The following link is the public details on the Encryption methods in Domino.
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/topic/com.ibm.help.domino.admin.doc/DOC/H_NOTES_AND_DOMINO_ENCRYPTION_2250_OVER.html
Depending on how you have your server set up, using #Password may not work. The administrator can set "Use more secure Internet passwords" option.
This generates a personalised salt for each user in the $SecurePassword field of the person document (the field is protected as well). To correctly hash the password in this instance you need to use #Hashpassword. If the administrator knows what they are doing then the related password fields will be locked down by the xACL to prevent external access (for security reasons).
It is a little unclear what you are trying to achieve though. You can use Directory Assistance in Domino to authenticate against a third party LDAP.
Just out of curiosity, I wonder why web apps typically user a userID and a password.
I don't see reasons, why a sufficiently long password doesn't fit too. For example, a password generated by a server-application.
Are there reasons an app ultimately has to use a userID too?
As long as password are unique and long, it perfectly allows to identify a user.
For one thing, password resets would be quite complicated without user IDs.
But the real reason would be that it's not possible to use salting to protect passwords if you don't have an user ID, which means that you would effectively not really be protecting your passwords.
Here's why. Salting requires you to know the salt that was used to generate the password hash. The process is as follows:
Locate salt using the User ID in your DB
Salt & Hash the password that was provided
Check whether this matches the password hash you have in the DB.
If you don't have an user ID, you'd need to check your password against every user in your database.
This is equivalent in complexity to checking one password is against your entire database, which is something you purposefully want to make prohibitively expensive (in time or money) by design.
One of the most important reasons why web applications don't use passwords only is that two users could have the same password.
When the password is the only factor to identify a user, user A could log in with his password and would have access to user B's account and not his own account since they use both the same password and the system needs to pick one user to log in.
Curious as to how to compare a text box string to the password the user used to authenticate themselves when they started the Microsoft Access database.
Microsoft Access version is 2003. Users authenticate themselves using Microsoft Access Jet security.
UPDATE: Per CesarGon (thank you), this is really a question of comparing hashed values; how might I replicate the hashing Microsoft Access does and compare the hashes?
In your change password form, you can execute an ado sql command:
ALTER USER user PASSWORD newpassword oldpassword
Just make sure the text entered for both passwords are not the same.
http://msdn.microsoft.com/en-us/library/bb177884.aspx
I don't think you can do that. The passwords that users use for Jet security are hashed and stored in the System.mdw database; the passwords themselves are not stored, but only a hash computed from the password. There is no (practical) way to recover the password from that hash.
Edit. You may use the Jet API to have Jet perform the validation for you. This is some sample code:
'set security database.
DBEngine.SystemDB = "C:\Temp\System.mdw"
'create a workspace.
Set wksp = DBEngine.CreateWorkspace("New", "John", "john's-password")
If the workspace is created, then the provided password was correct. If the password was incorrect, the workspace won't be created and an error will be raised.