My question is simple regarding password security..
As a web application developer using PHP for example, I may design a html form that accepts a username and password and post them to the webserver using the POST method..
My question is:
1- When a user enters a password for this form on a web browser, does this web browser send the password over the network as plaintext and thus insecurely?
2-isn't it possible that the web browser saves all passwords and sends them to the third party that design the web browser?
Thank you in advance
Yes, unless you're using https, which encrypts everything sent between the server and the client.
Sure, but you could use a network sniffer to verify that the browser sends no information to third party servers.
It's sent unencrypted (though possibly obfuscated) if you're using HTTP, or encrypted if you're using HTTPS.
Any mainstream web browser won't do that, no. It would be discovered within seconds of the browser being released. However, it's possible for such a leak to occur by other means, for example:
o A rogue browser plugin
o A rogue proxy on the user's network (if you're using HTTP)
o A keylogger on the user's machine
Related
We use client side form validation and we manage web page access using things like Authguard in Angular.
But how secure is this, can't clients directly manipulate the java scripts from their side and access any web page that is already loaded and send any unvalidated data to the server?
Is it only useful for the benign clients and is not useful against malicious clients? Or is there more to it?
Is there any other way to make the code of client side more secure and control what clients do even after the they have loaded all the web pages?
It's only useful for user experience, not for security.
In fact, you can't even assume that the client is a web browser, or that it's even running your code. You can't secure the server side from the client side, unless you have a way to vet each and every client device (e.g. with perimeter security).
Even after a user has logged in, that doesn't necessarily count as a vetted device, since it's possible to steal authentication cookies.
...unless you properly secure the server.
I have a web site that accomplishes user login via ajax call over https. Obviously the request contains the password. Playing around with Firefox developer tools I noticed that I can inspect any network requests coming from my page including the request body ... and there is my password. I assume the request is being encrypted since its over https but the developer tools still shows it as plain text. Am I missing something? If a user logs in on a public machine and forgets to logout anyone can use developer tools to grab their password. Thanks in advance for any help you can provide.
-Mike
Everything is functioning by design – there's nothing wrong.
The browser's dev tools are intended to allow the user to inspect everything that's happening in the page – without that functionality, they'd be pretty useless. The dev tools' network tab shows HTTP data before it is encrypted.
In the public machine scenario, remember that the dev tools only show network requests that happened after the tools were opened, so an attacker can't just open the dev tools after the user leaves with your page up and see the plaintext auth request.
I can inspect any network requests coming from my page including the request body
No you can't - that's not yet network traffic - that's a HTTP datagram which is then passed through the SSL layer before it gets to the TCP stack.
If a user logs in on a public machine and forgets to logout anyone can use developer tools to grab their password
No, because unless the page developer is doing really stupid things, the browser does not store the information - you could only see it because your browser was configured to intercept the information and store it temporarily. But having said that there are a large number of things which can cause the browser to store authentication tokens - auto complete and password managers for a start (the latter vary greatly in the quality of their implementation, the former has little protection against disclosure). Authentication tokens should never be sent as GET parameters hence should not be visilible from the browser history.
I wish to use my Stellaris LM3S8962 microcontroller as a bridge between internet and a bunch of sensors. I will be using Zigbee nodes for communication from the sensors to the microcontroller. I have been able to use the lwIP TCP/IP stack (for LM3S8962) to access HTML pages stored in the controller's flash.
Now, I want to add a secure login system for the same. What I basically want is that - when I enter the IP of the controller in the browser, it should prompt me for a username and a password. I want to make this system as secure as possible using the lwIP TCP/IP stack.
FYI, the stack does not support PHP or any other scripts. CGI feature (in C) is supported but I don't know how to implement the security part. Please guide.
There are basically two ways you could implement user authentication over HTTP on your platform:
"classic" Basic HTTP authentication (see RFC2616 for exact specification),
a login form, creating a session ID, and returning that to the browser, to be stored either in a cookie, or in the URL.
Basic HTTP authentication works by you inserting a check into your web page serving routine, to see if there is an Authorization HTTP header. If there is, you should decode it (see the RFC), and check the specified username/password. If the credentials are ok, then proceed with the web page serving. If the credentials are incorrect, or in case there is no Authorization header, you should return a 401 error code. The browser will then prompt the user for the credentials. This solution is rather simple, and you'll get the browser login dialog, not a nice HTML page. Also, the microcontroller will have to check the credentials for every page request.
Authentication via a login form works by your server maintaining a list of properly authenticated user sessions (probably in memory), and checking the request against this list. Upon loggin in, a unique, random ID should be generated for that session, and the session data should be entered into your list. The new session ID should be returned to the browser to be included in upcoming HTTP requests. You may choose the session ID to be put into a browser cookie, or you can embed it into the URL, as a URL parameter (?id=xxxxx). The URL parameter is embedded by sending a 302 Redirection response to the browser with the new URL. If you want the cookie solution, you can send the response to the login request with a Set-Cookie HTTP response header. In the login form solution, the actual credentials (username/password) are only checked once, at login. After that, only the session ID is checked against the list of active sessions. The session ID has to be extracted from the requests for every web page serving (from the URL, or from the Cookie HTTP header). Also, you'll have to implement some kind of session timeout, both as a security measure, and to put bounds to the size of the list of active sessions.
Now comes the harder part: in both solutions, the username/password travels in some requests (in every request for the Basic HTTP authentication, and in the login page POST for the login form solution), and can be extracted from the network traffic. Also, information neccessary to hijack the session is present in every request in both solutions. If this is a problem (the system works on a freely accessible LAN segment, or over network links beyond your control), you'll probably need SSL to hide these sensitive data. How to get a reasonable SSL implementation for your platform, that's another question.
In our login page we enter username password and then submit the form. The password goes to the server where it is crypted using some algorithm and then saved to database. But when it is posted to the server it can be seen in firebug post data. So how is it secure i have seen the similiar implementation in other cases as well. Can not it be trapped in between the time it is taken from client to server.
Firebug can see the password because it is acting as a proxy on your client (one of the two endpoints of the communications path). SSL/TLS (https) encrypts the data in transit between the two endpoints (think of it as a protected tunnel where the only way to see the real data inside is to be at one of the endpoints). Since Firebug runs on the client, it has access to the endpoint, where the data is not encrypted. Think of a tunnel you can pass data into that will be protected in transit; Firebug sits at the entrance to that tunnel so it can see everything that goes in (and comes out).
At a minimum, sending passwords (and any other sensitive data) should be done over SSL/TLS, to prevent someone/something not on an endpoint of the tunnel from seeing the data. Ideally, you will want to run everything over https to prevent session hijacking attacks (you can read all about that in the Wikipedia summary). Any site not encrypting at least the exchange of credentials (passwords, etc) is not following industry best-practices and should be considered an insecure implementation.
yes, you are right. If data is sent in clear text to the server, it can be captured in Transit. Hence, always use HTTPS connection.
I'm writing a firefox addon that logs certain user activity and displays some statistics on a webpage.
When the page is opened, the page sends an event to the addon.
The addon adds data to the page and sends an event back, and the page refreshes the statistics.
Now how do I ensure that the extension only puts the (sensitive) data on the right page and not some other malicious one?
Thanks
V
SSL. Unless you're doing something weird, the only route of attack is man in the middle.
The addon will have to authenticate with the server, probably with a username/password provided by the user. The server side needs to control what events, and from what user that it can accept from the client side. Also note that all authentication should be done over SSL to prevent session hijacking.