talk@lists.collectionspace.org
WE HAVE SUNSET THIS LISTSERV - Join us at collectionspace@lyrasislists.org
View all threadsMore secure hashing of passwords in the CollectionSpace database
There was a posting this week on a library patron privacy mailing list (http://bit.ly/16povxW) that described some rather poor practices by library automation vendors in storing patron passwords. Many were -- at least as of early 2014 -- storing them as plain text in the database. I went looking into the CollectionSpace code to see what we were doing, and I found this createHash() function in the password reset code:
We're using MD5 with a hard-coded salt, which is okay but not really up to current day security practices.
A couple of years ago Jesse created an issue ticket (http://issues.collectionspace.org/browse/CSPACE-5400) to upgrade the hashing algorithm, and Aron posted some great links to articles on some of the current best practices. Do folks feel like this is a priority that we should address? (I'm voting for "yes" to be prioritized with other activities.)
Peter
Peter Murray
Assistant Director, Technology Services Development
LYRASIS
Peter.Murray@lyrasis.org
+1 678-235-2955
800.999.8558 x2955
Hi Peter,
This would certainly be a good thing to do, but I'd want to see it in
the context of other improvements that we'd be prioritizing it above. I
think that at this point, we need to be doing everything we can to promote
adoption of CSpace and increase the numbers of institutions and developers
in the CSpace community.
Without seeing the Lyrasis list of priorities (but knowing what my list
of priorities looks like), I'd tend to say that if the current security is
adequate, let's set this improvement aside for now in favor of other
improvements that will be much more conspicuous and perhaps more valuable
to potential CSpace adopters (e.g., a hosted version of CSpace, an audit
trail, field-level access restrictions, searching across record types,
hierarchical searching on authority terms, checkboxes on search results,
the ability to use externally maintained authorities, sticky templates,
being able to add media to authority records, a conservation treatment
procedure, a workable solution for maintaining home locations, the ability
to mark donors as anonymous, making "preferred image" work within the UI,
handling BC and BP dates properly, an inventory control procedure, typed
relationships between records, being able to make batch edits, and so on).
Interested to hear what others think,
Michael
Michael T. Black
Head of Research and Information Systems
Phoebe A. Hearst Museum of Anthropology
On Thu, Feb 5, 2015 at 10:59 AM, Peter Murray peter.murray@lyrasis.org
wrote:
There was a posting this week on a library patron privacy mailing list (
http://bit.ly/16povxW) that described some rather poor practices by
library automation vendors in storing patron passwords. Many were -- at
least as of early 2014 -- storing them as plain text in the database. I
went looking into the CollectionSpace code to see what we were doing, and I
found this createHash() function in the password reset code:
We're using MD5 with a hard-coded salt, which is okay but not really up to
current day security practices.
A couple of years ago Jesse created an issue ticket (
http://issues.collectionspace.org/browse/CSPACE-5400) to upgrade the
hashing algorithm, and Aron posted some great links to articles on some of
the current best practices. Do folks feel like this is a priority that we
should address? (I'm voting for "yes" to be prioritized with other
activities.)
Peter
Peter Murray
Assistant Director, Technology Services Development
LYRASIS
Peter.Murray@lyrasis.org
+1 678-235-2955
800.999.8558 x2955
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
I am more concerned with how authentication is done generally (Basic Auth).
We should really implement some token-based authentication, which would
also allow us to clean up some other things with how the UI could talk to
the services (rather than going through the app layer). Nevertheless, and
as Michael notes, it is up to the functional committee to prioritize this.
Patrick
From: Talk [mailto:talk-bounces@lists.collectionspace.org] *On
Behalf Of *Michael
Black
Sent: Friday, February 06, 2015 11:11 AM
To: Peter Murray
Cc: CollectionSpace Talk List
Subject: Re: [Talk] More secure hashing of passwords in the
CollectionSpace database
Hi Peter,
This would certainly be a good thing to do, but I'd want to see it in
the context of other improvements that we'd be prioritizing it above. I
think that at this point, we need to be doing everything we can to promote
adoption of CSpace and increase the numbers of institutions and developers
in the CSpace community.
Without seeing the Lyrasis list of priorities (but knowing what my list
of priorities looks like), I'd tend to say that if the current security is
adequate, let's set this improvement aside for now in favor of other
improvements that will be much more conspicuous and perhaps more valuable
to potential CSpace adopters (e.g., a hosted version of CSpace, an audit
trail, field-level access restrictions, searching across record types,
hierarchical searching on authority terms, checkboxes on search results,
the ability to use externally maintained authorities, sticky templates,
being able to add media to authority records, a conservation treatment
procedure, a workable solution for maintaining home locations, the ability
to mark donors as anonymous, making "preferred image" work within the UI,
handling BC and BP dates properly, an inventory control procedure, typed
relationships between records, being able to make batch edits, and so on).
Interested to hear what others think,
Michael
Michael T. Black
Head of Research and Information Systems
Phoebe A. Hearst Museum of Anthropology
On Thu, Feb 5, 2015 at 10:59 AM, Peter Murray peter.murray@lyrasis.org
wrote:
There was a posting this week on a library patron privacy mailing list (
http://bit.ly/16povxW) that described some rather poor practices by library
automation vendors in storing patron passwords. Many were -- at least as
of early 2014 -- storing them as plain text in the database. I went
looking into the CollectionSpace code to see what we were doing, and I
found this createHash() function in the password reset code:
We're using MD5 with a hard-coded salt, which is okay but not really up to
current day security practices.
A couple of years ago Jesse created an issue ticket (
http://issues.collectionspace.org/browse/CSPACE-5400) to upgrade the
hashing algorithm, and Aron posted some great links to articles on some of
the current best practices. Do folks feel like this is a priority that we
should address? (I'm voting for "yes" to be prioritized with other
activities.)
Peter
Peter Murray
Assistant Director, Technology Services Development
LYRASIS
Peter.Murray@lyrasis.org
+1 678-235-2955
800.999.8558 x2955
Talk mailing list
Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Peter,
Thanks for voicing your request and concerns on the Talk list. It's great to hear from new members of the community. It's really important that the Talk email list is not only an active and safe place to voice these kinds of requests, but also a place for collegial discussions of them.
As Patrick noted, this particular issue is something the FWG (Functional Working Group) needs to address. And as Michael noted, we've got a backlog of other issues that we'll need to consider as well. In my opinion, this particular issue would likely involve very little functional and engineering analysis and work, is limited in scope, and is inherently low-risk, so it might be something we could do sooner rather than later. Again, final word comes from the FWG.
Per Patrick's concern of Basic Auth, our recommendation that production CollectionSpace instances be deployed only as an HTTPS (TSL/SSL) applications mitigates most of the security related issues involving the Basic Auth authentication between the UI and Application layers. This doesn't address Patrick's issue related to the UI talking directly to the Services however.
-Richard
From: Talk talk-bounces@lists.collectionspace.org on behalf of Patrick Schmitz pschmitz@berkeley.edu
Sent: Friday, February 6, 2015 11:39 AM
To: Michael Black; Peter Murray
Cc: CollectionSpace Talk List
Subject: Re: [Talk] More secure hashing of passwords in the CollectionSpace database
I am more concerned with how authentication is done generally (Basic Auth). We should really implement some token-based authentication, which would also allow us to clean up some other things with how the UI could talk to the services (rather than going through the app layer). Nevertheless, and as Michael notes, it is up to the functional committee to prioritize this.
Patrick
From: Talk [mailto:talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org] On Behalf Of Michael Black
Sent: Friday, February 06, 2015 11:11 AM
To: Peter Murray
Cc: CollectionSpace Talk List
Subject: Re: [Talk] More secure hashing of passwords in the CollectionSpace database
Hi Peter,
This would certainly be a good thing to do, but I'd want to see it in the context of other improvements that we'd be prioritizing it above. I think that at this point, we need to be doing everything we can to promote adoption of CSpace and increase the numbers of institutions and developers in the CSpace community.
Without seeing the Lyrasis list of priorities (but knowing what my list of priorities looks like), I'd tend to say that if the current security is adequate, let's set this improvement aside for now in favor of other improvements that will be much more conspicuous and perhaps more valuable to potential CSpace adopters (e.g., a hosted version of CSpace, an audit trail, field-level access restrictions, searching across record types, hierarchical searching on authority terms, checkboxes on search results, the ability to use externally maintained authorities, sticky templates, being able to add media to authority records, a conservation treatment procedure, a workable solution for maintaining home locations, the ability to mark donors as anonymous, making "preferred image" work within the UI, handling BC and BP dates properly, an inventory control procedure, typed relationships between records, being able to make batch edits, and so on).
Interested to hear what others think,
Michael
Michael T. Black
Head of Research and Information Systems
Phoebe A. Hearst Museum of Anthropology
On Thu, Feb 5, 2015 at 10:59 AM, Peter Murray <peter.murray@lyrasis.orgmailto:peter.murray@lyrasis.org> wrote:
There was a posting this week on a library patron privacy mailing list (http://bit.ly/16povxW) that described some rather poor practices by library automation vendors in storing patron passwords. Many were -- at least as of early 2014 -- storing them as plain text in the database. I went looking into the CollectionSpace code to see what we were doing, and I found this createHash() function in the password reset code:
We're using MD5 with a hard-coded salt, which is okay but not really up to current day security practices.
A couple of years ago Jesse created an issue ticket (http://issues.collectionspace.org/browse/CSPACE-5400) to upgrade the hashing algorithm, and Aron posted some great links to articles on some of the current best practices. Do folks feel like this is a priority that we should address? (I'm voting for "yes" to be prioritized with other activities.)
Peter
Peter Murray
Assistant Director, Technology Services Development
LYRASIS
Peter.Murray@lyrasis.orgmailto:Peter.Murray@lyrasis.org
+1 678-235-2955tel:%2B1%20678-235-2955
800.999.8558 x2955tel:800.999.8558%20x2955
Talk mailing list
Talk@lists.collectionspace.orgmailto:Talk@lists.collectionspace.org
http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org
Thanks for everyone's thoughts. I probably should have clarified when I posted my initial message, but I'm coming from the perspective of the hosting team at LYRASIS, not the organizational home. So my interest was from that perspective, not from the organizational home's perspective and certainly not a hint to the functional working group that this should be prioritized over other things. My preliminary assessment also matches Richard's, and I'll add that this would probably be an easy itch for someone to scratch and submit the patches for review. (Whether I can scrounge up enough time to scratch that itch remains to be seen.)
Peter
On Feb 6, 2015, at 10:58 PM, Richard Millet <richard.millet@lyrasis.orgmailto:richard.millet@lyrasis.org> wrote:
Peter,
Thanks for voicing your request and concerns on the Talk list. It's great to hear from new members of the community. It's really important that the Talk email list is not only an active and safe place to voice these kinds of requests, but also a place for collegial discussions of them.
As Patrick noted, this particular issue is something the FWG (Functional Working Group) needs to address. And as Michael noted, we've got a backlog of other issues that we'll need to consider as well. In my opinion, this particular issue would likely involve very little functional and engineering analysis and work, is limited in scope, and is inherently low-risk, so it might be something we could do sooner rather than later. Again, final word comes from the FWG.
Per Patrick's concern of Basic Auth, our recommendation that production CollectionSpace instances be deployed only as an HTTPS (TSL/SSL) applications mitigates most of the security related issues involving the Basic Auth authentication between the UI and Application layers. This doesn't address Patrick's issue related to the UI talking directly to the Services however.
-Richard
From: Talk <talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org> on behalf of Patrick Schmitz <pschmitz@berkeley.edumailto:pschmitz@berkeley.edu>
Sent: Friday, February 6, 2015 11:39 AM
To: Michael Black; Peter Murray
Cc: CollectionSpace Talk List
Subject: Re: [Talk] More secure hashing of passwords in the CollectionSpace database
I am more concerned with how authentication is done generally (Basic Auth). We should really implement some token-based authentication, which would also allow us to clean up some other things with how the UI could talk to the services (rather than going through the app layer). Nevertheless, and as Michael notes, it is up to the functional committee to prioritize this.
Patrick
From: Talk [mailto:talk-bounces@lists.collectionspace.orgmailto:talk-bounces@lists.collectionspace.org] On Behalf Of Michael Black
Sent: Friday, February 06, 2015 11:11 AM
To: Peter Murray
Cc: CollectionSpace Talk List
Subject: Re: [Talk] More secure hashing of passwords in the CollectionSpace database
Hi Peter,
This would certainly be a good thing to do, but I'd want to see it in the context of other improvements that we'd be prioritizing it above. I think that at this point, we need to be doing everything we can to promote adoption of CSpace and increase the numbers of institutions and developers in the CSpace community.
Without seeing the Lyrasis list of priorities (but knowing what my list of priorities looks like), I'd tend to say that if the current security is adequate, let's set this improvement aside for now in favor of other improvements that will be much more conspicuous and perhaps more valuable to potential CSpace adopters (e.g., a hosted version of CSpace, an audit trail, field-level access restrictions, searching across record types, hierarchical searching on authority terms, checkboxes on search results, the ability to use externally maintained authorities, sticky templates, being able to add media to authority records, a conservation treatment procedure, a workable solution for maintaining home locations, the ability to mark donors as anonymous, making "preferred image" work within the UI, handling BC and BP dates properly, an inventory control procedure, typed relationships between records, being able to make batch edits, and so on).
Interested to hear what others think,
Michael
Michael T. Black
Head of Research and Information Systems
Phoebe A. Hearst Museum of Anthropology
On Thu, Feb 5, 2015 at 10:59 AM, Peter Murray <peter.murray@lyrasis.orgmailto:peter.murray@lyrasis.org> wrote:
There was a posting this week on a library patron privacy mailing list (http://bit.ly/16povxW) that described some rather poor practices by library automation vendors in storing patron passwords. Many were -- at least as of early 2014 -- storing them as plain text in the database. I went looking into the CollectionSpace code to see what we were doing, and I found this createHash() function in the password reset code:
We're using MD5 with a hard-coded salt, which is okay but not really up to current day security practices.
A couple of years ago Jesse created an issue ticket (http://issues.collectionspace.org/browse/CSPACE-5400) to upgrade the hashing algorithm, and Aron posted some great links to articles on some of the current best practices. Do folks feel like this is a priority that we should address? (I'm voting for "yes" to be prioritized with other activities.)
Peter
--
Peter Murray
Assistant Director, Technology Services Development
LYRASIS
Peter.Murray@lyrasis.orgmailto:Peter.Murray@lyrasis.org
+1 678-235-2955
800.999.8558 x2955