How to encrypt SALTEDHASHED password (used by Weblogic) in java?
I need to be able to hash passwords in exactly the same way as WebLogic's authenticator does. Preferably without using WebLogic's library.
30 minutes later..
I've read some documentation and if I don't know the value of the salt I can't encrypt the password in the same way of weblogic.
So, the new question is:
where weblogic stores the value of the salt? It's unique for each password or it associated one to one?
Thanks
Where does weblogic stores the value of the salt? It's unique for each password or it associated one to one?
The value of the salt is stored in SerializedSystemIni.dat, the domain's password salt file. The salt is unique for each encrypted password. You should use weblogic.security.Encrypt...
Related
Does anyone know how PageKit CMS stores the admin password? I've installed it, created the account and then the password is wrong. In the database the password is hashed so I have to decrypt it or create another one using the same cryptography method.
NB: The reset password link is useless as I don't have mailing on this server.
The password is:
$2y$10$74yJFPijNzIA0ZJY4Ggy5eCRzRMhaCuj2Xw2S8fvd1yE9zZrxRU0y
and it's supposed to be "testtest".
The "password" looks like bcrypt format and that is a hash not encryption. The difference is that a hash is one-way, that is non reversible. The only choices are to run a password cracking program but the chances of success are really bad, update the password hash if possible or re-install.
How do I encrypt this field before storing it in the database?
password = fields.Char(string="Password", required=True)
Do I use auth_crypt?
How do I store (encrypt) and retrieve (decrypt) this field? Do I need to use computed fields?
Essentially you should not store encrypted passwords because they can be decrypted when an attacker obtains access to the server.
Instead you should iterate over an HMAC with a random salt for about 100ms, (the salt needs to be saved with the hash). Better to use functiions designed to do this such as password_hash, PBKDF2, bcrypt, etc. The point is to make the attacker spend a lot of time finding passwords by brute force.
See OWASP (Open Web Application Security Project) Password Storage Cheat Sheet.
Yes, use odoo official encrypt module. after 8.0 onward odoo default encrypt password.
new field: password_crypt which store encoded protected password.
Use official way of pick password field in model file
and proper xml widget for form view.
How to reset user's password via direct SQL for Odoo
I have a simple webapp which users login to access to a third party API that also require their personal credential in plain text username and password (no OAuth or anything). What's a proper, safe-ish, and straightforward way to store these third-party passwords so I can decrypt them to plain text when needed and minimise leakage of these passwords?
I'm thinking of just hardcoding GPG keys in to encrypt in webapp for storage and decrypt from another machine behind firewall when needed.
I don't think this is a GPG-specific problem. You could think of a scheme like the following (no need for public key crypto):
Generate a random password to encrypt the plaintext credentials you want to protect
Derive a key to protect this random password from the user's password
Encrypt the password from step 1 with the password from step 2
Now you can access the protected credentials after the user has logged in (since you know the password the user entered). When the user changes his password, you only have to re-encrypt the key from step 1 (in case you use this key in multiple places; so you can't miss one).
For step 2, you should use some (slow) key derivation function like PBKDF2. This makes sure that in case of a security breach, a simple dictionary attack on the encrypted credentials is not possible.
I'm trying to set a cookie so that user can be automatically logged in.
I do not want to query DB for session string when authenticating cookies (basically I need to do that whenever most of my APIs are called, I want to make it faster)
the solution I found is to set a hash in the cookie and try to decrypt it when authenticating, if decryption is successful then log user in.
I am wondering what hashing method should I use? Do I just use a constant salt in my program and hash the userName with that salt, store the hashed userName and original userName in cookie, and try to match userName with decrypted hash upon authentication?
Since I am not familiar with hashing functions, can anyone kindly provide some suggestions on how should I do it in Java?
I recommend you to use an unique token key generated for each session. For example, if a client once logged in from a computer, this token will be valid until the password is changed. Expiring a cookie is not completely secure...
You can also use session variable for a simple authentication. Once you set a session variable for an user, every time this user sends a request with this session id; your session variable will be reached for just this session id. Most of the platforms can also use DB for storing these variables for you.
Two approaches:
1) Create your own authentication framework. In this case I recommend to put in a cookie an encrypted value of a username (I strongly not recommend to use hashing; also please do not put the user password value). For encryption please use AES-256 encryption with BouncyCastle:
256bit AES/CBC/PKCS5Padding with Bouncy Castle
If your framework success to decrypt the cookie – the user is authenticated. If your framework cannot decrypt the cookie or the user is not exist - the user is not authenticated.
2) Please consider to use the Spring Security framework:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
It is the great framework and solves a lot of authentication / authorization problems.
Your problem is solved by the “RememberMe” feature:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#ns-remember-me
Best regards,
Michael
I don't come from Java background, but your hash key should never be something exposed.
For example:- In your case UserName is key and one of the fellow developers who knows what mechanism you are using can break it down because name is something very common and known.
Don't know what the best way is but I have used UserID(GUID) which is not visible in UI.
I'm trying to secure a website that is being moved to a public server soon. I've just finished adding the password hashing functions to all of my login scripts. I'm using FormsAuthentication.HashPasswordForStoringInConfigFile(pw, method) to do so. I have a question about the process I'm using and whether or not it's secure for a web server:
Password is sent in plain text over HTTPS to the server
The server looks in the Users table to find the user's Salt (several random characters) and their hashed and salted stored password
The plain text password is appended with the Salt
The new string is hashed using the above function
The newly hashed version is compared to the stored version
If equal, login is allowed
If not equal, the login attempt is logged in Session variables, up to 3 times before locking out the user's machine from accessing the login page until an admin verifies IP address and unlocks.
Does this look about right? I just don't see how the salt is effective in this method... Anyway, all I've done is add a salt and hash. Is this considered Encryption? Or am I missing a step? I remember reading that hashing algorithms like SHA1 and MD5 are not encyption algorithms, so what else needs to be done?
That is correct. The salt is used to prevent rainbow table attacks where a dictionary of common works hashed with MD5 is used to try to gain entry. Using the salt ensures that even if they had an MD5 hash of the word, it wouldn't work because they don't know the salt.
The MD5 algorithm is a 1 way hash algorithm, and not an encryption value. The difference is, once you've hashed the value, there is no way to get back to the original value. Encryption allows you to decrypt the data and get back the original value. So you are correct, they are not the same, and your passwords are not encrypted, they are hashed. This means that if someone forgets their password, you cannot send it to them. You have to provide a way for them to reset their password instead. This also means that anyone with access to the database would not have access to raw passwords. Which is good because a lot of people use the same password everywhere, and if you had access to a large list of usernames and passwords, someone could decide to start trying to log into bank / credit card websites.
What you are doing is a recommended practice.
You shouldn't be storing the retry count in the session - an attacker could simply discard their session cookie after each attempt, allowing them to retry as many times as they wish. Instead, store it against the user record.