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.
Related
I recently started to make some iPhone applications using Phonegap. Due to my current knowledge of HTML, CSS and JS, it is an easy way for me to start learning and create concepts that developers can optimize later on. I stumbled accross this blog post.
Here there is a description of a simple AJAX login form. I have previously asked about the security with using AJAX as a login method and was told that posting password as an AJAX variable is risky compared to a normal page change. This is of course based on desktop web applications, and in this case it is about native phone applications. Is there also a security risk using AJAX for Phonegap Apps?
In the post, the author also mentions a method to store the password and username as local variables to make an automatic login next time they open the application. Is this safe? Storing the login details as plain text in local variables?
I took some time browsing around some websites to see how they handle login AJAX based. To my big surprise, they don't do anything but just post the login details as an array to their login server. Websites such as iCloud and Squarespace, do not do anything with the login details before posting them. Of course they have an SSL certificate on the site, but is that secure enough?
Store password is not a good solution.
I Strongly recommend using security tokens using JWT (json web token) that can be disabled without putting your password at risk. Oauth 2.0 is also good complete solution.
Communications shoud be secured at least with SSL encryption and Basic Authentication protocol to send token in every connection.
Well the main problem of this approach is that login credentials can be sniffed .
You can prevent it, with a SSL certificate for sure.
Now for the encryption part, i have come to use bcrypt (instead of mcrypt that was referred), because it provides a mechanism to slow down brute force attacks and is generally a recommended encryption algorithm. PHP has password_hash method (PHP 5 >=5.5.0) and it is extremely easy to use it !
My iOS app needs to connect to a mysql server. To accomplish this, I'd like to create a webapp that acts as the middleman between the client side apps and the server side database.
My concern is that someone can simply figure out the URL that my app uses and pass their own URL parameters - and since the webapp has no idea whether legitimate data is being sent from my iOS app vs. someone just typing in the properly crafted URL from any web browser, the system will be vulnerable.
Let's say I have a PHP function for marking a user as "verified" (after I send them an email verification code). This is pretty standard stuff, but what's stopping someone from making the same request from a web browser?
Of course, the user that the app uses to make database queries will have limited privileges, so the rest of the database won't be at risk. However, even having users activating their accounts from outside the app would be catastrophic.
The option that I thought of was using https so that even if the user figures out the URL, they won't know the password and wouldn't be able to sniff it since it's encrypted from start to finish. Unfortunately, https can be expensive for a poor college student, so I'd like an alternative if one exists.
As stated before, there is no 100 % security possible. But there are several solutions that put together give great security.
Https
As you point out, this is an important part , as it prevents sniffing.
Sessions
Use sessions and don't allow any request without a valid session ( except the first, that must authenticate the app ).
Fingerprint
Check the user agent and set extra http headers, to get a fingerprint unique to your app. ( Still someone could sniff, but he needed to use curl or similar. )
Obfuscate requests
Build your query string and apply a hash function. The server needs to implement the reverse function. ?43adbf764Fz instead of ?a=1&b=2
Encrypt
This goes a step further. Use a shared secret to calculate a hash. On the server repeat the same. This is already strong security. In order to break, one needs to reverse engineer your app.
Use unique shared secret
You say it is a app for iOS. Upon installation a unique token is generated by iOS. Have your app register this token with your server. Like this you have a strong shared secret unique to each installation, and there would be no way to hack your web app.
First of all, a better question would be is this possible? My gut instinct is that it isn't entirely, but there may be some clever ways. Even if they just act as a deterrent, make it slightly harder for some one to hack, or even make it easier for me to detect suspicious activity.
Basically, I'm building a web service using PHP for my C#.NET program to connect to. Among other things, one of the most important purpose the web service serves is verifying license data. The program sends the licence key entered by the user to be checked, and if it is valid the web service will return the Name of the person who purchased the licence key so that the program knows to activate itself.
I am fully aware that there is no perfect anti-piracy scheme and that is my software will be cracked if people want it bad enough. However, I do not believe that there isn't anything I can do to make it very hard for people to crack my software.
I do have an SSL certificate so the program will be communicating with the web service using HTTPS, however that's the only security I have at the moment. I have thought about
Using long and obscure names so that the functions are hard to guess
Using MD5 to disguise the functions
Adding a username and password
Checking the User-Agent
etc.
However, I have read that there are applications available to simply extract strings from programs, which would render those measures completely ineffective. Still, I don't know how technical users have to be to use those applications. Is it still worth adding some of these measures to stop casual piracy? Which measures are the better ones and what will be the most effective?
Thanks in advance
You can distribute your C# application with a certificate bundled and sign your requests with the certificate. The server can then verify if the request was signed by your application and reject any other request.
Edit: Whoops, I only now understood that you want to secure you application even when in the hands of a malicious user. This, I don't think is possible. A hacker can decompile, scan the memory, read and decode files, etc and your certificate will be available in there if you distribute it with the application. An alternative would be to distribute an external security token (hardware device or flash storage) which will need to be plugged-in to the client computer. The token holds the certificate, keys or cyphers used to sign/encrypt your requests and it therefore doesn't stay with the application.
Your server-side SSL certificate will only guarantee that the communication channel is secure and the server is not lying about his identity. It doesn't guarantee anything about the client connecting. To also be sure that the client is identified, you need to use a form of client certificate that your server recognises.
We've been developing a web application (PHP, using the Yii PHP framework) that is going to be used for data entry. The clients will be users from both the LAN and WAN (many of the remote clients will be behind a proxy, reaching our network using one IP address with NAT). What we basically want is to guarantee the validity of data in the way that no malicious user alters it.
Is there a way to programmatically identify each client in a unique way, so that I can guarantee (at least at some good percent) that no malicious remote user will connect? We were thinking of gathering the MAC addresses of all remote users and using a (non-web) client that generates a hash string that the user will input in the web application and then proceed if this authentication scheme passes. As I said, using other non-web applications for the remote client is an option.
Is such a solution as the one I describe above viable? Should we see other solutions, like maybe a VPN?
A VPN is a typical solution to the problem of locking out everyone except those you've explicitly given access --- basically you're rejecting all connections to the site that aren't authenticated in your local network or vpn. That way you dont have to write any funky logic for your actual web application.
I think this is an ideal solution because it allows the application to be maintainable in the future when other developers step in... furthermore it will require less of your developers and will ultimately keep costs down.
Normal user authentication is generally OK, but if you have higher security needs you can provide clients X.509 certificates to install in their browser. VPN is of course an option but you just move authentication problem from website to network vpn.
What you are looking for are the SSH-Key pairs:
https://help.ubuntu.com/community/SSH/OpenSSH/Keys
There are much more ressources on this, the theory in brief:
Each client creates a pair of unique keys, a private and public one. The public goes onto your server, the private stays with him. Then the client uses the key to authenticate. The server calculates a valid public key from it and checks if you have such a key in your system. If a pair is found - authentication was successful. (I never used this so far for Web authentification)
Additionally you could use OTP (One Time Password) technology. Since it is normally bound on per-account basis it will be very secure:
https://github.com/lelag/otphp
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