<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <title>RE: Security - Password encryption/decryption problems</title>
  <link rel="self" href="https://liferay.dev/c/message_boards/find_thread?p_l_id=119785294&amp;threadId=103290543" />
  <subtitle>RE: Security - Password encryption/decryption problems</subtitle>
  <id>https://liferay.dev/c/message_boards/find_thread?p_l_id=119785294&amp;threadId=103290543</id>
  <updated>2026-04-27T16:36:49Z</updated>
  <dc:date>2026-04-27T16:36:49Z</dc:date>
  <entry>
    <title>RE: Security - Password encryption/decryption problems</title>
    <link rel="alternate" href="https://liferay.dev/c/message_boards/find_message?p_l_id=119785294&amp;messageId=103291374" />
    <author>
      <name>David H Nebinger</name>
    </author>
    <id>https://liferay.dev/c/message_boards/find_message?p_l_id=119785294&amp;messageId=103291374</id>
    <updated>2018-01-29T21:19:31Z</updated>
    <published>2018-01-29T21:19:31Z</published>
    <summary type="html">&lt;div class="quote-title"&gt;Shaun Nesbitt:&lt;/div&gt;&lt;blockquote&gt;I&amp;#39;m looking at replicating the logic that liferay implements for encoding/decoding passwords.&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;Okay, just for clarification, there is no password decoding.  The password algorithms are one-way only.  A given string is &amp;#34;encrypted&amp;#34; and that value is compared to what is stored.  This ensures that someone cannot get a copy of your database, &amp;#34;decrypt&amp;#34; all of the passwords and then start penetrating your environment.&lt;br /&gt;&lt;br /&gt;Although this may seem like a nit, I wouldn&amp;#39;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.&lt;br /&gt;&lt;br /&gt;&lt;blockquote&gt;a) The base64 encode and decode in Liferay is using it&amp;#39;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&amp;#39;m using has by default. I&amp;#39;ve tested node.js and c#). I&amp;#39;ve tested encoding/decoding using the standard java libraries and Liferays one and I get different results.&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;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.&lt;br /&gt;&lt;br /&gt;I mean, Liferay will support a lockout if you have a failed login after X number of attempts.  If you don&amp;#39;t emulate the same thing, you&amp;#39;d be creating a way for hackers to submit a brute force password attack, hammering your system until they get a successful result.&lt;br /&gt;&lt;br /&gt;Seriously, there are good reasons we all don&amp;#39;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.&lt;br /&gt;&lt;br /&gt;&lt;blockquote&gt;b) When I get the equivalent getInt() as found in the link below, I&amp;#39;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)&lt;br /&gt;https://github.com/liferay/liferay-portal/blob/6.2.1-ga2/portal-impl/src/com/liferay/portal/security/pwd/PBKDF2PasswordEncryptor.java#L6&lt;/blockquote&gt;&lt;br /&gt;&lt;br /&gt;Well I don&amp;#39;t know what your line 6 points to, but for me the link you specified is the comments.&lt;br /&gt;&lt;br /&gt;As far as 160 and 128000 go, those are the defaults, but if you read the code you&amp;#39;ll see where they can be derived from either the encrypted password or the algorithm, so they are not fixed by any means.&lt;br /&gt;&lt;br /&gt;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 &amp;#34;fake&amp;#34; SSO implementation is pretty much guaranteed to be a security whole that a decent hacker will be able to drive a truck through.</summary>
    <dc:creator>David H Nebinger</dc:creator>
    <dc:date>2018-01-29T21:19:31Z</dc:date>
  </entry>
</feed>
