Re: [WebDNA] Best practice re: password storage

This WebDNA talk-list message is from

2013


It keeps the original formatting.
numero = 110778
interpreted = N
texte = This is a multi-part message in MIME format. --------------010901030107010600090903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Oh, and aescrypt is pretty cool too http://www.aescrypt.com/ http://www.aescrypt.com/linux_aes_crypt.html I use it in server scripts, but assume it could probably be called from [shell] too. -Dan Strong http://www.DanStrong.com On 10/2/2013 2:07 PM, Dan Strong wrote: > Tom, > > Again, I don't know the answer to your direct question (I think only > WSC can answer it definitively) so I apologize if my input is > unhelpful, but I have taken a very keen interest in > encryption/security over the past few years and some of the things > I've been doing to harden WebDNA sites is stuff like this: > > [encrypt seed=[include > ^top-secret-seed-file.inc]&method=blowfish]salt-value.password-value[/encrypt] > "top-secret-seed-file.inc" contains a randomly generated string of > nonsense (256 chars/512 chars etc., whatever... basically a "key file" > > Not perfect of course since if someone hacks in they can probably > access /Globals/, but still better than hard-coding into pages. > > As an added step, I also re-generate the key file on another server > periodically then rsync it via ssh over to /Globals/ on target server. > Only plausible of course if you then decrypt/re-encrypt everything > that needs to be decrypted at some point in future, so ok if you're > just re-encrypting passwords in a database or simply using to > temporarily mask variables in a url or something simple like that, but > painful if you have a large/complex site with many things being encrypted. > > I have other thought/ideas/methods, but am pressed for time. Feel free > to contact me on or off list if you want to discuss further. > -Dan Strong > http://www.DanStrong.com > On 10/2/2013 1:47 PM, Tom Duke wrote: >> Stuart, >> >> >> > [URL][URL][ENCRYPT seed=secret]password-value[/ENCRYPT][/URL][/URL] >> >> >> Hi - that's what I have been using as well. The problem is that if >> the site is hacked the seed is accessible and all of the passwords >> are immediately exposed. >> >> One client in particular has been advised that passwords should only >> be stored after being salted and encrypted using a one-way hash. >> The hash should not be MD5 or SHA1. Their concern is that while a >> hack would be bad enough to deal with, it would be worse if they >> ended up exposing all of the users passwords, or were seen not to >> have taken measures to protect the passwords. >> >> I would like to continue to use [encrypt] but I can't figure out what >> algorithm is used if no seed is specified. >> >> - Tom >> >> >> >> --------------------------------------------------------- This >> message is sent to you because you are subscribed to the mailing list >> . To unsubscribe, E-mail to: archives: >> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >> support@webdna.us > --------------010901030107010600090903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Oh, and aescrypt is pretty cool too
http://www.aescrypt.com/
http://www.aescrypt.com/linux_aes_crypt.html

I use it in server scripts, but assume it could probably be called from [shell] too.
-Dan Stronghttp://www.DanStrong.com
On 10/2/2013 2:07 PM, Dan Strong wrote:
Tom,

Again, I don't know the answer to your direct question (I think only WSC can answer it definitively) so I apologize if my input is unhelpful, but I have taken a very keen interest in encryption/security over the past few years and some of the things I've been doing to harden WebDNA sites is stuff like this:

[encrypt seed=[include ^top-secret-seed-file.inc]&method=blowfish]salt-value.password-value[/encrypt]
"top-secret-seed-file.inc" contains a randomly generated string of nonsense (256 chars/512 chars etc., whatever... basically a "key file"

Not perfect of course since if someone hacks in they can probably access /Globals/, but still better than hard-coding into pages.

As an added step, I also re-generate the key file on another server periodically then rsync it via ssh over to /Globals/ on target server. Only plausible of course if you then decrypt/re-encrypt everything that needs to be decrypted at some point in future, so ok if you're just re-encrypting passwords in a database or simply using to temporarily mask variables in a url or something simple like that, but painful if you have a large/complex site with many things being encrypted.

I have other thought/ideas/methods, but am pressed for time. Feel free to contact me on or off list if you want to discuss further.
-Dan Stronghttp://www.DanStrong.com
On 10/2/2013 1:47 PM, Tom Duke wrote:
Stuart,


>  [URL][URL][ENCRYPT seed=secret]password-value[/ENCRYPT][/URL][/URL]


Hi - that's what I have been using as well.   The problem is that if the site is hacked the seed is accessible and all of the passwords are immediately exposed.

One client in particular has been advised that passwords should only be stored after being salted and encrypted using a one-way hash.   The hash should not be MD5 or SHA1.   Their concern is that while a hack would be bad enough to deal with, it would be worse if they ended up exposing all of the users passwords, or were seen not to have taken measures to protect the passwords.

I would like to continue to use [encrypt] but I can't figure out what algorithm is used if no seed is specified.

- Tom



--------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us


--------------010901030107010600090903-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] Best practice re: password storage (Dan Strong 2013)
  2. Re: [WebDNA] Best practice re: password storage (Tom Duke 2013)
  3. Re: [WebDNA] Best practice re: password storage (Dan Strong 2013)
  4. Re: [WebDNA] Best practice re: password storage (WebDNA 2013)
  5. Re: [WebDNA] Best practice re: password storage (Dan Strong 2013)
  6. Re: [WebDNA] Best practice re: password storage (WebDNA 2013)
  7. Re: [WebDNA] Best practice re: password storage (Dan Strong 2013)
  8. Re: [WebDNA] Best practice re: password storage (Dan Strong 2013)
  9. Re: [WebDNA] Best practice re: password storage (WebDNA 2013)
  10. Re: [WebDNA] Best practice re: password storage (Bill DeVaul 2013)
  11. Re: [WebDNA] Best practice re: password storage (Donovan Brooke 2013)
  12. Re: [WebDNA] Best practice re: password storage (Stuart Tremain 2013)
  13. Re: [WebDNA] Best practice re: password storage (Tom Duke 2013)
  14. Re: [WebDNA] Best practice re: password storage (Stuart Tremain 2013)
  15. Re: [WebDNA] Best practice re: password storage (Tom Duke 2013)
  16. Re: [WebDNA] Best practice re: password storage (Dan Strong 2013)
  17. Re: [WebDNA] Best practice re: password storage (Dan Strong 2013)
  18. Re: [WebDNA] Best practice re: password storage (Stuart Tremain 2013)
  19. Re: [WebDNA] Best practice re: password storage (Tom Duke 2013)
  20. Re: [WebDNA] Best practice re: password storage (Dan Strong 2013)
  21. Re: [WebDNA] Best practice re: password storage (Stuart Tremain 2013)
  22. [WebDNA] Best practice re: password storage (Tom Duke 2013)
This is a multi-part message in MIME format. --------------010901030107010600090903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Oh, and aescrypt is pretty cool too http://www.aescrypt.com/ http://www.aescrypt.com/linux_aes_crypt.html I use it in server scripts, but assume it could probably be called from [shell] too. -Dan Strong http://www.DanStrong.com On 10/2/2013 2:07 PM, Dan Strong wrote: > Tom, > > Again, I don't know the answer to your direct question (I think only > WSC can answer it definitively) so I apologize if my input is > unhelpful, but I have taken a very keen interest in > encryption/security over the past few years and some of the things > I've been doing to harden WebDNA sites is stuff like this: > > [encrypt seed=[include > ^top-secret-seed-file.inc]&method=blowfish]salt-value.password-value[/encrypt] > "top-secret-seed-file.inc" contains a randomly generated string of > nonsense (256 chars/512 chars etc., whatever... basically a "key file" > > Not perfect of course since if someone hacks in they can probably > access /Globals/, but still better than hard-coding into pages. > > As an added step, I also re-generate the key file on another server > periodically then rsync it via ssh over to /Globals/ on target server. > Only plausible of course if you then decrypt/re-encrypt everything > that needs to be decrypted at some point in future, so ok if you're > just re-encrypting passwords in a database or simply using to > temporarily mask variables in a url or something simple like that, but > painful if you have a large/complex site with many things being encrypted. > > I have other thought/ideas/methods, but am pressed for time. Feel free > to contact me on or off list if you want to discuss further. > -Dan Strong > http://www.DanStrong.com > On 10/2/2013 1:47 PM, Tom Duke wrote: >> Stuart, >> >> >> > [url][url][ENCRYPT seed=secret]password-value[/ENCRYPT][/URL][/URL] >> >> >> Hi - that's what I have been using as well. The problem is that if >> the site is hacked the seed is accessible and all of the passwords >> are immediately exposed. >> >> One client in particular has been advised that passwords should only >> be stored after being salted and encrypted using a one-way hash. >> The hash should not be MD5 or SHA1. Their concern is that while a >> hack would be bad enough to deal with, it would be worse if they >> ended up exposing all of the users passwords, or were seen not to >> have taken measures to protect the passwords. >> >> I would like to continue to use [encrypt] but I can't figure out what >> algorithm is used if no seed is specified. >> >> - Tom >> >> >> >> --------------------------------------------------------- This >> message is sent to you because you are subscribed to the mailing list >> . To unsubscribe, E-mail to: archives: >> http://mail.webdna.us/list/talk@webdna.us Bug Reporting: >> support@webdna.us > --------------010901030107010600090903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Oh, and aescrypt is pretty cool too
http://www.aescrypt.com/
http://www.aescrypt.com/linux_aes_crypt.html

I use it in server scripts, but assume it could probably be called from [shell] too.
-Dan Stronghttp://www.DanStrong.com
On 10/2/2013 2:07 PM, Dan Strong wrote:
Tom,

Again, I don't know the answer to your direct question (I think only WSC can answer it definitively) so I apologize if my input is unhelpful, but I have taken a very keen interest in encryption/security over the past few years and some of the things I've been doing to harden WebDNA sites is stuff like this:

[encrypt seed=[include ^top-secret-seed-file.inc]&method=blowfish]salt-value.password-value[/encrypt]
"top-secret-seed-file.inc" contains a randomly generated string of nonsense (256 chars/512 chars etc., whatever... basically a "key file"

Not perfect of course since if someone hacks in they can probably access /Globals/, but still better than hard-coding into pages.

As an added step, I also re-generate the key file on another server periodically then rsync it via ssh over to /Globals/ on target server. Only plausible of course if you then decrypt/re-encrypt everything that needs to be decrypted at some point in future, so ok if you're just re-encrypting passwords in a database or simply using to temporarily mask variables in a url or something simple like that, but painful if you have a large/complex site with many things being encrypted.

I have other thought/ideas/methods, but am pressed for time. Feel free to contact me on or off list if you want to discuss further.
-Dan Stronghttp://www.DanStrong.com
On 10/2/2013 1:47 PM, Tom Duke wrote:
Stuart,


>  [url][url][ENCRYPT seed=secret]password-value[/ENCRYPT][/URL][/URL]


Hi - that's what I have been using as well.   The problem is that if the site is hacked the seed is accessible and all of the passwords are immediately exposed.

One client in particular has been advised that passwords should only be stored after being salted and encrypted using a one-way hash.   The hash should not be MD5 or SHA1.   Their concern is that while a hack would be bad enough to deal with, it would be worse if they ended up exposing all of the users passwords, or were seen not to have taken measures to protect the passwords.

I would like to continue to use [encrypt] but I can't figure out what algorithm is used if no seed is specified.

- Tom



--------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us


--------------010901030107010600090903-- Dan Strong

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Nesting format tags (1997) WebCat2b13MacPlugIn - [shownext method=post] ??? (1997) SQL Error: 00000 (2004) Bookmarked URL with cart (1998) Migrating to NT (1997) re:check boxes (1997) Draft Manual, Tutorial, and more (1997) [WebDNA] Silly question (2009) WebCat2b13MacPlugIn - [include] doesn't allow creator (1997) Limit on nested [ShowIf]'s? (1997) Date/Time format problems (1997) Problems with WebCat (2000) Weird Math and SV (1997) .. more on sliding discounts... (1997) Plugin or CGI or both (1997) free "Image Viewer" widget (2004) WebCat2b13MacPlugIn - [include] doesn't allow creator (1997) Max Record length restated as maybe bug (1997) WebCatalog Features (1997) Webcat no longer supported? (2006)