Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

reading back checksum/secure

 [1/12] from: carlos:lorenz:bol at: 21-Oct-2003 16:42


Hello list, Considering the following code, how can I get :pwd back in plain English?
>> pwd: ask "Enter password: "
Enter password: mypass == "mypass"
>> write %password.txt checksum/secure pwd >> pwd: read %password.txt
== "'FJ$6&[/^Q8^[&" Thanks Carlos Lorenz

 [2/12] from: andreas:bolka:gmx at: 21-Oct-2003 21:10


Tuesday, October 21, 2003, 8:42:31 PM, Carlos wrote:
> Considering the following code, how can I get :pwd back in plain > English?
<<quoted lines omitted: 4>>
>>> pwd: read %password.txt > == "'FJ$6&[/^Q8^[&"
you can't, and that's what one way hash algorithms are designed for. -- Best regards, Andreas

 [3/12] from: maarten:vrijheid at: 21-Oct-2003 21:42


You can't. Checksumming (hashing) is a one-way operation

 [4/12] from: joel:neely:fedex at: 21-Oct-2003 14:11


Hi, Carlos, You can't. See below. Carlos Lorenz wrote:
> Considering the following code, how can I get > :pwd back in plain English?
<<quoted lines omitted: 3>>
>> > == "'FJ$6&[/^Q8^[&"
Check the help for CHECKSUM:
>> ? checksum
USAGE: CHECKSUM data /tcp /secure /hash size /method word /key key-value DESCRIPTION: Returns a CRC or other type of checksum. CHECKSUM is a native value. ARGUMENTS: data -- Data to checksum (Type: any-string) REFINEMENTS: /tcp -- Returns an Internet TCP 16-bit checksum. /secure -- Returns a cryptographically secure checksum. /hash -- Returns a hash value size -- Size of the hash table (Type: integer) /method -- Method to use word -- Method (Type: word) /key -- Returns keyed HMAC value key-value -- Key to use (Type: any-string) The description "cryptographically secure" means that it is intended to be infeasably difficult to reverse the computation. -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Enron Accountingg in a Nutshell: 1c=$0.01=($0.10)**2=(10c)**2=100c=$1

 [5/12] from: carlos:lorenz:bol at: 21-Oct-2003 18:27


Joel, I got it. That's exactly what I was looking for. The impossibility of getting back what was passed to checksum makes it ideal for login routines Thanks Carlos Em Ter 21 Out 2003 17:11, Joel Neely escreveu:

 [6/12] from: carlos:lorenz:bol at: 21-Oct-2003 18:25


Andreas, Maarten Is it secure to pass a checksum/secure value on a URL I mean when GET method is used on CGI? Carlos Em Ter 21 Out 2003 17:10, Andreas Bolka escreveu:

 [7/12] from: maximo:meteorstudios at: 21-Oct-2003 16:13


the reason for this, is that it protects you from the sysadmin himself. even he can't scan your password (unless he runs a mega-loop hashing and comparing all possible strings against the stored one) which can take hours, days or weeks to break. Which is why you should use long passwords on secure information (and change it from time to time). I am not sure how rebol hashes the password, but some algorythms make it possible for more than one password string to return the same hashed value. That is one reason it is not reversible. I'm not the expert, but these are little tidbits I've collected in my time ;-) -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.

 [8/12] from: SunandaDH:aol at: 21-Oct-2003 17:30


Carlos:
> Is it secure to pass a checksum/secure value on a URL > I mean when GET method is used on CGI?
Checksum/secure is proof against reverse engineering (given #{DE187642E6C75F60D10F29E52CAB54CDF676870D} you'd have a hard job working it backwards to the original string). But it isn't safe if the item you have checksumed is easily guessable. If I think you are using people's names, I can do a dictionary attack to find the matching checksum: foreach item ["carlos" "joel" "brett" "carl" "sunanda"] [ print [item checksum/secure item]] Cracked in moments! So be careful of the strings you decide to checksum. You might think checksum/secure form now/precise was safe. But it really isn't against a simple calendar attack. The other problem is that URLs pass through a host of intervening machines downstream of you and your server. So: http://www.myserver.com/mycgi.r?username=carlos&password=#{A8C40A306844B07D7B3 C733C3A9EF479ADAFAC1D} will be seen by many machines en route. To be truly safe, you'd want to make sure that password=#{A8C40A306844B07D7B3C733C3A9EF479ADAFAC1D} only works once -- on the next request it is a different checksum value. Otherwise, someone could simply spoof you by copying the value. Of course, that needs some extra messing around; and whether it's worth the bother depends on the value of your data, and how much you expect interlopers to come and attack you, Sunanda

 [9/12] from: tserpa:earthlink at: 21-Oct-2003 16:56


It would seem Carl's Cookbook entry "Strong Authentication Method" could serve as a useful example in this instance. http://www.rebol.net/cookbook/recipes/0019.html Ted

 [10/12] from: carlos:lorenz:bol at: 22-Oct-2003 14:51


Thank you Ted Em Ter 21 Out 2003 19:56, Ted Serpa escreveu:

 [11/12] from: carlos:lorenz:bol at: 22-Oct-2003 14:53


Sunanda, Your words enlightened some obscure points of the matter to me Thanks Carlos Em Ter 21 Out 2003 19:30, [SunandaDH--aol--com] escreveu:

 [12/12] from: rebol-list2:seznam:cz at: 23-Oct-2003 11:46


Hello SunandaDH, Tuesday, October 21, 2003, 11:30:24 PM, you wrote: Sac> The other problem is that URLs pass through a host of intervening machines Sac> downstream of you and your server. So: Sac> http://www.myserver.com/mycgi.r?username=carlos&password=#{A8C40A306844B07D7B3 Sac> C733C3A9EF479ADAFAC1D} Sac> will be seen by many machines en route. To be truly safe, you'd want to make Sac> sure that Sac> password=#{A8C40A306844B07D7B3C733C3A9EF479ADAFAC1D} Sac> only works once -- on the next request it is a different checksum value. Sac> Otherwise, someone could simply spoof you by copying the value. so it can work for example like this: Client -> Server -- wants connect Server -> Client -- sends session ID (SID) Client -> Server -- sends SID, checksum/secure join SID "mypass" Server compares if (checksum/secure join SID "mypass") is correct. This is good way how to prevent sending pure passwords thru web. This is trivial scenario. You can make it more difficult as well but than be careful to stay able to connect to your app:)) -- Best regards, rebOldes -----------------[ http://oldes.multimedia.cz/ ]

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted