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
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 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.
This is the paragraph on OpenID security from Wikipedia. Are there any new updates about this, or any comments?
Security and phishing
Some observers have suggested that
OpenID has security weaknesses and may
prove vulnerable to phishing
attacks.[26][27][28] For example, a
malicious relying party may forward
the end-user to a bogus identity
provider authentication page asking
that end-user to input their
credentials. On completion of this,
the malicious party (who in this case
also control the bogus authentication
page) could then have access to the
end-user's account with the identity
provider, and as such then use that
end-user’s OpenID to log into other
services.
In an attempt to combat possible
phishing attacks some OpenID providers
mandate that the end-user needs to be
authenticated with them prior to an
attempt to authenticate with the
relying party.[29] This relies on the
end-user knowing the policy of the
identity provider. In December 2008,
the OpenID Foundation approved version
1.0 of the Provider Authentication Policy Extension (PAPE), which
"enables Relying Parties to request
that OpenID Providers employ specified
authentication policies when
authenticating users and for OpenID
Providers to inform the Relying
Parties which policies were actually
used."[30] Regardless, this issue
remains a significant additional
vector for man-in-the-middle phishing
attacks.
Other security issues identified with
OpenID involve lack of privacy and
failure to address the trust
problem.[31]
This phishing attack still holds. If I (as a phisherman) sets up a page, I can link to my self-made (copied) Google login page and claim it's the real one. I don't even need to implement OpenID, I can just say that I do.
So yes, this attack is still very much possible. The solution is to educate computer users: they should check the domain name, make sure the login page uses SSL and that the SSL certificate is for the correct domain.
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.