[jira] [Commented] (SHIRO-552) JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt column is utf8 bytes

2019-05-29 Thread Steinar Bang (JIRA)


[ 
https://issues.apache.org/jira/browse/SHIRO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16851284#comment-16851284
 ] 

Steinar Bang commented on SHIRO-552:


I've created a github pull request with a fix for this issue: 
https://github.com/apache/shiro/pull/138

> JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt 
> column is utf8 bytes
> --
>
> Key: SHIRO-552
> URL: https://issues.apache.org/jira/browse/SHIRO-552
> Project: Shiro
>  Issue Type: Bug
>Affects Versions: 1.2.4
>Reporter: Richard Bradley
>Priority: Major
>
> The {{org.apache.shiro.realm.jdbc.JdbcRealm}} class, when configured with 
> SaltStyle.COLUMN, assumes that password column is Base64 but salt column is 
> utf8 bytes.
> The password is returned as a {{char[]}} (see JdbcRealm.java:241), which 
> {{org.apache.shiro.authc.credential.HashedCredentialsMatcher}} (see 
> HashedCredentialsMatcher.java:353):
> {code}
> if (credentials instanceof String || credentials instanceof char[]) {
> //account.credentials were a char[] or String, so
> //we need to do text decoding first:
> if (isStoredCredentialsHexEncoded()) {
> storedBytes = Hex.decode(storedBytes);
> } else {
> storedBytes = Base64.decode(storedBytes);
> }
> }
> {code}
> However, the salt is returned as a {{ByteSource}}, by converting the 
> DB-returned String into its UTF-8 bytes. See JdbcRealm.java:224:
> {code}
> if (salt != null) {
> info.setCredentialsSalt(ByteSource.Util.bytes(salt));
> }
> {code}
> This is broken and inconsistent.
> Not all salt byte[]s are valid UTF8 strings, so the default assumption should 
> be that the salt column is Base64 encoded.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (SHIRO-552) JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt column is utf8 bytes

2017-06-20 Thread Richard Bradley (JIRA)

[ 
https://issues.apache.org/jira/browse/SHIRO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16055409#comment-16055409
 ] 

Richard Bradley commented on SHIRO-552:
---

> Another workaround would be to go to hex encoding of the password and the 
> salt. Presumably that works...?

Yes, any reversible binary safe encoding would work. Base64 is a lot denser 
than hexadecimal strings though, so would be more efficient.

> JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt 
> column is utf8 bytes
> --
>
> Key: SHIRO-552
> URL: https://issues.apache.org/jira/browse/SHIRO-552
> Project: Shiro
>  Issue Type: Bug
>Affects Versions: 1.2.4
>Reporter: Richard Bradley
>
> The {{org.apache.shiro.realm.jdbc.JdbcRealm}} class, when configured with 
> SaltStyle.COLUMN, assumes that password column is Base64 but salt column is 
> utf8 bytes.
> The password is returned as a {{char[]}} (see JdbcRealm.java:241), which 
> {{org.apache.shiro.authc.credential.HashedCredentialsMatcher}} (see 
> HashedCredentialsMatcher.java:353):
> {code}
> if (credentials instanceof String || credentials instanceof char[]) {
> //account.credentials were a char[] or String, so
> //we need to do text decoding first:
> if (isStoredCredentialsHexEncoded()) {
> storedBytes = Hex.decode(storedBytes);
> } else {
> storedBytes = Base64.decode(storedBytes);
> }
> }
> {code}
> However, the salt is returned as a {{ByteSource}}, by converting the 
> DB-returned String into its UTF-8 bytes. See JdbcRealm.java:224:
> {code}
> if (salt != null) {
> info.setCredentialsSalt(ByteSource.Util.bytes(salt));
> }
> {code}
> This is broken and inconsistent.
> Not all salt byte[]s are valid UTF8 strings, so the default assumption should 
> be that the salt column is Base64 encoded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (SHIRO-552) JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt column is utf8 bytes

2017-06-19 Thread Steinar Bang (JIRA)

[ 
https://issues.apache.org/jira/browse/SHIRO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054619#comment-16054619
 ] 

Steinar Bang commented on SHIRO-552:


Thanks.  For now I'm staying with [my eksisting custom 
realm|https://github.com/steinarb/ukelonn/blob/master/ukelonn.bundle/src/main/java/no/priv/bang/ukelonn/impl/UkelonnRealm.java#L28]
 (which does base64 encoding of the salt).

Another workaround would be to go to hex encoding of the password and the salt. 
 Presumably that works...?

> JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt 
> column is utf8 bytes
> --
>
> Key: SHIRO-552
> URL: https://issues.apache.org/jira/browse/SHIRO-552
> Project: Shiro
>  Issue Type: Bug
>Affects Versions: 1.2.4
>Reporter: Richard Bradley
>
> The {{org.apache.shiro.realm.jdbc.JdbcRealm}} class, when configured with 
> SaltStyle.COLUMN, assumes that password column is Base64 but salt column is 
> utf8 bytes.
> The password is returned as a {{char[]}} (see JdbcRealm.java:241), which 
> {{org.apache.shiro.authc.credential.HashedCredentialsMatcher}} (see 
> HashedCredentialsMatcher.java:353):
> {code}
> if (credentials instanceof String || credentials instanceof char[]) {
> //account.credentials were a char[] or String, so
> //we need to do text decoding first:
> if (isStoredCredentialsHexEncoded()) {
> storedBytes = Hex.decode(storedBytes);
> } else {
> storedBytes = Base64.decode(storedBytes);
> }
> }
> {code}
> However, the salt is returned as a {{ByteSource}}, by converting the 
> DB-returned String into its UTF-8 bytes. See JdbcRealm.java:224:
> {code}
> if (salt != null) {
> info.setCredentialsSalt(ByteSource.Util.bytes(salt));
> }
> {code}
> This is broken and inconsistent.
> Not all salt byte[]s are valid UTF8 strings, so the default assumption should 
> be that the salt column is Base64 encoded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (SHIRO-552) JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt column is utf8 bytes

2017-06-19 Thread Richard Bradley (JIRA)

[ 
https://issues.apache.org/jira/browse/SHIRO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053721#comment-16053721
 ] 

Richard Bradley commented on SHIRO-552:
---

> I've been trying to convert my existing salt to a form understood by the 
> JdbcRealm but so far I've failed:
> ...
> But trying to figure out what the correct way of encoding the salt should be 
> has so far evaded me...

Those salt bytes are not a valid UTF-8 byte sequence, so any sensible database 
/ database client will not allow you to store them as a UTF-8 string.
There is no way of configuring or encoding JdbcRealm to fix this; the code 
needs changing so that either a) the salt is stored Base64 encoded in a String 
column or b) the salt is stored in a binary column.

You can either fork Shiro and make this change (please submit this change 
upstream for the benefit of all if you do), or you could write your own Realm 
which includes this change.

GL,


Rich

> JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt 
> column is utf8 bytes
> --
>
> Key: SHIRO-552
> URL: https://issues.apache.org/jira/browse/SHIRO-552
> Project: Shiro
>  Issue Type: Bug
>Affects Versions: 1.2.4
>Reporter: Richard Bradley
>
> The {{org.apache.shiro.realm.jdbc.JdbcRealm}} class, when configured with 
> SaltStyle.COLUMN, assumes that password column is Base64 but salt column is 
> utf8 bytes.
> The password is returned as a {{char[]}} (see JdbcRealm.java:241), which 
> {{org.apache.shiro.authc.credential.HashedCredentialsMatcher}} (see 
> HashedCredentialsMatcher.java:353):
> {code}
> if (credentials instanceof String || credentials instanceof char[]) {
> //account.credentials were a char[] or String, so
> //we need to do text decoding first:
> if (isStoredCredentialsHexEncoded()) {
> storedBytes = Hex.decode(storedBytes);
> } else {
> storedBytes = Base64.decode(storedBytes);
> }
> }
> {code}
> However, the salt is returned as a {{ByteSource}}, by converting the 
> DB-returned String into its UTF-8 bytes. See JdbcRealm.java:224:
> {code}
> if (salt != null) {
> info.setCredentialsSalt(ByteSource.Util.bytes(salt));
> }
> {code}
> This is broken and inconsistent.
> Not all salt byte[]s are valid UTF8 strings, so the default assumption should 
> be that the salt column is Base64 encoded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (SHIRO-552) JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt column is utf8 bytes

2017-06-18 Thread Steinar Bang (JIRA)

[ 
https://issues.apache.org/jira/browse/SHIRO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16053244#comment-16053244
 ] 

Steinar Bang commented on SHIRO-552:


I've been trying to convert my existing salt to a form understood by the 
JdbcRealm but so far I've failed:
I can't get the same byte[] out of CodecSupport.toBytes(String) that I'm 
putting in.

Has anyone successfully used the JdbcRealm with salt?

So far I haven't found any google matches that shows working code examples of 
this.  The closest I've been getting is [this stackoverflow 
answer|https://stackoverflow.com/a/23755827], which has saving the salt as a 
TODO

This is what I've done to try to fix the salt in the database:
# Add a liquibase changeset that adds a new column to the users table in the 
database
{code:xml}





{code}
# Add a liquibase changeset that runs a custom task to convert the old base64 
encoded salt values to utf-8 encoded salt values
{code:xml}


{code}
The essential part of the custom task, is:
{code:java}
public class ConvertUsersTableSaltEncodingFromBase64ToUtf8 implements 
CustomTaskChange {

@Override
public void execute(Database database) throws CustomChangeException {
JdbcConnection connection = (JdbcConnection) 
database.getConnection();
try {
PreparedStatement getsalt = connection.prepareStatement("select 
user_id, salt from users");
PreparedStatement updateUtf8EncodedSalt = 
connection.prepareStatement("update users set password_salt=? where user_id=?");
ResultSet result = getsalt.executeQuery();
while(result.next()) {
int userId = result.getInt(0);
String base64EncodedSalt = result.getString(1);
byte[] decodedSalt = 
Base64.getDecoder().decode(base64EncodedSalt);
char[] utf8EncodedSalt = CodecSupport.toChars(decodedSalt);
//String utf8EncodedSalt = CodecSupport.toString(decodedSalt);
//String utf8EncodedSalt = new String(decodedSalt, 
StandardCharsets.UTF_8);
updateUtf8EncodedSalt.setString(0, new 
String(utf8EncodedSalt));
updateUtf8EncodedSalt.setInt(1, userId);
updateUtf8EncodedSalt.executeUpdate();
}
} catch (Exception e) {
throw new CustomChangeException("Failed to convert users table salt 
values from base64 to utf-8", e);
}
}
}
{code}

The variuous commented out variants all give the same results:
What I put in, is:
{noformat}
[34, -17, 112, -83, -19, -119, -127, 123, -79, -67, 20, -10, 48, 13, 2, 25]
{noformat}
What I get out, is:
{noformat}
[34, -17, -65, -67, 112, -17, -65, -67, -19, -119, -127, 123, -17, -65, -67, 
-17, -65, -67, 20, -17, -65, -67, 48, 13, 2, 25]
{noformat}

There is a pattern there: byte three in the original sequence can be found as 
byte 5 in the second, the start and end are the same in both sequences

But trying to figure out what the correct way of encoding the salt should be 
has so far evaded me...

Base64 would have been much simpler, and I know from my own custom realm: it 
works
(and when I think about it: the issues around the salt may be why I ended up 
with a custom realm last autumn...? I remember something vaguely about that)


> JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt 
> column is utf8 bytes
> --
>
> Key: SHIRO-552
> URL: https://issues.apache.org/jira/browse/SHIRO-552
> Project: Shiro
>  Issue Type: Bug
>Affects Versions: 1.2.4
>Reporter: Richard Bradley
>
> The {{org.apache.shiro.realm.jdbc.JdbcRealm}} class, when configured with 
> SaltStyle.COLUMN, assumes that password column is Base64 but salt column is 
> utf8 bytes.
> The password is returned as a {{char[]}} (see JdbcRealm.java:241), which 
> {{org.apache.shiro.authc.credential.HashedCredentialsMatcher}} (see 
> HashedCredentialsMatcher.java:353):
> {code}
> if (credentials instanceof String || credentials instanceof char[]) {
> //account.credentials were a char[] or String, so
> //we need to do text decoding first:
> if (isStoredCredentialsHexEncoded()) {
> storedBytes = Hex.decode(storedBytes);
> } else {
> storedBytes = Base64.decode(storedBytes);
> }
> }
> {code}
> However, the salt is returned as a {{ByteSource}}, by converting the 
> DB-returned String into its UTF-8 bytes. See JdbcRealm.java:224:
> {code}
> if (salt != null) {
> info.setCredentialsSalt(ByteSource.Util.bytes(salt));
> }
> {code}
> This is bro

[jira] [Commented] (SHIRO-552) JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt column is utf8 bytes

2017-06-17 Thread Steinar Bang (JIRA)

[ 
https://issues.apache.org/jira/browse/SHIRO-552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16052811#comment-16052811
 ] 

Steinar Bang commented on SHIRO-552:


This one bit me today.

I'm trying to use salt from a password table used by my own custom realm 
[UkelonnRealm|https://github.com/steinarb/ukelonn/blob/master/ukelonn.bundle/src/main/java/no/priv/bang/ukelonn/impl/UkelonnRealm.java#L60]
 from a JdbcRealm, but that breaks because the base64 encoded salt value from 
the DB is interpreted as UTF-8 when converting the salt into a byte array.

I've been looking for a way to configure the encoding of the salt in JdbcRealm, 
but there doesn't seem to be any way to do this?

> JdbcRealm in SaltStyle.COLUMN assumes that password column is Base64 but salt 
> column is utf8 bytes
> --
>
> Key: SHIRO-552
> URL: https://issues.apache.org/jira/browse/SHIRO-552
> Project: Shiro
>  Issue Type: Bug
>Affects Versions: 1.2.4
>Reporter: Richard Bradley
>
> The {{org.apache.shiro.realm.jdbc.JdbcRealm}} class, when configured with 
> SaltStyle.COLUMN, assumes that password column is Base64 but salt column is 
> utf8 bytes.
> The password is returned as a {{char[]}} (see JdbcRealm.java:241), which 
> {{org.apache.shiro.authc.credential.HashedCredentialsMatcher}} (see 
> HashedCredentialsMatcher.java:353):
> {code}
> if (credentials instanceof String || credentials instanceof char[]) {
> //account.credentials were a char[] or String, so
> //we need to do text decoding first:
> if (isStoredCredentialsHexEncoded()) {
> storedBytes = Hex.decode(storedBytes);
> } else {
> storedBytes = Base64.decode(storedBytes);
> }
> }
> {code}
> However, the salt is returned as a {{ByteSource}}, by converting the 
> DB-returned String into its UTF-8 bytes. See JdbcRealm.java:224:
> {code}
> if (salt != null) {
> info.setCredentialsSalt(ByteSource.Util.bytes(salt));
> }
> {code}
> This is broken and inconsistent.
> Not all salt byte[]s are valid UTF8 strings, so the default assumption should 
> be that the salt column is Base64 encoded.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)