5 ms·

> Digest access authentication is an immediate and halfway decent fix. It really is a shame that browsers have such a terrible UI for HTTP auth.

by bct 18y ago

tptacek 18y ago
Before you consider converting your own web app to HTTP auth instead of login forms, be aware of the fact that several of the top security firms will demerit your app for doing it, and that will hurt you selling to companies. I don't totally agree with this (HTTP digest auth, while silly, is still better than the crazy Javascript hashing schemes), but the logic is, it is difficult to "log out" and manage sessions with HTTP auth.
- cperciva 18y ago
  be aware of the fact that several of the top security firms will demerit your app for doing it Speaking as FreeBSD Security Officer: Several of the top security firms provide ratings which reflect the quality of their checklists more than the quality of the security in the systems they're assessing. The FreeBSD security team recently dealt with a case of "if you don't fix this, people using FreeBSD will lose marks on PCI audits" -- and our answer was "screw the auditors, this isn't a security issue and we're not going to send out a bogus security advisory just to keep some idiotic auditors happy".
  - eru 18y ago
    Care to elaborate?
    - cperciva 18y ago
      There was a recent "security issue" reported to us whereby an attacker who could specify a printf format string could cause a buffer overflow. We don't consider this to be a security issue since if you're allowing an attacker to specify a printf format string, you've got much bigger problems already -- this "issue" doesn't make things any worse.
      - tptacek 18y ago
        Note that there are operating systems that have scrubbed their format string support, and, as a result, applications with format-string vulnerabilities have not been exploitable. I'd elaborate, but I don't know the context of the finding you were dealing with. If it was, "FreeBSD needs to get rid of the %n token", the auditor was right, and you were wrong. I'd be surprised if it was that simple, though.
        cperciva 18y ago
        FreeBSD needs to get rid of the %n token It wasn't that simple; but in any event, do you seriously think that FreeBSD should stop supporting a feature which (a) people have been using for two decades, and (b) is required by POSIX? If I was going to make FreeBSD more secure by removing features, I'd start by removing the boot loader -- which would render the system utterly useless, yet very secure. If someone wants to shoot themselves in the foot by using a feature incorrectly, we're not going to stop him -- but we will do our best to make sure that the gun doesn't explode if someone looks at it oddly. (I think the X11 people called this the "tools, not policy" approach.)
        tptacek 18y ago
        Yeah that one's pretty easy to answer. Of course you should get rid of obscure printf(3) format string features, used in fewer places in your codebase than you have fingers on your right hand, if it means saving your users from a similar number of vulnerabilities. Again: unless there are two Colin Percivals working on FreeBSD, you tried to remove Hyperthreading from FreeBSD to "save" your users from a crypto timing channel attack that has never been seen in the wild. Reconcile that with standing fast on format string apocrypha of the sort uncovered by "Month of XXX Bugs" fuzzers. Are you sure you're still speaking as FreeBSD Security Officer? I may quote you on some of this in the future.
        cperciva 18y ago
        obscure printf(3) format string features, used in fewer places in your codebase than you have fingers on your right hand I just did a quick grep of /usr/src and counted 17 places where %n was used in a format string -- fairly equally split between printf and scanf. I don't know what sort of mutant you think I am, but I don't have that many fingers on my right hand. And that's not even counting all of the 3rd party code which gets run on FreeBSD (including the 18000+ programs in the ports tree) which make the perfectly reasonable assumption that FreeBSD's printf(3) conforms to POSIX requirements. you tried to remove Hyperthreading from FreeBSD No, I didn't. I turned it off by default. There's a big difference. Are you sure you're still speaking as FreeBSD Security Officer? I may quote you on some of this in the future. Here's a quote for you: As FreeBSD Security Officer, I do not believe that POSIX-mandated features should be removed in an attempt to make foot-shooting harder. The printf and scanf family of functions are dangerous, and should NEVER be called with a format string provided by a potential attacker or constructed from data provided by a potential attacker.
  - tptacek 18y ago
    First, it's interesting to see where you draw the line, Colin. As FBSD Security Officer, you also attempted to have the OS disable Hyperthreading, ostensibly to eliminate localhost timing channels. That was a change with user-perceptible impact and minimal security benefit. Second, seperate PCI auditors out from security audits (though Hacker News readers should be familiar with both). I agree with your sentiment regarding PCI auditors. (PCI, for those who don't know, is the Payment Card Industry standard you get audited against if your application accepts credit cards). Third: like it or not, when you get dinged on a report like that, you can lose a sale. "Hah-hah!", Colin says. "Screw the auditors!" But Colin, and FreeBSD at large, loses nothing from failing an audit. Want some horror stories about people who do lose?
- bct 18y ago
  What's silly about Digest?
  - tptacek 18y ago
    It's obviously less secure than SSL.
    - thaumaturgy 18y ago
      DAA isn't intended to solve the same problem as SSL. SSL also isn't always worth the cost of the certificate, depending on the information being guarded; nor is it absolutely secure [http://eprint.iacr.org/2004/111.pdf http://eprint.iacr.org/2004/111.pdf, May 2004]. I don't understand the all-or-none attitude that appears to be prevalent in the security industry. For all the discussion spent on search spaces, and maximizing attack effort, there doesn't seem to be much acceptance for "good enough" security. There appears to be this attitude that -- to use wireless security as one example -- "WEP is broken, so you might as well just run a totally open network." I see that when you say that anybody that can sniff traffic for stupid JavaScript hashes can also necessarily inject traffic to alter the negotiation between the host and the client. While in theory that's correct, in practice it ignores the difference in the number of people that know enough to execute either attack. It makes sense to say, "If you're going to do password encryption, you might as well do it right", but I don't think it follows that even a stupid JavaScript MD5 hashing scheme is as insecure as plain-text password transmission.
      - tptacek 18y ago
        The paper you linked to, which I just got around to looking at, has no bearing whatsoever on the security of SSL for password security. It was also never, so far as I can tell, published.
    - deleted 18y ago
      [deleted]

> Digest access authentication is an immediate and halfway decent fix. It really is a shame that browsers have such a terrible UI for HTTP auth.

by bct 18y ago

> Digest access authentication is an immediate and halfway decent fix. It really is a shame that browsers have such a terrible UI for HTTP auth.

tptacek 18y ago

Before you consider converting your own web app to HTTP auth instead of login forms, be aware of the fact that several of the top security firms will demerit your app for doing it, and that will hurt you selling to companies. I don't totally agree with this (HTTP digest auth, while silly, is still better than the crazy Javascript hashing schemes), but the logic is, it is difficult to "log out" and manage sessions with HTTP auth.

cperciva 18y ago
be aware of the fact that several of the top security firms will demerit your app for doing it Speaking as FreeBSD Security Officer: Several of the top security firms provide ratings which reflect the quality of their checklists more than the quality of the security in the systems they're assessing. The FreeBSD security team recently dealt with a case of "if you don't fix this, people using FreeBSD will lose marks on PCI audits" -- and our answer was "screw the auditors, this isn't a security issue and we're not going to send out a bogus security advisory just to keep some idiotic auditors happy".
- eru 18y ago
  Care to elaborate?
  - cperciva 18y ago
    There was a recent "security issue" reported to us whereby an attacker who could specify a printf format string could cause a buffer overflow. We don't consider this to be a security issue since if you're allowing an attacker to specify a printf format string, you've got much bigger problems already -- this "issue" doesn't make things any worse.
    - tptacek 18y ago
      Note that there are operating systems that have scrubbed their format string support, and, as a result, applications with format-string vulnerabilities have not been exploitable. I'd elaborate, but I don't know the context of the finding you were dealing with. If it was, "FreeBSD needs to get rid of the %n token", the auditor was right, and you were wrong. I'd be surprised if it was that simple, though.
      - cperciva 18y ago
        FreeBSD needs to get rid of the %n token It wasn't that simple; but in any event, do you seriously think that FreeBSD should stop supporting a feature which (a) people have been using for two decades, and (b) is required by POSIX? If I was going to make FreeBSD more secure by removing features, I'd start by removing the boot loader -- which would render the system utterly useless, yet very secure. If someone wants to shoot themselves in the foot by using a feature incorrectly, we're not going to stop him -- but we will do our best to make sure that the gun doesn't explode if someone looks at it oddly. (I think the X11 people called this the "tools, not policy" approach.)
        tptacek 18y ago
        Yeah that one's pretty easy to answer. Of course you should get rid of obscure printf(3) format string features, used in fewer places in your codebase than you have fingers on your right hand, if it means saving your users from a similar number of vulnerabilities. Again: unless there are two Colin Percivals working on FreeBSD, you tried to remove Hyperthreading from FreeBSD to "save" your users from a crypto timing channel attack that has never been seen in the wild. Reconcile that with standing fast on format string apocrypha of the sort uncovered by "Month of XXX Bugs" fuzzers. Are you sure you're still speaking as FreeBSD Security Officer? I may quote you on some of this in the future.
        cperciva 18y ago
        obscure printf(3) format string features, used in fewer places in your codebase than you have fingers on your right hand I just did a quick grep of /usr/src and counted 17 places where %n was used in a format string -- fairly equally split between printf and scanf. I don't know what sort of mutant you think I am, but I don't have that many fingers on my right hand. And that's not even counting all of the 3rd party code which gets run on FreeBSD (including the 18000+ programs in the ports tree) which make the perfectly reasonable assumption that FreeBSD's printf(3) conforms to POSIX requirements. you tried to remove Hyperthreading from FreeBSD No, I didn't. I turned it off by default. There's a big difference. Are you sure you're still speaking as FreeBSD Security Officer? I may quote you on some of this in the future. Here's a quote for you: As FreeBSD Security Officer, I do not believe that POSIX-mandated features should be removed in an attempt to make foot-shooting harder. The printf and scanf family of functions are dangerous, and should NEVER be called with a format string provided by a potential attacker or constructed from data provided by a potential attacker.
- tptacek 18y ago
  First, it's interesting to see where you draw the line, Colin. As FBSD Security Officer, you also attempted to have the OS disable Hyperthreading, ostensibly to eliminate localhost timing channels. That was a change with user-perceptible impact and minimal security benefit. Second, seperate PCI auditors out from security audits (though Hacker News readers should be familiar with both). I agree with your sentiment regarding PCI auditors. (PCI, for those who don't know, is the Payment Card Industry standard you get audited against if your application accepts credit cards). Third: like it or not, when you get dinged on a report like that, you can lose a sale. "Hah-hah!", Colin says. "Screw the auditors!" But Colin, and FreeBSD at large, loses nothing from failing an audit. Want some horror stories about people who do lose?
bct 18y ago
What's silly about Digest?
- tptacek 18y ago
  It's obviously less secure than SSL.
  - thaumaturgy 18y ago
    DAA isn't intended to solve the same problem as SSL. SSL also isn't always worth the cost of the certificate, depending on the information being guarded; nor is it absolutely secure [http://eprint.iacr.org/2004/111.pdf http://eprint.iacr.org/2004/111.pdf, May 2004]. I don't understand the all-or-none attitude that appears to be prevalent in the security industry. For all the discussion spent on search spaces, and maximizing attack effort, there doesn't seem to be much acceptance for "good enough" security. There appears to be this attitude that -- to use wireless security as one example -- "WEP is broken, so you might as well just run a totally open network." I see that when you say that anybody that can sniff traffic for stupid JavaScript hashes can also necessarily inject traffic to alter the negotiation between the host and the client. While in theory that's correct, in practice it ignores the difference in the number of people that know enough to execute either attack. It makes sense to say, "If you're going to do password encryption, you might as well do it right", but I don't think it follows that even a stupid JavaScript MD5 hashing scheme is as insecure as plain-text password transmission.
    - tptacek 18y ago
      The paper you linked to, which I just got around to looking at, has no bearing whatsoever on the security of SSL for password security. It was also never, so far as I can tell, published.
  - deleted 18y ago
    [deleted]