As I've stated before, I intend for JBoss Remoting 3 to utilize SASL for authentication, with SRP as its default mechanism. So pursuant to that, yesterday I put together a simple SRP SASL client & server provider. However, I can't work out the best way to handle password verification on the server side. One of the key security advantages of SRP is that the server does not need to store the user password, so if this database is compromised, the attacker cannot directly use this database to impersonate users. Instead, SRP stores a password verifier which is calculated from the password using a one-way algorithm. However the default SASL mechanisms generally require the server to have a copy of the cleartext password. In fact, the SASL API does not even include a Callback type to handle a password verifier of any kind. So, using just the default SASL API, there is no way to acquire the SRP password verifier value. Here's the options as I see them: Option #1: Just use PasswordCallback on the server side to get the clear password and derive the verifier from that value at authentication time. Pro: uses existing API; compatible out-of-the-box with code that uses default mechanisms such as DIGEST-MD5 or CRAM-MD5. Con: Loses key advantage of SRP (ability to avoid storing cleartext passwords). Option #2: Add a custom VerifierCallback used by the server side to get the verifier value. Pro: Stronger server-side security (no cleartext passwords stored). Con: SRP server code must be aware that SRP is the mechanism in use; will not be portable between different SRP SASL implementations (on the server side anyway). Option #3: Do not use a callback for password or verifier; instead, use a SASL configuration parameter to specify either a password file or some other means to acquire the verifier. Pro: still *mostly* compatible out-of-the-box with SASL authentication code (still would use NameCallback and AuthorizeCallback normally). Con: "mostly" != "fully"... Another possible option is to create a new GSSAPI provider and use SRP that way, with a special credential for SRP verifier. However, Sun's GSSAPI SASL mechanism cannot support any GSSAPI mechanism other than Kerberos. Also, this is a considerably more complex solution, and requires additional security APIs. For these reasons, I don't want to go this route for Remoting unless there's no other choice. I'm leaning towards doing Option #1 by default, for simplicity, but providing a SASL server property that can be enabled that causes the server to use the custom VerifierCallback, per Option #2. Any opinions? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096743#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...