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.
Related
I’ll be changing my website URL soon (eg example.net to example.com) and since my website is quite old and there is many users that saved their passwords in browser’s built-in password manager I’m afraid that they won’t be able to login with autofill after I change the website address.
I know most of browsers will let they obtain their passwords on settings but is there any way to let browser know that the new url is owned by the website as the other url? Probably 301 redirect will not warn browser to change the saved password url to the new one, right?
I tried to find anything related to this but seems like there’s not a pattern approach to the problem. Perhaps I’ll need to alert the users about the change some days before…
I’ve tried to search for a pattern way to solve the problem but couldn’t find any.
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.
One of customers have reported that they can see the password being transferred as clear text, they probably tried tool like a fiddler to capture the HTTP request/response. So my question is is it possible using fiddler or any other tool is it possible for someone to monitor the http traffic on that local computer at the moment the user entered the password and clicked to login ?
If the user is accessing the website without using SSL (i.e. by going to "http://" instead of "https://"), then it is possible to see all of the traffic between the website and the browser, and not only on the local computer but also on the network that the computer is connected to.
If the user is accessing the website via HTTPS, Fiddler is able to act as a proxy and decrypt the traffic between the browser and the server by using a special SSL certificate (thanks to #user18044 for clarification in the comments below).
In your case Fiddler is NOT accessing browser memory directly to get to the password in clear text.
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.
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.