Index
2011-12-20 17:02MB Software Solutions, LLC : Alternatives to storing a user's password in your database
2011-12-20 17:16Ed Leafe : Re: Alternatives to storing a user's password in your database
2011-12-20 17:17John Weller : RE: Alternatives to storing a user's password in your database
2011-12-20 17:25MB Software Solutions, LLC : Re: Alternatives to storing a user's password in your database
2011-12-20 17:25MB Software Solutions, LLC : Re: Alternatives to storing a user's password in your database
2011-12-20 17:26Tracy Pearson : RE: Alternatives to storing a user's password in your database
2011-12-20 17:35Ed Leafe : Re: Alternatives to storing a user's password in your database
2011-12-20 22:04MB Software Solutions, LLC : Re: Alternatives to storing a user's password in your database
2011-12-21 00:41Christof Wollenhaupt : Re: Alternatives to storing a user's password in your database
2011-12-21 01:43MB Software Solutions, LLC : Re: Alternatives to storing a user's password in your database
Back to top
Alternatives to storing a user's password in your database

Author: MB Software Solutions, LLC

Posted: 2011-12-20 17:02:08   Link

As you might have seen from a previous thread, I was looking at using

the checksum via SYS(2007) or Craig Boyd's CRC() function (from his

vfpencryption71.fll) to store the person's password. I've never liked

saving the actual password in the database.

Is anyone else here doing something similar and can comment on what they

use/do?

Thanks,

--Mike

--

Mike Babcock, MCP

MB Software Solutions, LLC

President, Chief Software Architect

http://mbsoftwaresolutions.com

http://fabmate.com

http://twitter.com/mbabcock16

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/4EF105E0.4040805@mbsoftwaresolutions.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 MB Software Solutions, LLC
Back to top
Re: Alternatives to storing a user's password in your database

Author: Ed Leafe

Posted: 2011-12-20 17:16:05   Link

On Dec 20, 2011, at 4:02 PM, MB Software Solutions, LLC wrote:

> As you might have seen from a previous thread, I was looking at using

> the checksum via SYS(2007) or Craig Boyd's CRC() function (from his

> vfpencryption71.fll) to store the person's password. I've never liked

> saving the actual password in the database.

You should never store passwords. Instead, you should store a hash of the password. When the user logs in, you hash the supplied password and compare it to the stored hash. If they match, the password was valid.

-- Ed Leafe

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/C01F0712-DCF5-448E-A37A-433B06B8ABB0@leafe.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 Ed Leafe
Back to top
RE: Alternatives to storing a user's password in your database

Author: John Weller

Posted: 2011-12-20 17:17:30   Link

I have a routine which pads the password to a fixed length of, say, 20

characters with a standard string of punctuation. I then take the ASCII

value of the first character and use it as a seed for a RAND() function. I

take the resulting fraction and multiply it by the ASCII value of the second

character then take the integer value and use it as the seed for another

RAND() repeating until the end of the string is reached. The final fraction

is then multiplied by 10,000,000 and the integer stored. When a user enters

their password I repeat the process and compare the result with the stored

value. I defy anyone to recover the password from the stored value :-).

If you want the code let me know.

John Weller

01380 723235

07976 393631

>

> Is anyone else here doing something similar and can comment on what they

> use/do?

>

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/006c01ccbf65$2b5d2af0$821780d0$@co.uk

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 John Weller
Back to top
Re: Alternatives to storing a user's password in your database

Author: MB Software Solutions, LLC

Posted: 2011-12-20 17:25:40   Link

On 12/20/2011 5:17 PM, John Weller wrote:

> I have a routine which pads the password to a fixed length of, say, 20

> characters with a standard string of punctuation. I then take the ASCII

> value of the first character and use it as a seed for a RAND() function. I

> take the resulting fraction and multiply it by the ASCII value of the second

> character then take the integer value and use it as the seed for another

> RAND() repeating until the end of the string is reached. The final fraction

> is then multiplied by 10,000,000 and the integer stored. When a user enters

> their password I repeat the process and compare the result with the stored

> value. I defy anyone to recover the password from the stored value :-).

>

> If you want the code let me know.

Good Lord, man....impressive!

--

Mike Babcock, MCP

MB Software Solutions, LLC

President, Chief Software Architect

http://mbsoftwaresolutions.com

http://fabmate.com

http://twitter.com/mbabcock16

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/4EF10B64.7000805@mbsoftwaresolutions.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 MB Software Solutions, LLC
Back to top
Re: Alternatives to storing a user's password in your database

Author: MB Software Solutions, LLC

Posted: 2011-12-20 17:25:44   Link

On 12/20/2011 5:16 PM, Ed Leafe wrote:

> You should never store passwords. Instead, you should store a hash of the password. When the user logs in, you hash the supplied password and compare it to the stored hash. If they match, the password was valid.

That's what I'm attempting to do....but with a checksum. So I should

use the HASH() function instead and store the 64 byte character string

instead of the 10 digit # generated from the checksum?

--

Mike Babcock, MCP

MB Software Solutions, LLC

President, Chief Software Architect

http://mbsoftwaresolutions.com

http://fabmate.com

http://twitter.com/mbabcock16

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/4EF10B68.8010509@mbsoftwaresolutions.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 MB Software Solutions, LLC
Back to top
RE: Alternatives to storing a user's password in your database

Author: Tracy Pearson

Posted: 2011-12-20 17:26:00   Link

MB Software Solutions, LLC wrote on 2011-12-20:

> As you might have seen from a previous thread, I was looking at using

> the checksum via SYS(2007) or Craig Boyd's CRC() function (from his

> vfpencryption71.fll) to store the person's password. I've never liked

> saving the actual password in the database.

>

> Is anyone else here doing something similar and can comment on what they

> use/do?

>

> Thanks,

> --Mike

Mike,

It has been discussed around here. Several ideas came up. One that makes

since to me:

CRC(Password + Seed)

Another one was

CRC(SeedFunction(CRC(Password)))

Yeah, crazy. Depending on the first or last character of the CRC of the

password start a random number generator to get addition characters at a

predetermined length. Something about the possibility of different machines

might generate different random numbers.

Tracy Pearson

PowerChurch Software

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/001801ccbf66$5a46caa0$0ed45fe0$@powerchurch.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 Tracy Pearson
Back to top
Re: Alternatives to storing a user's password in your database

Author: Ed Leafe

Posted: 2011-12-20 17:35:29   Link

On Dec 20, 2011, at 4:25 PM, MB Software Solutions, LLC wrote:

> That's what I'm attempting to do....but with a checksum. So I should

> use the HASH() function instead and store the 64 byte character string

> instead of the 10 digit # generated from the checksum?

Depends on what you're using to generate the checksum. With only 10 digits it sounds like a high probability of collision. Also, how different would the checksums for 'aaaaaaaa' and 'aaaaaaab' be?

I used to use MD5 hash algorithms, but those are considered broken by security experts, so I switched to the SHA-2 hashes.

-- Ed Leafe

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/D420687B-2CC7-4B1C-B672-7FDEB74CC31A@leafe.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 Ed Leafe
Back to top
Re: Alternatives to storing a user's password in your database

Author: MB Software Solutions, LLC

Posted: 2011-12-20 22:04:33   Link

On 12/20/2011 5:35 PM, Ed Leafe wrote:

> On Dec 20, 2011, at 4:25 PM, MB Software Solutions, LLC wrote:

>

>> That's what I'm attempting to do....but with a checksum. So I should

>> use the HASH() function instead and store the 64 byte character string

>> instead of the 10 digit # generated from the checksum?

>

> Depends on what you're using to generate the checksum. With only 10 digits it sounds like a high probability of collision. Also, how different would the checksums for 'aaaaaaaa' and 'aaaaaaab' be?

>

> I used to use MD5 hash algorithms, but those are considered broken by security experts, so I switched to the SHA-2 hashes.

Craig's site lists these options for the HASH:

1 = SHA1 (a.k.a SHA160)

2 = SHA256

3 = SHA384

4 = SHA512 *Default

5 = MD5

6 = RIPEMD128

7 = RIPEMD160

So your SHA-2 is most likely like #4, SHA512? So I store the 128 byte

result?

--

Mike Babcock, MCP

MB Software Solutions, LLC

President, Chief Software Architect

http://mbsoftwaresolutions.com

http://fabmate.com

http://twitter.com/mbabcock16

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/4EF14CC1.9050603@mbsoftwaresolutions.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 MB Software Solutions, LLC
Back to top
Re: Alternatives to storing a user's password in your database

Author: Christof Wollenhaupt

Posted: 2011-12-21 00:41:17   Link

If you use CRC functions you should salt the value. That is adding a few

application specific characters before or after the password, then passing

the result to SYS(2007) - or whatever else. Adding more sophisticated

functions to calculate the hash value would be possible but not add

security value. Once you went beyond storing the password, the application

(with code injection) becomes the weakest link, not cracking a password.

--

Christof

--- StripMime Report -- processed MIME parts ---

multipart/alternative

text/plain (text body -- kept)

text/html

---

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/CAL4QJhhGmUFzwcOK=bG5ptLrLP-XPB6--ObkZTBG5wgJ1fk1Ew@mail.gmail.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 Christof Wollenhaupt
Back to top
Re: Alternatives to storing a user's password in your database

Author: MB Software Solutions, LLC

Posted: 2011-12-21 01:43:47   Link

On 12/21/2011 12:41 AM, Christof Wollenhaupt wrote:

> If you use CRC functions you should salt the value. That is adding a few

> application specific characters before or after the password, then passing

> the result to SYS(2007) - or whatever else. Adding more sophisticated

> functions to calculate the hash value would be possible but not add

> security value. Once you went beyond storing the password, the application

> (with code injection) becomes the weakest link, not cracking a password.

>

That makes sense. Seems like me just getting and storing the CRC of

"<whatever prefix I choose here>" along with their password and then on

the login screen, comparing that same prefix + their entered password

against the stored value would be sufficient.

I see that approach as responsible. I'd like to hear someone give an

explanation as to why it wouldn't be (responsible).

Thanks,

--Mike

--

Mike Babcock, MCP

MB Software Solutions, LLC

President, Chief Software Architect

http://mbsoftwaresolutions.com

http://fabmate.com

http://twitter.com/mbabcock16

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://leafe.com/mailman/listinfo/profox

OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/4EF18023.2020603@mbsoftwaresolutions.com

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.

©2011 MB Software Solutions, LLC