On Dec 21, 2011, at 5:19 PM, Grigore Dolghin wrote:
Bottom line: stick to industry-proven solutions. Every single time. No
matter if it's storing passwords, or using sql parameters instead
concatenating the sql and checking for invalid input (this was discussed a
while ago). Stick to
On Fri, Dec 23, 2011 at 4:02 PM, Ed Leafe e...@leafe.com wrote:
On Dec 21, 2011, at 5:19 PM, Grigore Dolghin wrote:
Bottom line: stick to industry-proven solutions. Every single time. No
matter if it's storing passwords, or using sql parameters instead
concatenating the sql and checking for
On Tue, Dec 20, 2011, at 04:16 PM, Ed Leafe wrote:
On Dec 20, 2011, at 4:02 PM, MB Software Solutions, LLC 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
There was/is an old trick called irreversible encryption. It's used by
Unix/Linux, I believe.
On Wed, Dec 21, 2011 at 6:02 AM, MB Software Solutions, LLC
mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
As you might have seen from a previous thread, I was looking at using
the checksum via
Hi John
Its too late for my main product but for future use I would like to see the
code please. I use two fields currently, one with the length in.
Al
-Original Message-
I have a routine which pads the password to a fixed length of, say, 20
characters with a standard string of
On Dec 21, 2011, at 5:54 AM, Man-wai Chang wrote:
There was/is an old trick called irreversible encryption. It's used by
Unix/Linux, I believe.
That's what hashing is: a one-way process that produces a value that
cannot be used to re-create the original.
-- Ed Leafe
On Dec 20, 2011, at 9:04 PM, MB Software Solutions, LLC wrote:
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
I defy anyone to recover the password from the stored value :-).
There is a big risk of collision using your method.
As the result set is composed of only 65128 different values,
it doesn't take a long time to input in the routine a string whose result
will be the same value as the stored one
On 12/21/2011 5:15 PM, Gérard Lochon wrote:
I defy anyone to recover the password from the stored value :-).
There is a big risk of collision using your method.
As the result set is composed of only 65128 different values,
it doesn't take a long time to input in the routine a string whose
On Wed, Dec 21, 2011 at 3:33 PM, MB Software Solutions, LLC
mbsoftwaresoluti...@mbsoftwaresolutions.com wrote:
On 12/21/2011 5:15 PM, Gérard Lochon wrote:
I defy anyone to recover the password from the stored value :-).
There is a big risk of collision using your method.
As the
From: MB Software Solutions
I defy anyone to recover the password from the stored value :-).
There is a big risk of collision using your method.
As the result set is composed of only 65128 different values,
it doesn't take a long time to input in the routine a string whose result
will be
Could you explain why there can only be 65128 different values? I still
maintain that it would be extremely difficult to recover the password from
the stored numerical value :-)
John Weller
01380 723235
07976 393631
-Original Message-
From: profoxtech-boun...@leafe.com
On 12/21/2011 6:00 PM, Fred Taylor wrote:
http://en.wikipedia.org/wiki/Collision_(computer_science)
Thanks, Fred.
--
Mike Babcock, MCP
MB Software Solutions, LLC
President, Chief Software Architect
http://mbsoftwaresolutions.com
http://fabmate.com
http://twitter.com/mbabcock16
On 12/21/2011 6:10 PM, John Weller wrote:
Could you explain why there can only be 65128 different values? I still
maintain that it would be extremely difficult to recover the password from
the stored numerical value :-)
He's not saying they could guess it; he's saying that my password and
On Dec 21, 2011, at 5:10 PM, John Weller wrote:
Could you explain why there can only be 65128 different values? I still
maintain that it would be extremely difficult to recover the password from
the stored numerical value :-)
That's a different issue than collision. With collision,
I wonder when people will learn that there are guys whose only job is to
think on these things. And the outcome cannot be beaten by in-house
solutions no matter what, first because they do that 8 hours a day, 5 days a
week. An inhouse solution simply cannot compete. Not to mention that usually
the
- Original Message -
From: John Weller j...@johnweller.co.uk
Could you explain why there can only be 65128 different values?
At the first turn , you have 256 seeding possibilities. You randomize.
Then you multiply this value (between 0 and 1) by an ascii code (between 0
and 255),
Since I wrote my last message (1h 10 minutes ago) I wrote a quick'n'dirty
program that looks for alternate strings. Guess what, it finds the string as
fast as even by SET DECIMALS TO 18 I couldn't measure the execution time.
I used my name as a password and padded it with ABCDE up to 20 chars
On 12/21/2011 6:12 PM, Ed Leafe wrote:
That's a different issue than collision. With collision, you don't need
to know the original password; instead, you have a one in N chance of a
random string matching the password, where N is the total number of possible
values. So I could write
Well that opened my eyes, thanks guys! I wrote a quick and dirty test along
the lines of those suggested before I read any of the responses after
Gerard's initial one and was appalled at the results :-). What I thought
was reasonably secure is most definitely not! I also realised that my
Thanks Gerard, I should have thought it through a bit better :-)
John Weller
01380 723235
07976 393631
-Original Message-
From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com]
On Behalf
Of Gérard Lochon
Sent: 21 December 2011 23:58
To: profoxt...@leafe.com
On 12/21/2011 7:32 PM, Grigore Dolghin wrote:
Since I wrote my last message (1h 10 minutes ago) I wrote a quick'n'dirty
program that looks for alternate strings. Guess what, it finds the string as
fast as even by SET DECIMALS TO 18 I couldn't measure the execution time.
I used my name as a
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
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
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
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
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
On Dec 20, 2011, at 4:25 PM, MB Software Solutions, LLC wrote:
That's what I'm attempting to dobut 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
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 dobut 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
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
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
31 matches
Mail list logo
