In my wordpress local site generating an error that is given below that i need to fix. so please suggest me what should i do?
error is Password fields present on an insecure (http://) page. This is a security risk that allows user login credentials to be stolen.
Related
I wrote a PHP application which requires a login. This application is private so no new users can register. First I used sessions to identify the users but it lead to problems on tablets because they lost their sessions. I think this is because of energy saving operations.
Now I changed my application to generate a random security token. So the authentication is as the follows:
Log in
Generate random security token and save it to disk
Redirect the browser to http://myhost/site?id=[securitytoken]
On the server side I check if the file exists - if yes, user is authenticated
Everything is now working perfectly I am just thinking about security concerns. It is no problem if the user sees the security token. Is it somehow possible to find out the token when I use GET? I am using SSL.
I tried to change the expiration times and cookie lifetimes. On a normal computer it is working as it should. On the table it is also working IF it does not go into standby (meaning the screen gets black). If the screen gets black, the session expires very soon.
There is no vulnerability inherent to using GET instead of, for example, POST from a network perspective.
The only caveat you should keep in mind is that a GET request is more likely to be stored on the client (e.g. browser history) in a way you might not intend. For these reasons, I typically use POST requests for authentication.
The problem you are attempting to solve sounds remarkably similar to "remember me" cookies. The linked blog post might be helpful in mitigating the security risks involved in designing token-base authentication systems.
Generally, web apps are confined to using localStorage and cannot silently read/write to files in the background. How are you accomplishing this?
When you say you're using SSL, do you really mean TLS or do you mean SSL version 3? If SSLv3, I would advise updating your stack and webserver configuration to support current best standards. TLSv1.2 with ECDHE and AES-GCM + SHA2 or ChaCha20-Poly1305 are ideal.
GET is more vulnerable than POST as it can be transmitted and stored:
In server logs by default.
In corporate proxy logs.
In the referer header if your page uses external resources or links to external domains.
In your example you have a http URL (this could be a typo though as you said you are using SSL). Make sure you are using https URLs to protect this data in transit.
This approach could also be vulnerable to Session Fixation as an attacker could get the user to visit a URL containing, or redirecting to, the same session ID as the attacker. When the victim logs in, the shared session will be authenticated meaning the attacker is now also logged in. To protect against this, refresh the session ID upon login and logout.
Cookies are often the preferred approach for session handling as they are harder to attack in the above scenarios.
The issue with in URL variables in the get form means that for one : users can easily modify it (by accident or not) and they stay even when the link is copied somewhere.
If you send someone your link/someone gets your link with the id variable in it,is that a security risk to you?
I got the following error message in my Firebug console.
Password fields present on an insecure (http://) page. This is a
security risk that allows user login credentials ,to be stolen.
What is the reason for this error?
If this is regarding http and https, what do I have to do to convert http:// to https://?
I am working on my local machine and I can not install SSL here. I can not log to the system due to this error.
I change the password field to text filed, but the same thing is happening.
Please help me to solve this without installing SSL to work on my local machine.
First of all, this is not error. It's not even a warning. It's a notice.
Secondly, this in no way affect your forms, POSTs and logging.
Lastly, nothing even requires SSL and HTTPS for user logins. Even many e-commerce websites don't use SSL, because they don't need to. All you need to know that if you create account on non-SSL page, is that password must be stron and unique (you shouldn't use the same password anywhere else).
Note:
SSL actually is required when you process critical users' data like credit cards' numbers. You can usually observe it on some e-commerce shops, which don't use SSL at all, but when you go to any of payment methods, you always end up with SSL.
it's okay to have this error in development mode, but you should use https when you want to publish your website because login should be done through https because that prevent some hacker attacks like session hijacking.
I am working on a website at the moment, and I have coded the login boxes to login to another page (eg. login box on www.domain.com to login to subdomain.domain.com)
Subdomain uses HTTPS and at the moment domain doesn't.
My question is, should I hash the password and send it to subdomain to avoid using plaintext or should I require the domain to use HTTPS as well when using a POST request?
Hashing the password client side doesn't stop attackers sniffing "the thing you send to the server" and replicating it. Don't do that.
Using SSL encrypts communication between client and server. Do this.
Serving a form to the user without using SSL makes it vulnerable to man-in-the-middle attacks (e.g. JavaScript could be added that would steal the password as it was being entered and before the form was submitted securely). Don't do that.
When people want to login, redirect them to the secure site before asking them to enter their credentials.
My web application is receiving increased attention and I need to provide additional security to protect my customers.
The biggest problem as I see it is that the user login data is sent as plain text. My goal with this question is to discern if the following approach is an improvement or not.
In extension I will need to get dedicated servers for my service. This proposed solution is temporary until then.
I am currently running my web application on a shared hosting web server which only provides SSL through their own domain.
http://mydomain.com
is equivalent to
https://mydomain-com.secureserver.com
My thought is to have:
http://mydomain.com/login.php
...in which an iframe opens a page from the secure server, something like this:
<iframe src="http://mydomain-com.secureserver.com/ssllogin.php"></iframe>
I authenticate the user in
ssllogin.php with the (hashed+(per
user based-randomly salted))
passwords from the database.
After proper session regeneration set a session verifying the authentication.
This session is then somehow transferred and verified on http://mydomain.com
Is this approach even possible to achieve? Would this be an improvement of my login security or just move the "point of interception of password" for the attacker to another instance?
All feedback is appreciated.
You don't need an iframe. Just make the action of the login form to point to https://yourdomain.com/login.php . In there you may check if user & password are correct, and then redirect again to plain http.
BUT this is not 100% secure. The fact that you are sending the user & password via https may prevent an attacker or sniffer to get that. But if you later revert to plain http, it is possible to this attacker/sniffer to hijack the session of any logged in user sniffing the session cookies of this user.
If you want more security (not 100%, but more than this previous option), stay always in https, for all resources (css, js, images too, not just your php/html files), and even serve the login page via https.
For some reasoning of these points, see firesheep (for the hijacking session problems) or the recent tunisian gov't attack on tunisian facebook/yahoo/gmail users (for serving even the login page via https).
edit: sorry, I misread your question. If the SSL domain is different than the not-ssl domain, you may have problems, as the session cookie only will work against the same domain or subdomains. So, if you do the login and send the session cookie from https://yourdomain.secure-server.com, it will only be sent back by the browser to yourdomain.secure-server.com (or *.secure-server.com if you will), but not to yourdomain.com. I think it's possible to make a wildcard cookie valid for all *.com subdomains, but it's better not to do this (do you want your users' session cookie be sent to evil.com ?)
If I'm trying to secure my login method. From an unsecured server the user enters their login credentials into a standard HTML form, which is POSTing to a script on a secure server. This script does all the necessary login functions, and sends the user back to the insecure server.
My question boils down to this: Is the login information encrypted through SSL before it is POSTed to the secure server, therefore preventing any man-in-the-middle packet sniffing. Or is everything still being sent in the clear, and the form doing the POSTing has to be hosted on the secure server as well?
Thanks
If you post over SSL then the information will travel over the wire encrypted and will prevent packet sniffing.
Is it possible to also host the actual login form page on the secure server? That way when the user goes to log in to your site they can see that the login page is secured and they can be confident that their login information will be posted using SSL. Otherwise, the user is presented with an unencrypted page where they are asked to enter their credentials and they have no way (short of viewing the HTML source) to know if their information will be submitted using SSL.
Another question I have is how does the unsecured server "know" that the user has actually been authenticated with the secure server? If it is being done using cookies or a browser redirect (both of which will be unencrypted since the user is being sent back to the unsecured server) then that information will be easily read by anyone on the wire. This could be a security hole where the user's credentials are actually secure but your application/web site is not protected from being accessed by individuals who have actually not authenticated themselves.