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,
Related
I'm putting together an android client (and possibly in the future iOS, web portal, etc) and php mysql server. Server side I am currently using the PHPass library to hash and salt the incoming passwords.
Should I make the client send plain text passwords over HTTPS/SSL or should the client do some form of hashing first. For example should every client simply sha1 (or some other algorithm) every outgoing password?
Most websites will send the password plain-text over an encrypted connection SSL/HTTPS. Hashing the password client-side can be done, but the advantage is small and often client-side languages (JavaScrypt) are slow so you can calculate less rounds in the same time, what weakens the hash. In every case the server must calculate a hash as well to be safe.
The advantage is small, because if an attacker can do a ManInTheMiddle attack, he can also modify/remove the script (JS) which does the hashing. Only an encrypted connection with SSL/HTTPS can protect against a MITM attack, so you need SSL anyway.
In your case with an app, it looks slightly different. Because the user first has to install your software, there is no need to send a script to the client, so a MITM cannot modify this script. Moreover, the app can calculate the hash relatively fast (if it can run native code) and therefore can do enough rounds on client-side.
This is what i would do:
For easiness send the password plain-text over an encrypted SSL/HTTPS connection and calculate the slow BCrypt hash server side, as you do now.
Only if the load on the server grows too heavy, then you can move the calculation of the slow BCrypt hash to the client app. Still use HTTPS to send the hash, and then calculate an additional fast hash (e.g. SHA-256) on the server. This is more complex, because you have to exchange and store the salt separately.
Another disadvantage of hashing passwords on the client is that you cannot change the hashing algorithm or iteration count without also having to update your clients.
For JavaScript clients that is not a problem, but you cannot easily guarantee that your users will be on the most recent version of your native client.
So I would stick with sending plain passwords over HTTPS.
In the early days of HTTP, there was Digest authorization as an alternative to Basic authorization. Instead of the HTTP header
Authorization: Basic <credentials>
you would use
Authorization: Digest <credentials>
It was an algorithm that increased security by avoiding the password being sent as cleartext. This was in the days when TLS/SSL came at a performance cost so this was an alternative. However the algorithm meant the password had to be stored as cleartext on the server. So you had a choice of sending the password cleartext but having a hash on the server, or sending the password as a hash but having cleartext on the server.
Unsurprisingly, as martinstoeckli said in his answer, now that TLS/SSL is widespread and easy to implement, HTTPS is used instead. You can store the password as a hash on the server but not expose the plaintext password if it is intercepted by a MITM attacker.
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 !
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
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.
I'm developing a small website where I'm going to allow user to create accounts but I'm quite clueless when it comes to safety around authorizations.
I have built my project in PHP with codeigniter and found a library (Tank Auth) that could handle authorization for me. It stores password in a safe way but I'm still worried about the part when the user sends their password to my server.
One easy way to do it would be to send the password in a post-request but I would guess that it's quite easy to sniff such a password. Should I do something with the password on the client side before sending it to my server? And is there any good javascript libraries for this?
As others have said SSL is the prefered way to go.
David Wotever metioned hashing - there's a detailled discussion of the process here
An alternative approach would be to rely exclusively on external providers to handle your authentication for you - openid being the most obvious candidate.
HTH
C.
You can muck around with client-side hashing, but in general POSTing the credentials over a secure (HTTPS) connection is considered sufficient.
This still leaves the possibility of MITM attacks… But performing an MITM attack on an SSL connection isn't entirely trivial, so it's probably not an attack vector you need to be too concerned with.
You say that SSL is too expensive for you, but most hosts offer it for free. The expensive part is getting a private IP address and formal certificate.
However, you could create your own certificate which would mean that all the details are still transmitted securely, it's just your identity that can't be guaranteed. As mentioned by David Wolever, MITM attacks are much harder to do; and anyway are probably not a concern for a hobby site.
Once (if) your site evolves out of being a hobby then you can invest in an assured certificate then.
Authentication via SSL is probably the easiest and most secure way.
If you encrypt it in something like rot13 etc.. it's easily undoable.
As mentioned also, you would want to make sure that your website's security isn't relying on Javascript as that can easily be turned off.
Any other operations performed on the client side can easily be broken.