Ask Questions and Find Answers

I'm looking at replicating the logic that liferay implements for encoding/decoding passwords.

Okay, just for clarification, there is no password decoding. The password algorithms are one-way only. A given string is "encrypted" and that value is compared to what is stored. This ensures that someone cannot get a copy of your database, "decrypt" all of the passwords and then start penetrating your environment.

Although this may seem like a nit, I wouldn't want someone tripping into this thread and think it is possible to decrypt the password, because it is not possible. Well, a brute force attack is possible, but it will take awhile.

a) The base64 encode and decode in Liferay is using it's own utility library com.liferay.portal.kernel.util.Base64 (so i have to copy this logic across instead of using whatever backend language I'm using has by default. I've tested node.js and c#). I've tested encoding/decoding using the standard java libraries and Liferays one and I get different results.

What are you trying to do here? I mean, it would appear that you are trying to somehow fake out an SSO solution without actually implementing a real SSO system. That in itself is a security issue.

I mean, Liferay will support a lockout if you have a failed login after X number of attempts. If you don't emulate the same thing, you'd be creating a way for hackers to submit a brute force password attack, hammering your system until they get a successful result.

Seriously, there are good reasons we all don't sit around trying to create our own SSO implementations as there is a better than average chance we would not cover all of the different attack vectors.

b) When I get the equivalent getInt() as found in the link below, I'm getting back really huge numbers for the number of rounds and key size. My assumption is that I should be getting back the values as noted in the code below (160, 128000)
https://github.com/liferay/liferay-portal/blob/6.2.1-ga2/portal-impl/src/com/liferay/portal/security/pwd/PBKDF2PasswordEncryptor.java#L6

Well I don't know what your line 6 points to, but for me the link you specified is the comments.

As far as 160 and 128000 go, those are the defaults, but if you read the code you'll see where they can be derived from either the encrypted password or the algorithm, so they are not fixed by any means.

Ultimately, though, my recommendation is that if you need an SSO solution, then go with a real SSO solution such as CAS or JOSSO or SAML or ... Any sort of "fake" SSO implementation is pretty much guaranteed to be a security whole that a decent hacker will be able to drive a truck through.