[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Jess Sightler updated AS7-4646: ------------------------------- Issue Type: Feature Request (was: Bug) Labels: security (was: ) Git Pull Request: (was: https://github.com/jbossas/jboss-as/pull/2139) Description: Many clients have security requirements that disallow HTTP Basic authentication. HTTP Digest is also disallowed due to the requirement to store plaintext passwords on the server. HTTP Form based authentication would provide a much smoother experience for users and comply with client requirements. (was: Original code is: String referrer = responseHeaders.getFirst("Referrer"); But the HTTP Referer header is actually spelled "Referer". Pull request with fix is here: https://github.com/jbossas/jboss-as/pull/2139 ) Component/s: Console (was: Domain Management) Steps to Reproduce: (was: Mod_proxy requests from a client using HTTPS (but with the proxy requests over HTTP).) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Jess Sightler commented on AS7-4646: ------------------------------------ DoD Security Requirements: http://iase.disa.mil/stigs/a-z.html http://iase.disa.mil/stigs/downloads/zip/app_services_checklist_v1r1-1-20... See Sec3A, Requirement APS0140: "Only DIGEST, FORM, and CLIENT-CERT types can be used when setup and configured properly:" I don't really know why "DIGEST" is listed as acceptible (as a practical matter it isn't, due to other security restrictions). Technically, it doesn't have to be FORM based, but this will be a significant blocker to AS/EAP deployment within government installations otherwise. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-4646: ----------------------------------- Why exactly is DIGEST non compliant? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Jess Sightler commented on AS7-4646: ------------------------------------ @Darran: Thanks for the clarification, but this still leaves several problems with Digest: 1. Current implementations use MD5. MD5 is not FIPS compliant, and therefore cannot be used for password storage in our environment 2. The LDAP server uses SSHA, and HTTP Digest is incompatible with this 3. Storing the hash, even with a modified realm, still suffers from weak salt. From the RFC: http://tools.ietf.org/html/rfc2617#section-4.13 "The security implications of this are that if this password file is compromised, then an attacker gains immediate access to documents on the server using this realm. Unlike, say a standard UNIX password file, this information need not be decrypted in order to access documents in the server realm associated with this file. On the other hand, decryption, or more likely a brute force attack, would be necessary to obtain the user's password. This is the reason that the realm is part of the digested data stored in the password file. It means that if one Digest authentication password file is compromised, it does not automatically compromise others with the same username and password (though it does expose them to brute force attack)." IMO, DIGEST is actually worse than BASIC for our purposes, but BASIC is explicitly prohibited. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse commented on AS7-4646: --------------------------------------- Anyway two options are going to be open to you: - 1 - Define the users within the actual realm (see schema) - for passwords use a vault expression and store passwords in the vault. 2 - We are just adding a pluggble store mechanism so implement your own plug-in that uses whatever backing store you deem appropriate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Jason Greene edited comment on AS7-4646 at 4/27/12 10:44 AM: ------------------------------------------------------------- You just described the principle of digest. The whole point is that you never send a password, or anything that can be used as one over the wire. Someone can record all your traffic, and they can't do much with it. That is the tradeoff. You basically choose, secure your storage, or secure the wire. You can't have both. Usually the storage point is far easier to secure than every network intermediary you could possibly have traffic on, in particular if its a public facing internet connection that crosses untrusted networks. You are certainly more vulnerable in that a recovered digest database gives an attacker immediate access to all users on the same realm. This is an identical problem to having a keystore. Someone steals your keys and its game over (until you revoke them). As to this FIPS SHA1 over MD5 requirement, it would be nice if browsers were updated to support SHA DIGEST, however the known MD5 weaknesses require some knowledge of the plaintext, and DIGEST doesn't have that property, so the advantages aren't that significant. Using SSL greatly reduces the weakness of passing passwords in the clear over the wire, so using FORM or BASIC starts to make more sense, and allows you to have strong storage security. It is certainly the most flexible configuration. However, BASIC is no less secure than FORM though, so whoever came up with that rule has no idea what they are talking about. In fact FORM has some ugly weaknesses that BASIC does not, namely the potential to hijack session tokens without having to even care which user owns it. Also our management interface isn't just a browser application, it supports usage from REST-like HTTP client applications, and FORM just doesn't make sense for those. This makes me wonder how on earth could any form of password scheme would survive these security standards, since they all use BASIC? If we did a javascript login, it would look like form but would still be stateless, we would be either using BASIC or DIGEST headers from the javascript code. The funny thing about BASIC being disallowed, is I could use a different auth header, I could call it "NOTBASIC", or maybe I could even call it "FORM". Under the hood its the same as every other plain text transmission method. You are sending the password over the wire. was (Author: jason.greene): You just described the principle of digest. The whole point is that you never send a password, or anything that can be used as one over the wire. Someone can record all your traffic, and they That is the tradeoff. You basically choose, secure your storage, or secure the wire. You can't have both. Usually the storage point is far easier to secure than every network intermediary you could possibly have traffic on, in particular if its a public facing internet connection that crosses untrusted networks. You are certainly more vulnerable in that a recovered digest database gives an attacker immediate access to all users on the same realm. This is an identical problem to having a keystore. Someone steals your keys and its game over (until you revoke them). As to this FIPS SHA1 over MD5 requirement, it would be nice if browsers were updated to support SHA DIGEST, however the known MD5 weaknesses require some knowledge of the plaintext, and DIGEST doesn't have that property, so the advantages aren't that significant. Using SSL greatly reduces the weakness of passing passwords in the clear over the wire, so using FORM or BASIC starts to make more sense, and allows you to have strong storage security. It is certainly the most flexible configuration. However, BASIC is no less secure than FORM though, so whoever came up with that rule has no idea what they are talking about. In fact FORM has some ugly weaknesses that BASIC does not, namely the potential to hijack session tokens without having to even care which user owns it. Also our management interface isn't just a browser application, it supports usage from REST-like HTTP client applications, and FORM just doesn't make sense for those. This makes me wonder how on earth could any form of password scheme would survive these security standards, since they all use BASIC? If we did a javascript login, it would look like form but would still be stateless, we would be either using BASIC or DIGEST headers from the javascript code. The funny thing about BASIC being disallowed, is I could use a different auth header, I could call it "NOTBASIC", or maybe I could even call it "FORM". Under the hood its the same as every other plain text transmission method. You are sending the password over the wire. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Jess Sightler edited comment on AS7-4646 at 4/27/12 11:02 AM: -------------------------------------------------------------- HTTP BASIC and FORM are better than DIGEST for these types of environments, because all communications are over SSL. When all communications are over SSL, the tradeoffs involved in HTTP DIGEST no longer make sense. was (Author: jsightler): HTTP BASIC and FORM are better, because all communications are over SSL. When all communications are over SSL, the tradeoffs involved in HTTP DIGEST no longer make sense. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Jess Sightler commented on AS7-4646: ------------------------------------ @Jason Greene - To be clear here, I'm not really arguing against the points you are making here. We just have to deal with a very particular set of security requirements (not from ourselves), that are based on history and various other reasons. Honestly, you are absolutely right... if this thing were controlled by Javascript, and the header could be construed as to not look like BASIC, that would likely be adequate to pass this checklist. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse commented on AS7-4646: --------------------------------------- At what point do your requirements regarding storage actually apply? Is it that it needs to be irreversible or just a level of encryption that is applied? As I said above we do have an option to use the vault to store the passwords to work with Digest authentication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4646?page=com.atlassian.jira.plugin.s... ] Jason Greene commented on AS7-4646: ----------------------------------- Jess is certainly right about FIPS. FIPS essentially whitelists all encryption algorithms an entire product is allowed to use. So hes right that md5 would fail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira