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).
Related
I am currently developing a RESTful API server, and I am choosing between using ID and password or using a token to authenticate a user.
Let me, explain my situation first. I need to include static authentication information to my library to communicate between a client and my server or provide it to a partnership company to communicate between their server and my server. And when I was researching other services which are in a similar situation as us, they are using token now (for example, Bugfender is using a token to specify a user).
However, what I think is that using ID and PW and using the token are the same or using ID and PW is better because there are two factors to compare it is correct or incorrect.
Is there any reason why other services are using a token?
Which one is better as a security perspective or is there a better way to do this?
I think, if you are going go use on your client fixed username/password, or some fixed token, then the level of the security is the same.
Username and password is not considered as multi-factor authentication. Multi factor means that you are authenticating someone by more than one of the factors:
What you know. This can be the combination of username and password, or some special token.
What you have. Might be some hardware that generates an additional one time password - Google authenticator app on your telephone, or SMS with OTP received with some time expiration.
What you are. This is for example your fingerprint or retina of the eye.
Where you are. This can be the IP address of the origin if it is applicable for your setup.
How you behave. What is your normal way of using the service.
etc.
Maybe not needed to mention that both - the token and the username/password combination have to be carried in an encrypted requests (I believe you are using HTTPS). Otherwise the client's identity can be stolen.
How are you going to provide the credentials to your client library? I thnk this is the most tricky part. If those credentials are saved as a configuration (or worse hard coded) on their server, is that storage secure enough? Who is going to have access to it. Can you avoid it?
What would happen if your partner company realize that the username/password is compromised? Can they change it easily themselves? Or how fast you can revoke the permissions of stolen credentials?
My advice is also to keep audit logs on your server, recording the activity of the client requests. Remember also the GDPR if you work with Europe servers, check for similar regulations in your country based on what you are going to audit log.
In case the credentials (ID and password) and the token are being transferred the same way (say: by a header in a REST request) over a TLS secured channel, the only difference lies in the entropy of the password VS entropy of the token. Since it is something for you to decide in both cases, there is no real difference from the security perspective.
NOTE: I don't count the ID as a secret, as it usually is something far easier to guess than a secret should be.
I'd go for a solution that is easier to implement and manage.
IMHO this would be HTTP basic authentication, as you usually get full support from your framework/web server with little danger of making security mistakes in authentication logic. You know, friends don't let friends write their own auth. ;)
I want to do the following
User signs up to IOS app and provides username and password
Make a server call and store password in server database
When user logs in in the future, retrieve that password and check against the password that the user entered.
How can I do this in the most secure way possible? I was thinking of encrypting the password when storing in the db. When the user logsin, use the same encryption algorithm and compare against the db encrypted password.
NEVER ever store user credentials in encrypted (reversible) form. Currently best known way for checking user credentials is slow salted hash
for what and why please read https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
However, don’t try to invent your own algorithm for repeated hashing.
Choose one of these three well-known ones: PBKDF2, bcrypt or scrypt.
As already commented you may outsource the user authentication to some reliable service (google, fb, aws cognito, ibm appid,...)
Have you tried looking into databases? I know that Firebase has an authentication component of their database for ios development, and you might want to try to look into it or other databases. Check out firebase at: https://firebase.google.com/
I need to store a sensible info in a database (clients passwords). Is there a common practice? The information should be accessible by various users. Think about service company that should make maintenance of clients systems.
I'm thinking about using AES encryption. All the information is encrypted with the same main key. For every user this main key is encrypted with the user's password used as the key and stored separately. During login and authentication the main key is decrypted and saved in a session. Later the key is used to decrypt clients info. Is it a good practice?
Thanks
P.S.: Yes, I know that it's better not to use passwords, but it's not me to decide the way to access client's servers.
I am developing an app which uses several API services, the API requires that I provide username and password for API transactions, unfortunately no API token :-( in-order to automate I need to store username passwords somewhere, preferably database, I cannot use hashing because I need to send the username/password to authenticate and process API request, hence I am wondering how to go about it.
If I use Zend\Crypt to encrypt and store the password in database and decrypt whenever required, would this be enough for security? is there something else I must consider?
Looking for pointers.
PS: I am using ZendFramework2 with Doctrine/MySQL for the app.
Usually you would use a token mechanism (like OAuth). If that's not possible, one would use TLS/SSL client authentication.
However, if you rely on plain passwords (on the application-level, I still guess the username/password tupel is transmitted over a secure connection!) and you want to store them encrypted, you have to think of a meaningful mechanism to get an encryption key for your scenario. Just generating an encryption key and storing it on the same machine in plain does not provide more security.
Without more information on your scenario it is hard to make a suitable suggestion.
Few sites I've come across using either Google, Facebook or Twitter connect for login. Still they are asking for new password creation.
Ex: http://setapp.me/
Why user need to setup another password when the user is using OpenID/Facebook/Twitter connect?
One need I can think of: if the user disconnects the app from any of the above OAuth/OpenId connect services providers (Google/FB/Twitter/...), then as an alternative way for the user to login - as a best practice.
What they're doing is an incremental step towards federation, but not what I'd describe as a best practice. For apps that aren't ready to fully embrace relying on another service for identity it is still sometimes helpful to connect with identity providers to speed up the sign-up process. In other words, just as a mechanism for pre-populating the signup form.
However, if using it for sign-on, then having a local password is one more potential vulnerability. The reality is the vast majority of users just re-use passwords across sites. That password is only as secure as the weakest application that stores it. If one app is compromised and email & passwords recovered, attackers know that a good percentage of those are valid logins elsewhere.
Best thing to do when federating with Google/Facebook/etc is to not ask the user for their password at all. Trust the major identity providers to keep account information & credentials secure rather than take on that responsibility yourself and deal with the fallout if your app is compromised.
Lots of good reading here if you're up for it: https://docs.google.com/a/google.com/document/pub?id=1O7jyQLb7dW6EnJrFsWZDyh0Yq0aFJU5UJ4i5QzYlTjU#h.moajj1qnb85l