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 !
Related
I have a scenario, we have an PHP based website through which the users login using credentials stored in a database. Now we have another SPA website with .NET CORE as API layer.We don't have an option of having a central authentication server like Azure. If I want to let the users of SPA to access the website since they have already been authenticated in PHP, What should I do? Can PHP generate a JWT to pass it to API? How does that JWT then gets to SPA and how do I validate it? Please be kind as I am a newbie to website programming.
Json Web Tokens are a very specific format for a Bearer token. There are protocols like OpenID Connect that provide more structure around the login and trust process but at their heart, JWTs are just BASE64 encoded json with a verification hash.
You can roll your own SSO with JWT but as with everything in security, rolling your own comes with significant risks of making a bone head mistake and compromising your security. So research research and research some more if you take this route.
I did a very similar thing but stayed purely in the .net world. I used a .net library to build the JWT (https://learn.microsoft.com/en-us/previous-versions/visualstudio/dn464181(v%3Dvs.114)) and ASP.NET Core Identity to handle verification of the JWT (https://www.nuget.org/packages/Microsoft.AspNetCore.Authentication.JwtBearer) so I didn't write the code to actually generate the JWT. There is also only SSL connections made between the servers so some of the risk of the token getting sniffed is mitigated.
There are libraries for PHP to generate JWT or you could stand up your own JWT token provider in any language.
There also may be the possiblility of finding an OpenId Connect provider that could hook into your existing database. Identity Server 4 is one for .net but there may be one to be found in the PHP world. This introduces some overhead but does solve the problem of not having the ability to have a third party OpenId Connect provider.
Its not too terrible but security is one place where you wnat to be absolutely sure you get things right.
Authenticating from another server is SSO. There are lots of ways you could do this, but SSO protocols like OpenID Connect and SAML are specifically designed for what you're trying to do.
However, those protocols are anything but simple. You should try to see if you can find existing libraries to have your PHP application act as an Identity Provider (IdP), and your SPA to act as a Service Provider (SP) using the same protocol.
An idea that's a stretch - you didn't explain WHY you can't use a central authentication server. You might consider something like Keycloak (there are other options - that's the one I've used), which you can self-host, and can serve as either an IdP or an SP using OpenID-Connect or SAML 2.0.
You definitely shouldn't build this from scratch on your own (unless this is a hobby project). Authentication is full of security pitfalls that can trip up even the most experienced programmers.
So far I've learned that Firebase's Security Rules play an important role in keeping our data secure regardless of the platform we're using. But I found that the Web + JavaScript combo and other implementations might be purely exposed to risk if developers structure them in such a way that firebase credentials can easily be seen on the client scripts.
Thankfully, Firebase has support for REST API's in a variety of languages which can mitigate the risk, somehow. For this purpose, I took a look at Kreait's Firebase Admin SDK for PHP for a Web data administration portal that I am creating.
Here is a simple demo for the Firebase Admin SDK for PHP.
The following good points that I found for this library are:
Firebase credentials are written on the backend scripts, they are hidden on the front-facing clients
Queries and database operations and implementation are hidden from the clients
Has backend support for Firebase real-time database, authentication and user management
My questions are:
Are my firebase credentials really secure, will it not be broadcasted to the world when using this approach as opposed to just putting it in a plain javascript file?
Are there other ways to make the firebase credentials and data more secure (aside from encrypting data, hiding them on backend scripts thru REST implementation and properly-structured security rules)?
Thank you in advance for your comments and suggestions.
There's no security risk in exposing information like the API Key or Project ID in your front-facing application (see https://firebase.google.com/docs/web/setup, it's the recommended procedure) - your web application can only do what the currently authenticated user is allowed to do.
There's, of course, the risk that the security rules are not well defined, but that's the case with a backend application as well - a stupid example: when you create a passwordless account on a server, anyone can log in with that account ^^.
Concerning the Admin SDKs: their primary purpose is to perform administrative and/or backend tasks. If you shift your business logic from the client (= Browser) to the backend, you will lose a lot of the functionality that the web libraries provide out of the box. You will have to re-implement functionality, pass data from the frontend to the backend and back... I don't think this would be worth the hassle.
So, my recommendation is: don't worry about the config snippet that is visible when looking at the JS code in the browser and test your security rules extensively, preferably with an automated test suite, and you should be just fine.
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.
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.