RE: [cas-user] Using SHA512

2014-07-14 Thread richard . wiseman 
The password and salt are indeed stored in the same database in different 
columns.  The only encoding I ever seem to see is base64, so the hex actually 
surprised me!  (I've next to no experience with hashing passwords, but my 
googling has tended to yield results that base64-encode hashes and salts.)

As far as ordering of digest inputs goes, that I couldn't say, since it's all 
done by an Apache Shiro object:

Sha512Hash shaHasher = new Sha512Hash(password, salt, iterations);

(And the next time shaHasher is mentioned, it's to get the bytes to pass to 
String.format.)

Regards,

Richard


-Original Message-
From: Marvin Addison [mailto:marvin.addi...@gmail.com] 
Sent: 14 July 2014 15:54
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Using SHA512

>An example hash is:
4d8d39a8283a53aeb51061457edc32c6a8e5404864b7571bf7b33d2c3bd5c580869ac1635be0d8ee57581f28b8aa9799729244852eb7aa010e7ac7b1cd69638f
>
> And an example salt is:
> 91f3c641110b2ded640c418046b3cb5af257da06ca98f192085cb10c7443e5e9

I think hex encoding is common and safe to assume generally. Just to
clarify, these values are stored in separate columns in the same
table? I would hope that's common and a safe assumption. Supporting
values across separate tables is possible, but it's hopefully an edge
case we could ignore.

> I also have to be able to specify the number of iterations, of course, which 
> is another issue!

That's a common input for salted hashing, so that would be an
anticipated configuration point.

The only concern you didn't address is whether the salt is the first
input to the digest or the last; I have seen both approaches used in
practice. I find it strange that there is no standard or guidance on
the matter despite having researched it fairly extensively. It looks
like it's simply an arbitrary choice and the CAS component would have
to support both approaches.

M

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
richard.wise...@bt.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Using SHA512

2014-07-14 Thread Marvin Addison 
>An example hash is:
4d8d39a8283a53aeb51061457edc32c6a8e5404864b7571bf7b33d2c3bd5c580869ac1635be0d8ee57581f28b8aa9799729244852eb7aa010e7ac7b1cd69638f
>
> And an example salt is:
> 91f3c641110b2ded640c418046b3cb5af257da06ca98f192085cb10c7443e5e9

I think hex encoding is common and safe to assume generally. Just to
clarify, these values are stored in separate columns in the same
table? I would hope that's common and a safe assumption. Supporting
values across separate tables is possible, but it's hopefully an edge
case we could ignore.

> I also have to be able to specify the number of iterations, of course, which 
> is another issue!

That's a common input for salted hashing, so that would be an
anticipated configuration point.

The only concern you didn't address is whether the salt is the first
input to the digest or the last; I have seen both approaches used in
practice. I find it strange that there is no standard or guidance on
the matter despite having researched it fairly extensively. It looks
like it's simply an arbitrary choice and the CAS component would have
to support both approaches.

M

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] Using SHA512

2014-07-14 Thread richard . wiseman 
Hi Marvin,

My database is actually someone else's database, but I do know (now) that the 
hashes stored in the database are generated using Apache Shiro and that the 
salt is stored as hex.  An example hash is:

4d8d39a8283a53aeb51061457edc32c6a8e5404864b7571bf7b33d2c3bd5c580869ac1635be0d8ee57581f28b8aa9799729244852eb7aa010e7ac7b1cd69638f

And an example salt is:

91f3c641110b2ded640c418046b3cb5af257da06ca98f192085cb10c7443e5e9

This salt is 32 bits (64 characters).  I also have to be able to specify the 
number of iterations, of course, which is another issue!  This is why I'm now 
thinking that implementing the hashing in my own class (by retrieving the 
hashed password and salt from the database and then processing them along with 
the provided password) is the only realistic route.

Regards,

Richard

-Original Message-
From: Marvin Addison [mailto:marvin.addi...@gmail.com] 
Sent: 14 July 2014 15:32
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Using SHA512

> I'll look at the documentation again to try and work out the best/simplest
> approach.

Can you briefly describe how you store the salt in your database?
There's a quasi-standard for LDAP directories, SSHA, but nothing
equivalent that I'm aware of in the database world. The challenge for
the CAS project will be shipping a component that has the right
configuration knobs, but we don't have good use cases from which to
design those knobs at present. Your input will help in that regard.

M

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
richard.wise...@bt.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Using SHA512

2014-07-14 Thread Marvin Addison 
> I'll look at the documentation again to try and work out the best/simplest
> approach.

Can you briefly describe how you store the salt in your database?
There's a quasi-standard for LDAP directories, SSHA, but nothing
equivalent that I'm aware of in the database world. The challenge for
the CAS project will be shipping a component that has the right
configuration knobs, but we don't have good use cases from which to
design those knobs at present. Your input will help in that regard.

M

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] Using SHA512

2014-07-14 Thread richard . wiseman 
One further (hopefully quick) question, if I may…

Until now, I’ve been using the SearchModeSearchDatabaseAuthenticationHandler 
class, but this doesn’t do everything I need (and neither do the alternatives) 
so I thought I would copy it and customise it.  I’ve given it a new name (of 
course) but left it in the same package; I’ve compiled it, created a .jar file 
and put that in WEB-INF/lib (where I’ve successfully put various other .jars to 
get things working).  However, CAS is complaining on start-up:

Caused by: org.springframework.beans.factory.BeanCreationException: Error 
creating bean with name 'authenticationManager' defined in ServletContext 
resource
[/WEB-INF/deployerConfigContext.xml]: Cannot resolve reference to bean 
'primaryAuthenticationHandler' while setting constructor argument; nested 
exception is
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'primaryAuthenticationHandler' defined in ServletContext resource [/W
EB-INF/deployerConfigContext.xml]: Initialization of bean failed; nested 
exception is java.lang.NoClassDefFoundError: 
org/jasig/cas/authentication/principal/
UsernamePasswordCredentials

I think this means it either can’t find my class or can’t turn it into a bean.  
My class is almost identical to SearchModeSearchDatabaseAuthenticationHandler, 
so the latter seems unlikely.

Am I missing a step?

Thanks,

Richard

From: richard.wise...@bt.com [mailto:richard.wise...@bt.com]
Sent: 10 July 2014 18:30
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] Using SHA512

Thanks again Dmitriy. I suspected that it wouldn't be possible out of the box 
but thought I'd ask just in case! I'll look into the possibility of creating a 
custom plug-in or something.

I'll look at the documentation again to try and work out the best/simplest 
approach. Any pointers or hints would if course be welcome! :-)

Thanks once again,

Richard

-Original Message-
From: Dmitriy Kopylenko [dkopyle...@unicon.net<mailto:dkopyle...@unicon.net>]
Sent: Thursday, July 10, 2014 04:26 PM GMT Standard Time
To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>
Subject: Re: [cas-user] Using SHA512
I don’t think CAS’ out of the box password encoder supports salt, etc. 
cas-addons has a Shiro’s framework based encoder impl which supports salting 
(only static at this time):

https://github.com/Unicon/cas-addons/wiki/Configuring%20ShiroHashServicePasswordEncoder

If there is enough interest for dynamic salt config, we could consider it 
adding it. Or another option, of course is the JIRA against CAS core for the 
more robust encoder impl(s) to be developed, etc.

Best,
Dmitriy.

On Jul 10, 2014, at 11:19 AM, 
richard.wise...@bt.com<mailto:richard.wise...@bt.com> wrote:


Hi Dmitriy,

Thanks very much for that – it works! :-)

Now for the really difficult part, I fear…  Is it possible to provide a salt by 
specifying a database column?

Thanks again,

Richard

From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net]
Sent: 10 July 2014 16:12
To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>
Subject: Re: [cas-user] Using SHA512

Hi Richard.

Try SHA-512 instead of SHA512

Best,
Dmitriy.

On Jul 10, 2014, at 10:04 AM, Richard Wiseman 
mailto:richard.wise...@bt.com>> wrote:

Hi,

The CAS documentation <https://wiki.jasig.org/display/CASUM/JDBC> indicates 
that you can use any of the MACs listed on the JDK Javadoc 
<http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA>
 for the password encoder's encodingAlgorithm attribute; this list includes 
"HmacSHA512", which is what I want to use.  (I confess I don't know the 
difference, if any, between SHA512 and HmacSHA512 in the context of hashing 
passwords.)

I have used the following in my deployerConfigContext.xml file:



and it worked.  However, neither of the following two variants works:



and



Each of these results in something in the log such as:

2014-07-10 15:13:01,251 INFO 
[com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail 
record BEGIN
=
WHO: audit:unknown
WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available
ACTION: TICKET_GRANTING_TICKET_NOT_CREATED
APPLICATION: CAS
WHEN: Thu Jul 10 15:13:01 BST 2014
CLIENT IP ADDRESS: 10.255.240.6
SERVER IP ADDRESS: cas.zion.bt.co.uk
=

This suggests that I have to provide an implementation of SHA512.  However, I 
have no idea where to get one or how to make it available once I do!  (I assume 
I would get a JAR file and put it in WEB-INF/lib - but I don't know how I would 
specify the implementing class name in deployerConfigContext.xml.)

Also, even if I do find an implementation, what I really need is one that lets 
me specify a salt for

RE: [cas-user] Using SHA512

2014-07-10 Thread richard . wiseman 
Thanks again Dmitriy. I suspected that it wouldn't be possible out of the box 
but thought I'd ask just in case! I'll look into the possibility of creating a 
custom plug-in or something.

I'll look at the documentation again to try and work out the best/simplest 
approach. Any pointers or hints would if course be welcome! :-)

Thanks once again,

Richard

-Original Message-
From: Dmitriy Kopylenko [dkopyle...@unicon.net<mailto:dkopyle...@unicon.net>]
Sent: Thursday, July 10, 2014 04:26 PM GMT Standard Time
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Using SHA512

I don’t think CAS’ out of the box password encoder supports salt, etc. 
cas-addons has a Shiro’s framework based encoder impl which supports salting 
(only static at this time):

https://github.com/Unicon/cas-addons/wiki/Configuring%20ShiroHashServicePasswordEncoder

If there is enough interest for dynamic salt config, we could consider it 
adding it. Or another option, of course is the JIRA against CAS core for the 
more robust encoder impl(s) to be developed, etc.

Best,
Dmitriy.

On Jul 10, 2014, at 11:19 AM, 
richard.wise...@bt.com<mailto:richard.wise...@bt.com> wrote:

Hi Dmitriy,

Thanks very much for that – it works! :-)

Now for the really difficult part, I fear…  Is it possible to provide a salt by 
specifying a database column?

Thanks again,

Richard

From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net]
Sent: 10 July 2014 16:12
To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>
Subject: Re: [cas-user] Using SHA512

Hi Richard.

Try SHA-512 instead of SHA512

Best,
Dmitriy.

On Jul 10, 2014, at 10:04 AM, Richard Wiseman 
mailto:richard.wise...@bt.com>> wrote:


Hi,

The CAS documentation <https://wiki.jasig.org/display/CASUM/JDBC> indicates 
that you can use any of the MACs listed on the JDK Javadoc 
<http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA>
 for the password encoder's encodingAlgorithm attribute; this list includes 
"HmacSHA512", which is what I want to use.  (I confess I don't know the 
difference, if any, between SHA512 and HmacSHA512 in the context of hashing 
passwords.)

I have used the following in my deployerConfigContext.xml file:



and it worked.  However, neither of the following two variants works:



and



Each of these results in something in the log such as:

2014-07-10 15:13:01,251 INFO 
[com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail 
record BEGIN
=
WHO: audit:unknown
WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available
ACTION: TICKET_GRANTING_TICKET_NOT_CREATED
APPLICATION: CAS
WHEN: Thu Jul 10 15:13:01 BST 2014
CLIENT IP ADDRESS: 10.255.240.6
SERVER IP ADDRESS: cas.zion.bt.co.uk
=

This suggests that I have to provide an implementation of SHA512.  However, I 
have no idea where to get one or how to make it available once I do!  (I assume 
I would get a JAR file and put it in WEB-INF/lib - but I don't know how I would 
specify the implementing class name in deployerConfigContext.xml.)

Also, even if I do find an implementation, what I really need is one that lets 
me specify a salt for each password.

And I need to get the salt from the database containing the hashed passwords.

Is this an unrealistic or naively optimistic notion?  Should I really be 
thinking about implementing a bean or other Java class and (somehow) using that 
instead of CAS's built in JDBC options?  If I should, what's the 
preferred/easiest approach?

Any advice would be much appreciated!

Many thanks.
--
You are currently subscribed to 
cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: 
dkopyle...@unicon.net<mailto:dkopyle...@unicon.net>
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user







--



You are currently subscribed to 
cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: 
richard.wise...@bt.com<mailto:richard.wise...@bt.com>



To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user



--
You are currently subscribed to 
cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: 
dkopyle...@unicon.net<mailto:dkopyle...@unicon.net>
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user




--
You are currently subscribed to cas-user@lists.jasig.org as: 
richard.wise...@bt.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user


-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Using SHA512

2014-07-10 Thread Dmitriy Kopylenko 
I don’t think CAS’ out of the box password encoder supports salt, etc. 
cas-addons has a Shiro’s framework based encoder impl which supports salting 
(only static at this time):

https://github.com/Unicon/cas-addons/wiki/Configuring%20ShiroHashServicePasswordEncoder

If there is enough interest for dynamic salt config, we could consider it 
adding it. Or another option, of course is the JIRA against CAS core for the 
more robust encoder impl(s) to be developed, etc.

Best,
Dmitriy.

On Jul 10, 2014, at 11:19 AM, richard.wise...@bt.com wrote:

> Hi Dmitriy,
>  
> Thanks very much for that – it works! :-)
>  
> Now for the really difficult part, I fear…  Is it possible to provide a salt 
> by specifying a database column?
>  
> Thanks again,
>  
> Richard
>  
> From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net] 
> Sent: 10 July 2014 16:12
> To: cas-user@lists.jasig.org
> Subject: Re: [cas-user] Using SHA512
>  
> Hi Richard.
>  
> Try SHA-512 instead of SHA512
>  
> Best,
> Dmitriy.
>  
> On Jul 10, 2014, at 10:04 AM, Richard Wiseman  wrote:
> 
> 
> Hi,
> 
> The CAS documentation <https://wiki.jasig.org/display/CASUM/JDBC> indicates 
> that you can use any of the MACs listed on the JDK Javadoc 
> <http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA>
>  for the password encoder's encodingAlgorithm attribute; this list includes 
> "HmacSHA512", which is what I want to use.  (I confess I don't know the 
> difference, if any, between SHA512 and HmacSHA512 in the context of hashing 
> passwords.)
> 
> I have used the following in my deployerConfigContext.xml file:
> 
>  class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder" 
> c:encodingAlgorithm="SHA1" p:characterEncoding="UTF-8" />
> 
> and it worked.  However, neither of the following two variants works:
> 
>  class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder" 
> c:encodingAlgorithm="HmacSHA512" p:characterEncoding="UTF-8" />
> 
> and
> 
>  class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder" 
> c:encodingAlgorithm="SHA512" p:characterEncoding="UTF-8" />
> 
> Each of these results in something in the log such as:
> 
> 2014-07-10 15:13:01,251 INFO 
> [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit 
> trail record BEGIN
> =
> WHO: audit:unknown
> WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not 
> available
> ACTION: TICKET_GRANTING_TICKET_NOT_CREATED
> APPLICATION: CAS
> WHEN: Thu Jul 10 15:13:01 BST 2014
> CLIENT IP ADDRESS: 10.255.240.6
> SERVER IP ADDRESS: cas.zion.bt.co.uk
> =
> 
> This suggests that I have to provide an implementation of SHA512.  However, I 
> have no idea where to get one or how to make it available once I do!  (I 
> assume I would get a JAR file and put it in WEB-INF/lib - but I don't know 
> how I would specify the implementing class name in deployerConfigContext.xml.)
> 
> Also, even if I do find an implementation, what I really need is one that 
> lets me specify a salt for each password.
> 
> And I need to get the salt from the database containing the hashed passwords.
> 
> Is this an unrealistic or naively optimistic notion?  Should I really be 
> thinking about implementing a bean or other Java class and (somehow) using 
> that instead of CAS's built in JDBC options?  If I should, what's the 
> preferred/easiest approach?
> 
> Any advice would be much appreciated!
> 
> Many thanks.
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: 
> dkopyle...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>  
>  
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: 
> richard.wise...@bt.com
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: 
> dkopyle...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user


-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] Using SHA512

2014-07-10 Thread richard . wiseman 
Hi Dmitriy,

Thanks very much for that - it works! :-)

Now for the really difficult part, I fear...  Is it possible to provide a salt 
by specifying a database column?

Thanks again,

Richard

From: Dmitriy Kopylenko [mailto:dkopyle...@unicon.net]
Sent: 10 July 2014 16:12
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Using SHA512

Hi Richard.

Try SHA-512 instead of SHA512

Best,
Dmitriy.

On Jul 10, 2014, at 10:04 AM, Richard Wiseman 
mailto:richard.wise...@bt.com>> wrote:


Hi,

The CAS documentation <https://wiki.jasig.org/display/CASUM/JDBC> indicates 
that you can use any of the MACs listed on the JDK Javadoc 
<http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA>
 for the password encoder's encodingAlgorithm attribute; this list includes 
"HmacSHA512", which is what I want to use.  (I confess I don't know the 
difference, if any, between SHA512 and HmacSHA512 in the context of hashing 
passwords.)

I have used the following in my deployerConfigContext.xml file:



and it worked.  However, neither of the following two variants works:



and



Each of these results in something in the log such as:

2014-07-10 15:13:01,251 INFO 
[com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail 
record BEGIN
=
WHO: audit:unknown
WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available
ACTION: TICKET_GRANTING_TICKET_NOT_CREATED
APPLICATION: CAS
WHEN: Thu Jul 10 15:13:01 BST 2014
CLIENT IP ADDRESS: 10.255.240.6
SERVER IP ADDRESS: cas.zion.bt.co.uk
=

This suggests that I have to provide an implementation of SHA512.  However, I 
have no idea where to get one or how to make it available once I do!  (I assume 
I would get a JAR file and put it in WEB-INF/lib - but I don't know how I would 
specify the implementing class name in deployerConfigContext.xml.)

Also, even if I do find an implementation, what I really need is one that lets 
me specify a salt for each password.

And I need to get the salt from the database containing the hashed passwords.

Is this an unrealistic or naively optimistic notion?  Should I really be 
thinking about implementing a bean or other Java class and (somehow) using that 
instead of CAS's built in JDBC options?  If I should, what's the 
preferred/easiest approach?

Any advice would be much appreciated!

Many thanks.
--
You are currently subscribed to 
cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: 
dkopyle...@unicon.net<mailto:dkopyle...@unicon.net>
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user




--

You are currently subscribed to 
cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org> as: 
richard.wise...@bt.com<mailto:richard.wise...@bt.com>

To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Using SHA512

2014-07-10 Thread Dmitriy Kopylenko 
Hi Richard.

Try SHA-512 instead of SHA512

Best,
Dmitriy.

On Jul 10, 2014, at 10:04 AM, Richard Wiseman  wrote:

> Hi,
> 
> The CAS documentation  indicates 
> that you can use any of the MACs listed on the JDK Javadoc 
> 
>  for the password encoder's encodingAlgorithm attribute; this list includes 
> "HmacSHA512", which is what I want to use.  (I confess I don't know the 
> difference, if any, between SHA512 and HmacSHA512 in the context of hashing 
> passwords.)
> 
> I have used the following in my deployerConfigContext.xml file:
> 
>  class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder" 
> c:encodingAlgorithm="SHA1" p:characterEncoding="UTF-8" />
> 
> and it worked.  However, neither of the following two variants works:
> 
>  class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder" 
> c:encodingAlgorithm="HmacSHA512" p:characterEncoding="UTF-8" />
> 
> and
> 
>  class="org.jasig.cas.authentication.handler.DefaultPasswordEncoder" 
> c:encodingAlgorithm="SHA512" p:characterEncoding="UTF-8" />
> 
> Each of these results in something in the log such as:
> 
> 2014-07-10 15:13:01,251 INFO 
> [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit 
> trail record BEGIN
> =
> WHO: audit:unknown
> WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not 
> available
> ACTION: TICKET_GRANTING_TICKET_NOT_CREATED
> APPLICATION: CAS
> WHEN: Thu Jul 10 15:13:01 BST 2014
> CLIENT IP ADDRESS: 10.255.240.6
> SERVER IP ADDRESS: cas.zion.bt.co.uk
> =
> 
> This suggests that I have to provide an implementation of SHA512.  However, I 
> have no idea where to get one or how to make it available once I do!  (I 
> assume I would get a JAR file and put it in WEB-INF/lib - but I don't know 
> how I would specify the implementing class name in deployerConfigContext.xml.)
> 
> Also, even if I do find an implementation, what I really need is one that 
> lets me specify a salt for each password.
> 
> And I need to get the salt from the database containing the hashed passwords.
> 
> Is this an unrealistic or naively optimistic notion?  Should I really be 
> thinking about implementing a bean or other Java class and (somehow) using 
> that instead of CAS's built in JDBC options?  If I should, what's the 
> preferred/easiest approach?
> 
> Any advice would be much appreciated!
> 
> Many thanks.
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: 
> dkopyle...@unicon.net
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user


-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] Using SHA512

2014-07-10 Thread Nancy Snoke 
CAS documentation only shows using SHA1 or MD5 for encoding and mentions no 
other hashes as being available.

David Ohsie wrote an adapter to use Spring Security password encoders in CAS 
including salts.  You can find that here:  
https://groups.google.com/forum/#!topic/jasig-cas-dev/eZDRV4vbGzg


You could use that basic idea to tie in any of the spring securitypassword 
encoders.  I believe those only go up to SHA256.  Spring security also has the 
standard password encoder -- 1024 iterations of sha256 with 8 byte salt -- or 
the BCrypt encoder -- designed to be slow for the attacker and based off 
blowfish. 

See: 
http://security.stackexchange.com/questions/4781/do-any-security-experts-recommend-bcrypt-for-password-storage

http://docs.spring.io/spring-security/site/docs/3.1.x/apidocs/org/springframework/security/crypto/bcrypt/BCryptPasswordEncoder.html

http://stackoverflow.com/questions/17444258/how-to-use-new-passwordencoder-from-spring-security

http://docs.spring.io/spring-security/site/docs/3.1.x/apidocs/org/springframework/security/crypto/password/StandardPasswordEncoder.html


-Original Message-
From: Richard Wiseman [mailto:richard.wise...@bt.com] 
Sent: Thursday, July 10, 2014 9:05 AM
To: cas-user@lists.jasig.org
Subject: [cas-user] Using SHA512

Hi,

The CAS documentation <https://wiki.jasig.org/display/CASUM/JDBC> indicates 
that you can use any of the MACs listed on the JDK Javadoc 
<http://download.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA>
 for the password encoder's encodingAlgorithm attribute; this list includes 
"HmacSHA512", which is what I want to use.  (I confess I don't know the 
difference, if any, between SHA512 and HmacSHA512 in the context of hashing 
passwords.)

I have used the following in my deployerConfigContext.xml file:



and it worked.  However, neither of the following two variants works:



and



Each of these results in something in the log such as:

2014-07-10 15:13:01,251 INFO 
[com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail 
record BEGIN =
WHO: audit:unknown
WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available
ACTION: TICKET_GRANTING_TICKET_NOT_CREATED
APPLICATION: CAS
WHEN: Thu Jul 10 15:13:01 BST 2014
CLIENT IP ADDRESS: 10.255.240.6
SERVER IP ADDRESS: cas.zion.bt.co.uk
=

This suggests that I have to provide an implementation of SHA512.  However, I 
have no idea where to get one or how to make it available once I do!  (I assume 
I would get a JAR file and put it in WEB-INF/lib - but I don't know how I would 
specify the implementing class name in deployerConfigContext.xml.)

Also, even if I do find an implementation, what I really need is one that lets 
me specify a salt for each password.

And I need to get the salt from the database containing the hashed passwords.

Is this an unrealistic or naively optimistic notion?  Should I really be 
thinking about implementing a bean or other Java class and (somehow) using that 
instead of CAS's built in JDBC options?  If I should, what's the 
preferred/easiest approach?

Any advice would be much appreciated!

Many thanks.
--
You are currently subscribed to cas-user@lists.jasig.org as: 
nsn...@thegeneral.com To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user


-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

[cas-user] Using SHA512

2014-07-10 Thread Richard Wiseman 
Hi,

The CAS documentation  indicates 
that you can use any of the MACs listed on the JDK Javadoc 

 for the password encoder's encodingAlgorithm attribute; this list includes 
"HmacSHA512", which is what I want to use.  (I confess I don't know the 
difference, if any, between SHA512 and HmacSHA512 in the context of hashing 
passwords.)

I have used the following in my deployerConfigContext.xml file:



and it worked.  However, neither of the following two variants works:



and



Each of these results in something in the log such as:

2014-07-10 15:13:01,251 INFO 
[com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail 
record BEGIN
=
WHO: audit:unknown
WHAT: java.security.NoSuchAlgorithmException: SHA512 MessageDigest not available
ACTION: TICKET_GRANTING_TICKET_NOT_CREATED
APPLICATION: CAS
WHEN: Thu Jul 10 15:13:01 BST 2014
CLIENT IP ADDRESS: 10.255.240.6
SERVER IP ADDRESS: cas.zion.bt.co.uk
=

This suggests that I have to provide an implementation of SHA512.  However, I 
have no idea where to get one or how to make it available once I do!  (I assume 
I would get a JAR file and put it in WEB-INF/lib - but I don't know how I would 
specify the implementing class name in deployerConfigContext.xml.)

Also, even if I do find an implementation, what I really need is one that lets 
me specify a salt for each password.

And I need to get the salt from the database containing the hashed passwords.

Is this an unrealistic or naively optimistic notion?  Should I really be 
thinking about implementing a bean or other Java class and (somehow) using that 
instead of CAS's built in JDBC options?  If I should, what's the 
preferred/easiest approach?

Any advice would be much appreciated!

Many thanks.
-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user