gwoho@nntp-server.caltech.edu (g liu) (11/06/90)
i cant figure out how passwords are encrypted. it does not even seem very deterministic: i can look in the password file, change my password, change it back, and look again, and it changes. how are they encrypted, and how can it even work if the same password encryptes differently 2 differnt times? gwoho liu. .
jik@athena.mit.edu (Jonathan I. Kamens) (11/06/90)
In article <1990Nov5.185707.18709@nntp-server.caltech.edu>, gwoho@nntp-server.caltech.edu (g liu) writes: |> i cant figure out how passwords are encrypted. it does not even seem |> very deterministic: i can look in the password file, change my password, |> change it back, and look again, and it changes. how are they encrypted, |> and how can it even work if the same password encryptes differently |> 2 differnt times? I suggest you read the man page for "crypt" in section 3 of the manual. It addresses the "nondeterminism" you mention. In particular, the algorithm used to encrypt passwords take the initial password string and a two-character "salt" which can have any one of 4096 different possible values. To quote the man page, "The salt string is used to perturb the DES algorithm in one of 4096 different ways, after which the password is used as the key to encrypt repeatedly a constant string." When you change your password, the passwd(1) program semi-randomly chooses a salt to use with the newly encrypted entry in the passwd file. Therefore, if you change your password and then change it again to the same thing, the odds are that the encrypted string will end up different the second time because a different salt will be chosen. The purpose of the salt is to deter dictionary attacks against the passwd file. If there were no salt, then any particular word used as a password would always encrypt in the same way, so an attacker could encrypt all of the words in a dictionary and store them in a password dictionary, and then do fast string comparisons of the encrypted strings in his dictionary to the encrypted strings in the passwd file. However, because of the salts, the attacker either has to (a) encrypt all of the words in his dictionary using each of the 4096 salts, or (b) do the encryption of the entire dictionary on the fly as he tries to crack each password, based on the salt for that particular password. There was a time when the added protection of the salt made it "effectively impossible," or at least very improbable, to do a dictionary attack against a well-chosen password. However, in this age of mega-fast CPU's and mega-large disks, it isn't really enough anymore. ("Mega-fast" and "mega-large" are, of course, very specific terms with very technical meanings upon which I won't elaborate here :-). -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
kdq@demott.COM (Kevin D. Quitt) (11/06/90)
In article <3852@idunno.Princeton.EDU> pfalstad@roof.Princeton.EDU (Paul John Falstad) writes: > >Speaking of salts, try this on your system: > >ypcat passwd (or cat /etc/passwd) | cut -d: -f2 | cut -c1,2 | sort | >uniq -c | sort -n | tail > OK: 1 TJ 1 b4 1 bx 1 me 1 pt 1 qD 1 qe 1 yz 3 cy 19 NO -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last 96.37% of all statistics are made up.
darcy@druid.uucp (D'Arcy J.M. Cain) (11/06/90)
In article <1990Nov5.185707.18709@nntp-server.caltech.edu> gwoho@nntp-server.caltech.edu (g liu) writes: >i cant figure out how passwords are encrypted. it does not even seem >very deterministic: i can look in the password file, change my password, >change it back, and look again, and it changes. how are they encrypted, >and how can it even work if the same password encryptes differently >2 differnt times? >gwoho liu. >. Would you trust a password encryption scheme that you could figure out? See crypt(3C) and crypt(3X) for a short discussion on DES Encryption. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
ballerup@diku.dk (Per G|tterup) (11/07/90)
kdq@demott.COM (Kevin D. Quitt) writes: => In article <3852@idunno.Princeton.EDU> pfalstad@roof.Princeton.EDU (Paul John Falstad) writes: => > => >Speaking of salts, try this on your system: => > => >ypcat passwd (or cat /etc/passwd) | cut -d: -f2 | cut -c1,2 | sort | => >uniq -c | sort -n | tail => > => OK: => 1 TJ => 1 b4 => 1 bx => 1 me => 1 pt => 1 qD => 1 qe => 1 yz => 3 cy => 19 NO => -- => _ => Kevin D. Quitt demott!kdq kdq@demott.com => DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 => VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last => 96.37% of all statistics are made up. On our system it looks like this: 3 Vo 3 WH 3 Yo 3 Zo 3 sX 3 vL 3 zF 10 CL 19 NO 22 * -- | Per Gotterup | "The most merciful thing in the | | Student, DIKU (Inst. of Comp. Sci.) | world, I think, is the inability | | University of Copenhagen, Denmark | of the human mind to correlate all | | Internet: ballerup@freja.diku.dk | its contents." - H.P. Lovecraft - |
adeboer@gjetor.geac.COM (Anthony DeBoer) (11/08/90)
> In article <3852@idunno.Princeton.EDU> pfalstad@roof.Princeton.EDU (Paul John Falstad) writes: (stuff deleted) > 1 yz > 3 cy > 19 NO In article <1990Nov7.105055.26178@diku.dk> ballerup@diku.dk (Per G|tterup) writes: >On our system it looks like this: > 3 Vo > 3 WH > 3 Yo > 3 Zo > 3 sX > 3 vL > 3 zF > 10 CL > 19 NO > 22 * So did you folks check how many accounts are blocked with the word "NOLOGIN" in the password field, or with an asterisk? (I almost suspect the ten "CL"'s might be "CLOSED" accounts :-) Other than that, the distribution looks pretty flat. -- Anthony DeBoer - NAUI #Z8800 adeboer@gjetor.geac.com Programmer, GEAC J&E Systems Ltd. uunet!jtsv16!geac!gjetor!adeboer Toronto, Ontario, Canada #include <std.random.opinions.disclaimer>
olapw@olgb1.oliv.co.uk (Tony Walton) (11/08/90)
kdq@demott.COM (Kevin D. Quitt) writes: >In article <3852@idunno.Princeton.EDU> pfalstad@roof.Princeton.EDU (Paul John Falstad) writes: >> >>Speaking of salts, try this on your system: >> >>ypcat passwd (or cat /etc/passwd) | cut -d: -f2 | cut -c1,2 | sort | >>uniq -c | sort -n | tail >> >OK: > 1 TJ > 1 b4 > 1 bx > 1 me > 1 pt > 1 qD > 1 qe > 1 yz > 3 cy > 19 NO Have you, perhaps, got a lot of logins (possibly even 19 of them) which are "locked out" because the system admin has put "NO PASSWORD" (or something else similarly negative :-) ) in the password field? I get 1 *n 1 FB 1 Zf 1 vC 1 /2 1 Gs 1 c0 1 vV 1 /p 1 H. 1 c8 1 w/ 1 /z 1 Hj 1 cS 1 wX 1 0A 1 IH 1 f5 1 xA 1 0z 1 Ke 1 jG 1 xR 1 5Q 1 Kq 1 jm 1 xk 1 6J 1 Kw 1 nN 1 zP 1 7H 1 Rh 1 oR 4 NP 1 8Z 1 SA 1 qg 6 *L 1 90 1 SL 1 th 29 np 1 Cc 1 Tl 1 u1 and guess what - there are 29 locked logins, flagged by having a password field of "np" (looks like one *np* in there, as well). -- Think of salad days, they were folly and fun, they were good, they were young
volpe@camelback.crd.ge.com (Christopher R Volpe) (11/08/90)
In article <1990Nov6.151444.3409@druid.uucp>, darcy@druid.uucp (D'Arcy J.M. Cain) writes: |> |>Would you trust a password encryption scheme that you could figure out? |>See crypt(3C) and crypt(3X) for a short discussion on DES Encryption. The original poster said he couldn't figure out *how* passwords are encrypted, not how to decrypt them. I wouldn't trust a password encryption scheme that *relied* upon an attacker's inability to figure out *how* the encryption is done. You should *always* assume the enemy knows your encryption algorithm. Only the key is assumed secret. |> |>-- |>D'Arcy J.M. Cain (darcy@druid) | |>D'Arcy Cain Consulting | I support gun control. |>West Hill, Ontario, Canada | Let's start with the government! |>+ 416 281 6094 | ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
teb@uqun38.nixdorf.de (Tobias Brueck) (11/08/90)
gwoho@nntp-server.caltech.edu (g liu) writes: >i cant figure out how passwords are encrypted. it does not even seem >very deterministic: i can look in the password file, change my password, >change it back, and look again, and it changes. how are they encrypted, >and how can it even work if the same password encryptes differently >2 differnt times? >gwoho liu. It's very simple . The password encryption is a "one-way-encryption" . The first two letters of the encrypted password (EP) are used for more difference on the Data-Encryption-Standard (DES) . So you have 4096 (64*64) differnt kinds of the same EP . If you type in your password the software will use the first two letters of EP for encryption your password and compare to the old . If you type in a new and then the old password it will produced two new first letters by random . Hope that help , Tobias ****** I still havn't found , what I'm looking for ****** ============================================================================= | Tobias Brueck | Siemens-Nixdorf-Informationssysteme AG | WIF-382 | | D-W4790 Paderborn | Heinz-Nixdorf-Ring | Phone: inter-5251-10-5815 | | Federal Republic of Germany | Republique Federale d'Allemagne | ============================================================================= | europe: eunet : ..!unido!nixpbe!brueck.pad | brueck.pad@nixdorf.com... | | usa: usenet: ..!linus!nixbur!brueck.pad | | =============================================================================
J.G.Hall@newcastle.ac.uk (Jon Hall) (11/09/90)
In article <13507@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >In article <1990Nov6.151444.3409@druid.uucp>, darcy@druid.uucp (D'Arcy >J.M. Cain) writes: >|> >|>Would you trust a password encryption scheme that you could figure out? >|>See crypt(3C) and crypt(3X) for a short discussion on DES Encryption. > >The original poster said he couldn't figure out *how* passwords >are encrypted, not how to decrypt them. > >I wouldn't trust a password encryption scheme that *relied* upon >an attacker's inability to figure out *how* the encryption is done. >You should *always* assume the enemy knows your encryption algorithm. >Only the key is assumed secret. > I beg to differ. The source for a passwd is widely available (including key), the difficulty (IMHO) is inverting the encryption algorithm to come up with a sensible password. (note sensible, not original). Have I picked up this thread correctly? > >================== >Chris Volpe >G.E. Corporate R&D >volpecr@crd.ge.com --jon ARPA : j.g.hall@newcastle.ac.uk JANET: j.g.hall@uk.ac.newcastle UUCP : ...!ukc!newcastle.ac.uk!j.g.hall PHONE: +44 91 222 7957 SNAIL: Computing Laboratory, University of Newcastle upon Tyne, UK, NE1 7RU
fwp1@CC.MsState.Edu (Frank Peters) (11/10/90)
In article <1990Nov9.095039.20561@newcastle.ac.uk> J.G.Hall@newcastle.ac.uk (Jon Hall) writes: In article <13507@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >In article <1990Nov6.151444.3409@druid.uucp>, darcy@druid.uucp (D'Arcy >J.M. Cain) writes: >|> >|>Would you trust a password encryption scheme that you could figure out? >|>See crypt(3C) and crypt(3X) for a short discussion on DES Encryption. > >The original poster said he couldn't figure out *how* passwords >are encrypted, not how to decrypt them. > >I wouldn't trust a password encryption scheme that *relied* upon >an attacker's inability to figure out *how* the encryption is done. >You should *always* assume the enemy knows your encryption algorithm. >Only the key is assumed secret. > I beg to differ. The source for a passwd is widely available (including key), the difficulty (IMHO) is inverting the encryption algorithm to come up with a sensible password. (note sensible, not original). Have I picked up this thread correctly? No. The 'key' Christopher was referring to is your plain text password. Put another way, the only thing you can reasonably assume that a cracker doesn't know about your password is the password itself. You should assume that he/she has the encrypted password and the algorithm used to generate it. -- -- Frank Peters Internet: fwp1@CC.MsState.Edu Bitnet: FWP1@MsState Phone: (601)325-2942 FAX: (601)325-8921
clarke@ives.cs.colostate.edu (Charles Clarke) (11/11/90)
For the passwords, the 'key' is easily obtainable. It is the salt (first two letters of the encrypted password for those of you who missed that). The password (unencrypted) is the plain text. The program encrypts your password using the key and a modified DES. It then compares this with what is stored for you in the passwd file. As was pointed out, you do not care who knows the encryption algorithm (in this case, you do not care who knows about the key either), the only thing you need to worry about is someone knowing a decryption algorithm or having the information of what can produce your encrypted password given your salt. Note that this may be several strings, not just your password. Looking at the source for crypt(3) is a way to see what the modified DES looks like, but expect to get a headache. Happy hacking! charles
schriste@uceng.UC.EDU (Steven V. Christensen) (11/11/90)
clarke@ives.cs.colostate.edu (Charles Clarke) writes: >For the passwords, the 'key' is easily obtainable. It is the salt .... >As was pointed out, you do not care who knows the encryption algorithm >(in this case, you do not care who knows about the key either) >Looking at the source for crypt(3) is a way to see what the modified DES >looks like, but expect to get a headache. A though just occurring--- since the sources for the encryption algorithms are available, why hasn't anyone written a decrypter? Is the algorithm that "one way"ish? >Happy hacking! >charles Steven -- Steven V. Christensen U.C. College of Eng. schriste@uceng.uc.edu For the adventurous: svc@elf0.uucp
jik@athena.mit.edu (Jonathan I. Kamens) (11/12/90)
In article <11101@ccncsu.ColoState.EDU>, clarke@ives.cs.colostate.edu (Charles Clarke) writes: |> For the passwords, the 'key' is easily obtainable. It is the salt |> (first two letters of the encrypted password for those of you who missed that). |> |> The password (unencrypted) is the plain text. The program encrypts your |> password using the key and a modified DES. It then compares this with |> what is stored for you in the passwd file. Methinks you need to get your terminology straightened out, because, simply put, this is wrong. The word "key" refers to the password, not to the two-letter salt. If you don't believe me, look at the man page for crypt(3), which uses the words "key" and "salt" in this way, not in the way you have claimed above. Furthermore, in cryptological circles (in which I do not claim to be an expert, but I do know *something* about cryptology), "key" is used to refer to the private information possessed by the user attempting to authenticate himself; in this case, that private information is the password. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
jik@athena.mit.edu (Jonathan I. Kamens) (11/12/90)
In article <6686@uceng.UC.EDU>, schriste@uceng.UC.EDU (Steven V. Christensen) writes: |> A though just occurring--- since the sources for the encryption algorithms |> are available, why hasn't anyone written a decrypter? Is the algorithm that |> "one way"ish? Yes, crypt() is a one-way function. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
teb@uqun38.nixdorf.de (Tobias Brueck) (11/13/90)
clarke@ives.cs.colostate.edu (Charles Clarke) writes: >For the passwords, the 'key' is easily obtainable. It is the salt >(first two letters of the encrypted password for those of you who missed that). >The password (unencrypted) is the plain text. The program encrypts your >password using the key and a modified DES. It then compares this with >what is stored for you in the passwd file. This is not true . If you use this , you have to analyse the password-programm to get the key . The password is the key , with a plaintext of 0's or 1's . >Happy hacking! >charles ****** I still havn't found , what I'm looking for ****** ============================================================================= | Tobias Brueck | Siemens-Nixdorf-Informationssysteme AG | WIF-382 | | D-W4790 Paderborn | Heinz-Nixdorf-Ring | Phone: inter-5251-10-5815 | | Federal Republic of Germany | Republique Federale d'Allemagne | ============================================================================= | europe: eunet : ..!unido!nixpbe!brueck.pad | brueck.pad@nixdorf.com... | | usa: usenet: ..!linus!nixbur!brueck.pad | | =============================================================================
clarke@ives.cs.colostate.edu (Charles Clarke) (11/14/90)
Thanks to Jonathan for pointing out a possible mistake in my posting. The man page for crypt(3) differs from how I remember the routine, but as it has been several years, and due to system problems, I am unable to look at it currently,... Have to watch out for the old memory :-) However, Jonathan, something to add to the *something* you know about cryptography: a "key" does not have to be private. Public key cryptography has been around for a while. What you have is a public key for encryption and a private key for decryption. I believe the most famous is the one where you start with two large prime numbers and do some crunching to get the keys. (I won't put down what I remember about it because my memory might be failing :-) In an application like passwords where all you need is authentication and not decryption, with public key encryption, either the key or the plaintext can be the "private" information. To support your view, I believe DES is a conventional(not public key) encryption system in which case, with one piece of "private" information, it would have to be the key. BTW, usage in a man page does not qualify as a method for determination of "proper" usage. Though reading the man page suggests the salt as a key in an encryption process of the hashing algorithm. Anyway, the point that was originally meant still stands(as supported in another post by Jonathan: Knowing the encryption process and the encrypted password does not help much to determine the user's password. Yes, it can be done, but it is computationally expensive and almost infeasible with today's machines. Knowing additional information like how long it is and whether or not it has special symbols in it brings it down to doable today(I have seen it done. Before you ask, it was a case of a forgotten root password, not "cracking" someone else's). Enjoy! charles