I've looked around and haven't found the basic Password requirements, if any, for PostgreSQL. That is, chars allowed, length, casing, etc...
Will someone please point me to these, if they exist?
Thanks
The best you can do on the server is to use the passwordcheck contrib module. You probably have to hack it up to fix your needs.
However, that won't be able to enforce password policies in general, because the server never sees the clear text password unless you change it with
ALTER ROLE xy PASSWORD 'clear_text';
which is not recommended. Changing the password with tools like psql's \password command will hash the password before it is sent to the server, so the server cannot enforce any password rules.
You would have to check the password on the client, but naturally the client is not under your control, unless you restrict severely what people can do on their machines (and people usually find ways around such restrictions).
So there is really no way to do what you want.
What you can do is enable cracklib in the passwordcheck module and this way test the hashed passwords against a dictionary.
For good security, use something like LDAP or Kerberos authentication and implement your password policy there.
Related
I have a couple of functions (login, reset-password) implemented as functions. Is it possible to make sure that these functions are not logged by either postgres itself or any extensions that may be installed?
You cannot absolutely eliminate the possibility of logging parameters. Your log files should only be readable by people you really trust (generally the same people who have superuser on the database). Also, you might consider reading the salt and hash from the database and doing the rehashing and comparison in the app server, rather than sending the password in the clear to the database.
I am creating a password generator for Postgresql users. I cannot find out anything in the official docs, regarding the rules for the password quality.
Numerous articles and questions circle around passwordcheck module
But it is not enabled by default, why?
And is there default rule for password strength in Postgre?
It is easy to enable the passwordcheck module.
The main reason why it is not enabled by default is its limited usefulness: it is only effective for passwords sent to the server in clear text, which is bad security practice to begin with. If you use a more secure method like psql's \password, the server never sees the clear text password and consequently cannot check it.
The deep reason why there are no more advanced password checks is that the PostgreSQL community deems passwords in the database second-rate security. For serious security requirements, use central identity management and authenticate with Kerberos or one of the other authentication methods. Then have your password strength checks in the identity management system, which specializes in this area.
Somebody told me it could be possible if i use pgcrypto pgp_pub_decrypt() function with my queries the logs will reveal the secret key used to decrypt my data
SELECT pgp_pub_decrypt(string_to_decrypt, private_key)
I can not check that because i dont have access to the logs, but if this is true, from my point of view this should be considered as a security issue. Is this true?
Yes, this is true. Assuming you are logging statements.
It is also probably visible in pg_stat_activity to a superuser who is looking at the right moment.
Of course, a superuser could also install an extension to secretly log just crypto-related function calls, that's the nature of having superuser access.
If you don't control the server your database is running on and don't trust the people who do, then you shouldn't store sensitive information in it.
I would like to add simple password protection in an iPhone App that I am working on. I will probably use crypt() to store the password in my database which in in CoreData / sqlite format.
I think I have a pretty good understanding of how to create and store the password, but in case the user forgets their password, I would like to add a password recovery ability
This is the part that I'm struggling with in iOS. I want everything to be local, so I can't think of a way to use a link to reset a password.
I had thought about emailing the password, but in iOS there is no way to send emails without the person holding the device seeing the contents of the email.
The only way that I can think of is to have one or two "backup passwords" which is basically the answer to a question of the user's choice (or maybe even just storing a reminder question along with the password).
Neither of these are really that secure, although the data being protected in my app is not that critical, so I'm not looking for the most robust solution (just a decent solution that is not too hard to implement, not too inconvenient for the user, and not too hard for a hacker to break).
Suggestions are greatly appreciated.
Thanks,
Ron
Instead of recovering a password, you can prompt to reset a password using criteria that is set up when they initially create their account -- such as mothers maiden name, last-4, etc. This way, you don't need to worry about decrypting a password or sending it to the user. Once they answer enough security questions correctly, they are prompted to reset their password. You can store this data encrypted locally. You'll never need to send a password to the user.
The easiest way is probably to make "password protection" optional and display a warning ("if you forget your password, your data may be irrecoverable!").
It's not going to be that secure: The data is probably going to appear unencrypted in a phone backup, unless you encrypt it yourself. The upshot is that determined users can ask you for help, and you can write them a tool that digs through the unencrypted backup and resets the password.
Avoid the built-in crypt(), which is probably DES-based and limited to 8 ASCII characters. Storing the plaintext password in the keychain is not too terrible an option.
Here is what I got for a webapp login scheme.
Present in database would be two salts and hmac(hmac(password, salt1), salt2).
When the user go on the login page, he gets salt1.
If he has javascript activated, instead of sending the plaintext password, it would send hmac(password, salt1).
If he does not have javascript, the plaintext password is sent.
So, on the serverside, when getting a login request, we'd first check what is sent (passwordSent) against hmac(passwordSent, salt2). If it does not work, we'd try hmac(hmac(passwordSent, salt1), salt2).
Someone getting access to the database should not be able to login with the password hashes and I don't think (but I may be wrong) that multiples hmacs diminish the hash resistance.
Do any good crypto expert see any obvious error I may have done ?
This looks a little like security through obscurity, what is the point of using javascript to hash the password on the client side if you still accept plain text password from the client?
You didn't mention if this was over https, if you aren't using https then you may as well have no passwords at all. If you aren't running https then any MITM can see the salt you are sending as well as the javascript used to hash the original password so you have nothing gained.
As for your concern about the possibility of hmac collisions between two salts, that is probably very unlikely (depending on your hash algorithm) and how secure you keep your salt values. Even with MD5 that has had some collision attacks discovered and has a set of rainbow tables, you will be ok if you keep your salt very very safe.
Please, everybody, please stop trying
to implement custom crypto systems
unless you have a background in
cryptography. You will screw it up.
--Aaronaught
Well said!
Sounds pretty far-fetched to me. If the objective of this is to prevent a "man-in-the-middle" attack by virtue of the plaintext password being sent over HTTP, then use SSL.
Hashing on the client side accomplishes nothing; unless the salt is actually a nonce/OTP, and not stored in the database, then a man in the middle can simply look at the hash sent by the original client and pass that along to the server. The server won't know the difference.
If this is supposed to make it harder to crack if someone gets hold of the database, it won't. If the hashing function is cheap, like MD5, this won't be any more difficult to crack than one salt and one hash (in fact it's actually weaker, since hashing is a lossy function). And if you use a strong hashing function like bcrypt, it's already good enough.
Please, everybody, please stop trying to implement custom crypto systems unless you have a background in cryptography. You will screw it up.
Probably obvious to you already, but you're effectively letting people log in with two different passwords in that setup.
If you want to give people the option of sending their passwords with encryption, I wouldn't tie that to anything strictly client-side, and just force HTTPS, as Harley already implied.
You might want to look at HTTP Digest authentication. That is a standardized protocol which avoid clear text password in any case.