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.
Related
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.
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.
i'm developing a website with videos. i do not have any transactions in my site. i have a login system.
Do you think i require ssl for the login system? i've even integrated facebook, so mostly users would login with their facebook account.
Is there any alternative for ssl for websites like mine?
Anything you pass over the Internet without using SSL/TLS (or an equivalent system to encrypt/protect the confidentiality of the information you are passing) must be assumed to be completely compromised and visible to anyone. In your case, that would include usernames, passwords, and session tokens, which could allow an attacker to learn your UN/PW combinations, so they could impersonate users for the long term, and session tokens so they could act as a logged in user.
Do you need to protect this? Absolutely a risk decision. What is the sensitive level of your data? What would be the consequences if this compromise happened? What would your users think if their usernames and passwords were to be made available to the world? As users tend to reuse passwords among websites, then there would be some damage to your site's reputation (and your reputation) should this happen.
The same thing can happen with your Facebook-based login. This uses OAuth, which is just a bearer token sent from the client to your server. If this is sent outside of an SSL/TLS tunnel, it has to be assumed to be compromised and, based on how bearer tokens work, anyone who can see the token and reuse it and act as the user.
Basically, SSL/TLS is cheap, both in terms of the cost of a certificate from a respected and trusted CA and server power/latency. If you have a user base of any significant size, then it most likely a very easy decision to use SSL/TLS.
I would seriously consider using a 3rd party OpenID or OAuth provider as an authentication system. There are many considerations for handling a login. Often users are put at risk by custom login systems that use weak hash functions to store the password. A good example is the Gawker leak which used DES for password storage. Pretty terrifying stuff, especially when you think that this can be avoided entirely.
Obviously you need SSL to transmit a username and password over the network. But really the user is authenticated to your application using a cookie value or session token. This is the real method of authentication and why OWASP a9 requires that this value is never spilled over an insecure channel.
If your website is worth anything at all, then use SSL to protect your user's sessions. If your website is useless and no one cares about having an account, then why build it?
Many people use the same logins on different sites, so to prevent eavesdropping, it is recommendable to use ssl.
If it is the price you are worried about and you do not do any financial transactions on your site, you can try to get a free certificate: https://www.startssl.com/?app=1
I'm building a website that will require registration and login.
Since I'm new to web developing, i was thinkink if sending unencrypted passwords to the server is an option.
Or, what you would reccomand me, since I don't know nothing about cryptography?
Edit: http://pastebin.com/nYcazcZq
If your website is just for testing or for use within the intranet, it's not that big of a deal.
If not, I highly suggest you use SSL.
If you can't afford the certificate, at least give your users the option to :
login with OpenID (as most OpenID providers offer SSL for authentification) ;
login using Digest Authentication (which doesn't send the passwords in clear over the network).
If you mean sending from browser to your server, then you need to use https/ssl to encrypt the connection, not the password itself. If on the other hand you're talking about storing passwords plaintext, then yes, that's bad as well. You should hash it with a strong salt (per user is best) and a slow algorithm.
This answer goes into more detail about sending passwords over SSL : Sending passwords over the web
You can use PHP's crypt for hashing : http://php.net/manual/en/function.crypt.php
Keep in mind that even when your service doesn't have any kind of valuable payload, it is guaranteed that many of your users will use the same password with it that they use with something more valuable, which means a breach or an easily-intercepted password on your end is capable of causing harm. Even if this is bad practice on the user's part, it's an unavoidable fact of life, so there is really no circumstance under which it is responsible to be blasé about user credentials with a publicly-accessible service. Please use SSL/https or OpenID (or another externally-hosted login management scheme, even Facebook: how to use facebook for user login on my website?) and if you are the password holder, please don't save them in the db as plaintext.
It is never good to send password unencrypted. For a serious web site you should encrypt the traffic between the browser and server using https. You do that by purchasing a certificate that you install on the web server.
never send raw critical data on net,using ssl is best solution i think,also you can use javascript encryptor to encrypt password in client side and decrypt in server,
We have the following:
iPhone native app, with login form that posts to:
A php script on remote web server which checks against MySQL user table.
For security, would it be best practice to use some two-way encryption to encrypt every request? including this initial login? otherwise the user and pass will simple be passed to the web app in the clear?
I suppose https would take care of it automatically...
It would be very wise to use SSL or TLS (the protocols that HTTPS uses) to communicate with the server. You could likely get this set up rather easily on a *nix or Windows server using OpenSSL. If you're on a shared host, they likely have an option to purchase an SSL certificate that's valid for a given period of time. This is a fairly trivial process and usually requires about a week (average) with most hosts to get set up.
It should also be noted that while it is never a bad idea to encrypt the login process, it will not make your system more secure "over all" if you have a login from the web that is not secured. For instance, if you secure communication with mobile devices, but not with desktops or laptops, your security may be for nigh. The security of your application is only as strong as its weakest link, so securing your entire application (for all platforms) is very important.
Also, keep in mind that a user's login credentials are only as valuable as the data or resources that they protect: if you encrypt the login information, it is also a good idea to encrypt the rest of the application as well. Wireless sniffing technology could easily steal session data, private user information, or other sensitive data. Securing the entire user session--rather than just the login procedure--is in your users' best interest.
Hope this helps!
Using https is probably the way to go. It's what it was designed for.