47

As outlined in the bug report, the issue is that an authentication dialog shows up on trustworthy.com, so oblivious users (and let's be honest, many users who pay attention as well) will type in their username and password, not realizing they're actually sending it to malicious.com. Combine this with a very similar looking domain (e.g. trustw0rthy.com), and ...


16

Passwords in general should be stored hashed on the server, no matter if they are transferred within some HTTP POST body as a result of a form submit or if they are transferred in the HTTP header as in Basic authentication.


12

Yes, it should be. The default backend for HTTP Basic Auth is htpasswd, and it encrypts passwords*: htpasswd encrypts passwords using either bcrypt, a version of MD5 modified for Apache, SHA1, or the system's crypt() routine. Files managed by htpasswd may contain a mixture of different encoding types of passwords; some user records may have bcrypt or MD5-...


9

I think I know what's happening with you. Actually, that's exactly what I do with the image in my "about me" section in my StackExchange profiles. It's a .php file that grabs some information about the visitor (IP address, browser type, whether the visitor made the smiley happy or not, etc.). I simply rewrote the URL to show two different images that are in ...


7

If you aren't using HTTPS then this information could easily be picked up by anyone sitting between you and your server and reused. If you are using SSL/HTTPS to encrypt the link, then you should be fine.


6

Firefox (Firefox 68.0, under Linux) doesn't store this info in Cookies and Site Data but in History. You need to go to Preferences->Privacy & Security and under the History section, click on Clear History.... Make sure the Active Logins checkbox is checked before you submit.


4

This is called a 403 phishing attack, and the only way you can prevent it is to prevent user-generated-content from containing links to external resources that are rendered on your pages, like images. Fortunately, it's not a particularly common attack, but it can be concerning, particularly if the credentials users use on your site are more likely than ...


2

ZAP supports HTTP basic authentication natively, so you wont need to use Zest in this case. If you know that an app uses basic auth then you can set that up via the API. However I recommend that you start by using the ZAP desktop as this is much easier to use when debugging issues. For specific help with this its probably quicker to ask on the ZAP User Group:...


2

The accepted answer (clearing "Active Logins" from "Clear History...") has the disadvantage that it clears all active logins, including from other sites on other browser tabs. An alternative, at least with Firefox, is to reload the page by specifying a different (or invalid) login. This can be done by adding it in front of the URL: http://...


2

Like a normal (not same-site) cookie the Authorization header for Basic Authentication is always send with a normal HTTP request when the site is accessed and credentials are known, no matter if cross-site or not. There is no way to specify a different policy for this header.


2

The credentials are not part of the DNS query so they are not visible there. The credentials are included in the encrypted part of HTTPS so that the ISP cannot see these either.


2

Another argument not mentioned (I guess) so far is the fact that many mobile devices such as smart phones do not let the user check the certificate when doing basic auth over HTTPS in the browser. That means that unlike with forms based auth you cannot bypass the basic auth popup which is a modal dialog on most mobile platforms to check the certificate ...


2

As mti2935 mentions, the Basic Auth header is automatically sent by the browser with every request. That means setting a session cookie is redundant. However, usage of HTTP Basic Auth should be discouraged, as is discussed in this answer.


1

If your variable, req.session.loggedIn is client-side controllable, then you have a gaping authentication flaw. Assuming that is the case -- you need to generate a unique session ID after successful login. When a user requests a page, you will check if the session ID is valid. It's worth noting: we want to reduce transmittance of credentials wherever ...


1

I can think of three points: You must use HTTPS, or password will be sent in plaintext. But you need HTTPS for all authentication so this is not specific to basic auth. (I wouldn't really care about the fact that the password hits the network multiple times instead of once. Either you use HTTPS, and then it is fine, or you don't, and then just sending it ...


1

Using Basic Authentication over HTTPS is considered to be secure as the main issue with Basic Authentication is that the credentials are sent over clear text. However, there are some common practices that make using Basic Authentication a bad idea. The following are some examples: Usually no request limiting is put in place - This can allow brute force ...


1

Here is a bit more context for history. Just like others said Basic Auth over TLS works well if you can live with a few limitations. Used on the client side, you probably need to deal with session management, which is rather hard with Basic Auth. On the backend, Basic Auth performs well but relies entirely on TLS for confidentiality and integrity. It is ...


Only top voted, non community-wiki answers of a minimum length are eligible