I understand htpasswd is pretty secure if done through SSL. Question:
I visit directory "mysite.com/protected/" (https) and log in via htaccess/htpasswd. In the same browser I open up a new tab to "mysite.com/unprotected/" (http).
Is the user/pass transmitted in the second request, or only when accessing the /protected/ directory?
The user's name and password will be sent with every HTTP request under the protected directory. The user will only be asked (usually) on the first try until you close and reopen the browser.
Here is a good overview.
Related
I know that man in the middle (mitm) can be in passive mode : forward, or active mode : modify trafic and forward...
But Can mitm open a page, in firefox for example, to connect on a website where i was logged.
Is this possible ?
Yes, as you say, the man-in-the-middle can modify the traffic. So when you request a page, he/she can easily return an HTTP 302 to another page, or insert some JavaScript to set the document.location.href of your document.
If your traffic is encrypted using https, this is not possible.
This is a question about the functionality of htaccess password remembering. When i visit a htaccess protected website and enter my password i can visit the site without entering the password again until i change my ip address. I first thought my browser would save the password but that can't be the case because the browser shouldn't care about ip changing, right? The only option left would be that the webserver saves my ip address. But then would whoever would get my ip address after me be able to access the site without entering the password, that wouldn't be save.
Do you know who remembers my htaccess password?
The authentication method is known as Basic Auth.
As you can read from the article, the Browser has to send the credentials with EVERY request, so there is no session or similar whatsoever on the server-side.
The browser will 'remember' for a while (differs from browser to browser). I suppose it's either a coincidence that you get "logged off" whenever you change your IP, or your browser detects the connection loss and clears all cached credentials.
tl;dr: the browser
It is the browser.
But the browser is sensitive to changes.
If I open Fiddler and log into 50 different websites from my browser... in a perfect world, would Fiddler ever be able to show me my password in plain text?
If it does, is that a security problem with the website?
If not, how can you tell if a website is sending data unencrypted? Wireshark?
Did you enable HTTPS decryption in Fiddler? If so, then Fiddler is doing something that no web based attacker can easily do, and seeing your password shouldn't worry you.
If you didn't enable HTTPS decryption, or you see your password in a session whose protocol is HTTP, then the website is not sending your password securely, and anyone able to sniff your HTTP traffic could see your password.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
We recently changed our login to use HTTPS, and we are experiencing issues with the login.
After the login, the user is redirected to an unencrypted (HTTP) page. When it reaches this page, the site checks if the user is logged in. It creates a new session and it appears that the user is not logged in, and thus our user is redirected to the login page. If the user logs in again, it will work.
The cookies are not set as https-only, but it seems like they don't work on http pages.
Does anyone know why this might be happening.
Edit:
I should have mentioned that the page that displays the login is on a different URL. (There is a login page from the machine running the tomcat instance, but the marketing site is on a wordpress install and uses a different domain).
I can't use the HTTP request first method to set the cookie, because the default Internet Explorer settings prevent the session cookie from being saved.
We have this problem with our app. We wanted a similar behavior of logging in via https, then redirecting to an http page.
The issue is that when Tomcat creates the session under https, it creates a secure cookie which can't be read in http. Note that this keeps getting filed as a bug in Tomcat and getting marked as "not a bug".
The solution we ended up is based on the message in this forum
http://forum.java.sun.com/thread.jspa?threadID=197150&start=0
Quoting from the forum thread: "One way to maintain the session in Tomcat, when the session cookie is getting created in SSL mode is to trick the browser by creating the non-secure cookie, when the secure cookie is getting created." This is accomplished via a filter that wraps the request and overrides request.getSession(). It's worked very well for us.
As a side note, redirecting from an https to http page will pop up a warning message in some versions of Internet Explorer "You are about to be redirected to a connection that is not secure." The only way we found to avoid this is to have the redirection be done with a meta refresh tag. Specifically, return a blank page from the original https request with a meta tag that refreshes to an http page. This avoids the warning message at the expense of making the code slightly more convoluted.
(I just noticed some of the advice here is a repeat of an earlier answer -- I apologize, but will post anyways since it is from direct experience).
Edit: I see in your comments you have two domains, which complicates the use of cookies. Can you use a proxy or web server such as Apache to present just one domain to the end users?
When using https tomcat establishes the jsessionid through a secure cookie, which cannot be transmitted through a non-secure connection. So when you fall back to http the session is lost.
The workaround (which I haven't done it myself) seems to be establishing the session through a http request before redirecting to https, and then setting a filter in the HttpRequestWrapper to plug into the nonsecure cookie.
I don't know much about this, but here are a couple of references:
http://forums.sun.com/thread.jspa?threadID=197150
http://tp.its.yale.edu/pipermail/cas/2006-March/002356.html
If you've verified the secure-only flag is off, and that the first cookie is being dropped correctly - I would guess that that there may be a path issue which is preventing the cookie from being presented again.
Question in title, but I'll elaborate.
Say I have a form on a non-secure page, but I don't want the data that the user is posting to my web server to make sense to anyone who might intercept it. Do I need to serve the form securely or simply post the form to a secure URL?
By serving the form unsecured, you allow a man-in-the-middle to alter your form's POST destination, letting an attacker harvest login information. But MITM attacks are not common, so you're probably fine serving the form unsecured.
No. The post data is what counts. You can serve the login page over regular HTTP and post to HTTPS. You want the username and password to be encrypted, so we send that to the server over HTTPS we are golden.
No you don't need to serve the form on HTTPS. You need to post it on HTTPS though. For example the not infamous Twitter login box is served on HTTP. What matters is to establish a secure connection when sending the username and password to the server.