So, I'm working with a really old system which uses a person's mysql database credentials to authenticate to a web site (the database was originally only accessed from the command line, but is now accessed from a php frontend). Because of some internal reasons (and to preserve the user's history), I have to leave the old authentication intact. I've been charged with adding openid authentication to this system. Somehow I need to be able to retrieve a users mysql username and password upon logging into the site through openid (using the Zend framework, by the way). I've thought of simply requiring registration at the first login, where the user must provide their mysql credentials, but I'd rather not store the password plain text.
I've also considered blanking everyone's mysql passwords, and just setting the user's mysql username manually (rather than having the user provide this, since they could provide any username).
This is turning into a security nightmare. Does anyone have any suggestions for alternatives?
This is running on a Linux server, by the way. Also, I can't use mysql pluggable authentication because the mysql version is 5.0 (pluggable authentication requires mysql 5.5), and no, I can't update it.
MySQL passwords are hashed, so you will not be able to extract the plaintext password from MySQL. I guess that leaves you with two options, both of which you considered in your question:
The first time the user logs in with OpenID, replace the user's password in MySQL with a new password that is known to your application. Your application uses that password to log into the account of any user who is using OpenID.
Con: A user who uses OpenID cannot go back to using direct MySQL authentication because they don't know their own password anymore. Not even using MySQL command line tools. That implies that users, having once used OpenID, must use OpenID forevermore.
When the user registers to use OpenID, your application momorizes their password.
Con: Your application keeps a list of plaintext passwords
Con: Your application breaks when the user changes their MySQL password by themselves.
Third option:
For each user who uses OpenID, create a second MySQL user for them, which has a generic password. Copy all of the permissions assigned to the normal account to this "shadow" account.
Con: the normal user and shadow user must be kept in sync, so that if some MySQL permissions are added or revoked from one, they should also be added or revoked from the other one at the same time. Forgetting do to this will result in a mess.
Given that you can't sensibly perform openid authentication for the CLI client (even with PAM), I would stringly recommend you do not try to reconcile the openid users with the mysql users - just add a generic user that anyone authenticated via openid can use to connect to the database.
Related
I need to capture client's passwords for a third party account on a web form.
I have a dedicated server and SSL installed.
My plan was to have the user submit the form to the PHP processing script.
The PHP processing script will encrypt the password using aes-256-ctr and then save it to a randomly generated filename in a write only folder on the server (below the public_html folder).
I will get an alert when a new one is added and will immediately scp the encrypted file to my local machine and delete it from the server.
I can then decrypt the file locally.
How secure is this?
No that is not a secure method of securing the passwords. Security is not gained by keeping the method secret.
If you must save the actual passwords here is one method to reduce the vulnerability:
Consider using an HSM for encryption the passwords, they are not cheap.
Store the passwords on a separate server not connected to the Internet.
Have only a connection to the server that needs the passwords.
Use a simple API to set, request and delete the passwords.
Use 2-factor admin authentication and limit the admins to no more than two trusted people.
Use serial numbered tokens for the 2-factor authentication, not email or text messaging, that way you have positive control of the number of admins.
Use rate-limiting on the server and provide alerting if the rate is exceeded.
Hire a cryptographic SME to vet the design and implementation.
Use 2-factor admin authentication on the Internet connected server.
Buy liability insurance.
One major security issue is that many of the users will re-use passwords with other systems. Your system will be breached and user information and passwords will be stolen and you will not know that has happened. These user credentials will be used to gain access to users information on other systems. Your liability is potentially huge.
Warning: I am not a SME on this topic.
I have a html5 Web View Android application which uses php website . How do I enable the use of website only for people who have purchased the application .I was thinking of a combination of getting the users android device id in combination with php mysql generated id and preventing php site access by using a php library that checks if client is a mobile phone .Perhaps even Google application licensing - I don't know how easy is to get around this by recompiling of application ?Maybe even a good way to hide the url inside Android application.
Where do users purchase the application? How do they get access to your website?
If they purchase your app from Google Play, then you should use some form of authentication/authorization that forces them to sign into your website and establish credentials there and on the device.
Please don't use the device id. That's not particularly friendly, and it opens up a security hole. In addition, it's an inconvenience to users who upgrade (or lose) a device.
A username and password should be sufficient security for most situations. If it isn't in your case, then you could also consider establishing an encrypted key on the device after the user first logs into your site. The key could be based on various values that the user would have difficulty reproducing on a different device.
One must consider the tradeoff of securing against undesired access versus the effort involved. How likely is it that users will give away their username and passwords to allow others to use your site? If you secure something too much, nobody will use it.
I need to make an Android Application that has a connection to a remote php server to fetch and save data.
This app needs to work offline and have a login system based on the same data that the server has.
Should I have the same passwords on the Server and on the Smartphone? Or should I have 2 different system logins (one password for the app and other for the server login)?
Users would be confused by two logins. It will never work. The important thing is- never save passwords locally. Save the hash of their password instead, and compare the hashws. Otherwise anyone who gains access to their phone can get their password.
Also, if you allow them to change the password on the server you'll need some mechanism to push that change back to the phone.
I have 2 sites:
SITE A - an asp.net site
SITE B - a php site
We have all the user information in an asp.net site (which is actually a Kentico site).
Now, there is a business requirement that users should be able to log-in with the same credentials in Site B. Ideally, we would need that users who log-in Site A, and navigate to Site B, the authentication would be automatic.
Is there a way to achieve this form of authentication. Or is it not possible?
This is not an authentication problem, but an authorization one. Once you have authenticated your user, in whichever way you want, with whichever technology you want, you probably will grant them some sort of token that you will then use to grant authorization to the different resources in your sites.
In your case you have two different technologies, which only means that you won't be able to use the out of the box asp.net or php session management, but all you need to do is have a common place to check that the session tokens are valid, they belong to a legitimate user and that user has permissions to access this resource.
If the above is trivial, sorry, maybe your question is more oriented to the sites being in two different domains, and therefore not being able to use a domain cookie to store the session information. is that the case?
The canonical solution to this is to use a protocol like OpenID. OpenID allows a website to ask a user to authenticate themselves using a different site, and then honour those credentials; using a protocol called "attribute Exchange", the authentication provider can provide additional data about the user.
OpenID is how StackExchange manages to log you in with your Google account (or whatever you're using), and how sites in the SO network recognize your identity without you logging in everywhere.
The benefit for OpenID is that it's a widely used protocol, so it's likely to be highly secure and well-tested; you don't risk weaving your own solution and accidentally exposing your users to security risks. It's well-documented, and widely supported.
There's an OpenID framework for .Net which allows you to create your own OpenID provider; it appears Kentico supports OpenID as an authentication mechanism. There are several OpenID libraries for PHP (Google is your friend here).
Exactly how you implement this depends on how your Kentico authentication works right now, but in principle it should be fairly easy to glue the Kentico user database to an OpenID provider you write; getting Kentico to use that for authentication appears to be a configuration setting. You'd have to re-write the PHP site to use OpenID; again, not clear how that currently works, but I can't imagine it would be harder than any other solution you might try.
I had a similar issue on a .net platform where I didn't have the option to put them on one subdomain. In that case you could pass the username and a token (that signified the user was already authenticated by site B) and perhaps the encrypted password to re-authenticate against an external DB, then redirect them to the site. In my case I needed to do this as I was redirecting to the corresponding site CMS for site admins.
I have written an API for my latest project. Written entirely in PHP, it currently supports web and mobile applications. We would like to expand that to desktop applications as well, but I'm not exactly sure how to enable to user to login through the desktop application, while still protecting the username and password from said application.
There are many brilliant developers on Stackoverflow, so shoot me some brilliant answers!
The application will be developed by 3rd parties, so I want to ensure they aren't able to store usernames and passwords
If the application has to send usernames and passwords, then it has to be able to have access to them, so don't use them inside the application at all.
Use OAuth. This is the solution used by quite a lot of large organisations, including Twitter.
There are many possibilities. What comes to mind:
Issue a Certificate signed by your CA and verify later, eg via the OpenSSL lib or Apache.
Use Public key encryption, eg via GnuPG lib, and grant access only to known pub keys.
Use any kind of Token based authentication or any other two factor authentication..
Just give them another set of API credentials (Secret Key, API Key)
its a desktop application, it has full access to the users keyboard and memory. if the application should have a login form where end users type in their usernames and passwords, the application has this data by definition.
the only solution would be to distribute the login-application yourself which does some sort of toked based authentication and provide the 3rd party applications a login token via your api.
oauth and other singe-sign-on systems on the web usually use an iframe or popup which comes from the system-to-login-to itself. no 3rd party website or application should be allowed to provide this input fields.