A timing channel in PasswordCredentials.java

[fredfeng]

Current password comparison violates the "constant-time" discipline which could lead to a timing attack: https://github.com/acciente/oacc-core/blob/master/src/main/java/com/acciente/oacc/PasswordCredentials.java#L66

For more information about timing attack, please refer to: https://codahale.com/a-lesson-in-timing-attacks/

[fspinnenhirn]

Hi fredfeng, Thanks for checking out OACC and being concerned about its security!

The kind of side-channel vulnerability you're implying here occurs when an attacker tries to compromise a secret by analyzing the response time of comparing values (provided by the attacker) against that secret.

In our case, the PasswordCredentials class represents a "dumb" container object to transfer char[] passwords from the client to the built-in authentication provider implementation. The equals() method of the PasswordCredentials is overridden to fulfill the standard Java contract of objects to provide sensible implementations of hashCode() and equals().

OACC does not use the equals() method to compare passwords during authentication — and neither should anyone else! OACC's built-in password-based authentication provider uses one-way cryptographic hashing functions (your choice of bcrypt or Jasypt) on salted passwords to store and to later check against during authentication. Since OACC never stores passwords, and only compares salted hashes in the provided implementations, there is no risk of a timing attack from the PasswordCredentials class.

Let me know if you have any other questions or observations! Regards, -Fabian

[fredfeng]

Hi Fabian,

I see. I didn't realize that the equals() method in PasswordCredentials.java is never called in practice.

Thanks for the reply!