* Saving and Encoding Passwords @ 1999-11-16 0:00 Josh Highley 1999-11-17 0:00 ` Gisle S�lensminde ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Josh Highley @ 1999-11-16 0:00 UTC (permalink / raw) I'm writing an Ada program that checks email accounts. I'm storing the user name, password, and other info in a text file that my program references on startup. I obviously don't want to store the password unencoded. Thus, my question is how should I encrypt the password? Is there an Ada package that will do this? I thought of using the CPU id to encrypt the password, but I'm not sure how secure this would be and I haven't found an API function or any other method of retrieving the CPU id. Is there a typical/standard/accepted way of encoding passwords? Thanks, Josh Highley joshhighley@hotmail.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-16 0:00 Saving and Encoding Passwords Josh Highley @ 1999-11-17 0:00 ` Gisle S�lensminde 1999-11-17 0:00 ` Ted Dennison 1999-11-26 0:00 ` Florian Weimer 2 siblings, 0 replies; 10+ messages in thread From: Gisle S�lensminde @ 1999-11-17 0:00 UTC (permalink / raw) In article <38315e1a.0@silver.truman.edu>, Josh Highley wrote: > I'm writing an Ada program that checks email accounts. I'm storing the >user name, password, and other info in a text file that my program references >on startup. I obviously don't want to store the password unencoded. Thus, >my question is how should I encrypt the password? Is there an Ada package >that will do this? I thought of using the CPU id to encrypt the password, >but I'm not sure how secure this would be and I haven't found an API function >or any other method of retrieving the CPU id. Is there a >typical/standard/accepted way of encoding passwords? > >Thanks, > >Josh Highley >joshhighley@hotmail.com You can use the same trick as UNIX uses. Unix use the password to encrypt a string of zeros using a modified version of DES(Data encryption standard) and the encrypted string is stored (usualy in /etc/passwd ) When the user is logging on the system he types the password, and the system will again encrypt the password. If this encrypted string is the same as the original encrypted string in the password file, the logon is accepted. The DES is modified by changing the number of rounds from 16 to 25, which have no known decryption, and the algorithm is also modified to take an extra 12 bit random "salt" which is stored with the password. The salt is there to prevent a text search for the same password when one password is broken. I you use a UNIX or Linux system, you can use the 'crypt' system call which does the encryption. (see the man pages) You then have interface this with convention 'C' This scheme give you only moderate security, since there has been several successfull attacks to this scheme. One of them is the dictionary attack, that use a wordlist, and tries different combinations of words. The programs doing this has been remarably sophisticated, and will typically break passwords on most systems. You can improve security by letting the password list be write protected, and have some quality check for the passwords, to make offline attacks more difficult. Another problem is that des limits the number bits used for encryption to 56 bit, which is to few by todays standards. Instead you can use one of the 5 remaining AES candidate algorithms, which allows up to 256 bit keys. The web pages under provide Ada implemetations of some of them. http://www.cl.cam.ac.uk/~mgk25/download/ (serpent) http://www.ccsr.cam.ac.uk/projects/aes/ (Rc6, Rijndael) http://www.skinner.demon.co.uk/aidan/programming/libra/ (mars, rc6, rijndael, twofish) There are of cause more 'state of the art' autentification schemes, but then I would recommend to learn more crypthograpy first. Also consider other security issues. It do not help that a cracker can't read the password file if he can read password transefered over the network in clear. Programs like SSH (secure shell) can improve this. Hope this helps. -- Gisle S�lensminde ( gisle@ii.uib.no ) ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-16 0:00 Saving and Encoding Passwords Josh Highley 1999-11-17 0:00 ` Gisle S�lensminde @ 1999-11-17 0:00 ` Ted Dennison 1999-11-17 0:00 ` Josh Highley 1999-11-26 0:00 ` Florian Weimer 2 siblings, 1 reply; 10+ messages in thread From: Ted Dennison @ 1999-11-17 0:00 UTC (permalink / raw) In article <38315e1a.0@silver.truman.edu>, joshhighley@hotmail.com (Josh Highley) wrote: > I'm writing an Ada program that checks email accounts. I'm storing > the user name, password, and other info in a text file that my program > references on startup. I obviously don't want to store the password > unencoded. Thus, my question is how should I encrypt the password? Is > there an Ada package that will do this? I thought of using the CPU id No, not as a standard part of the compiler, anyway. ... > or any other method of retrieving the CPU id. Is there a > typical/standard/accepted way of encoding passwords? There is ususally an OS call to help with this. On Unix, you can use "crypt" -- T.E.D. Sent via Deja.com http://www.deja.com/ Before you buy. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-17 0:00 ` Ted Dennison @ 1999-11-17 0:00 ` Josh Highley 0 siblings, 0 replies; 10+ messages in thread From: Josh Highley @ 1999-11-17 0:00 UTC (permalink / raw) Sorry, I should have mentioned that I'm using GNAT 3.12 on Windows 95. I'm in the process of looking at the web sites posted by Gisle Saelensminde (say that 3 times fast) I have limited knowledge about encryption, so I'm trying to figure out if you store the key along with the password or what. . . Josh Highley joshhighley@hotmail.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-16 0:00 Saving and Encoding Passwords Josh Highley 1999-11-17 0:00 ` Gisle S�lensminde 1999-11-17 0:00 ` Ted Dennison @ 1999-11-26 0:00 ` Florian Weimer 1999-11-27 0:00 ` Larry Kilgallen 1999-12-01 0:00 ` Robert I. Eachus 2 siblings, 2 replies; 10+ messages in thread From: Florian Weimer @ 1999-11-26 0:00 UTC (permalink / raw) joshhighley@hotmail.com (Josh Highley) writes: > I'm writing an Ada program that checks email accounts. I'm > storing the user name, password, and other info in a text file that > my program references on startup. Do you need the passwords themselves, or do you want to check whether the password entered by the user is correct? In the latter case, you should not store the password itself, but a cryptographic hash of it. It is considered close to impossible to recover the password from the hash value if the cryptographic hash function is one of the most commonly used and thoroughly analyzed (i.e. MD5 or SHA-1). If your program needs the passwords themselves (for example, to authenticate itself with a POP mail server) and you don't want any user interaction, you can't get much security, because your software must be able to decrypt the passwords -- and so is a possible attacker. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-26 0:00 ` Florian Weimer @ 1999-11-27 0:00 ` Larry Kilgallen 1999-11-28 0:00 ` Florian Weimer 1999-11-29 0:00 ` Samuel T. Harris 1999-12-01 0:00 ` Robert I. Eachus 1 sibling, 2 replies; 10+ messages in thread From: Larry Kilgallen @ 1999-11-27 0:00 UTC (permalink / raw) In article <87u2m8exf8.fsf@deneb.cygnus.argh.org>, Florian Weimer <fw@s.netic.de> writes: > It is considered close to impossible to recover the password from > the hash value if the cryptographic hash function is one of the most > commonly used and thoroughly analyzed (i.e. MD5 or SHA-1). But that consideration is only of interest to mathematicians. Security folk realize that passwords freely chosen by humans are highly susceptible to brute force guessing attacks. The common defenses are: Include a secret per-user pseudo-random seed number in the hash, to prevent pre-computation of hashes for a particular username. Enforce rules regarding password choice that effectively prevent the use of dictionary words (e.g., punctuation and numeric characters required). Larry Kilgallen ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-27 0:00 ` Larry Kilgallen @ 1999-11-28 0:00 ` Florian Weimer 1999-11-28 0:00 ` Larry Kilgallen 1999-11-29 0:00 ` Samuel T. Harris 1 sibling, 1 reply; 10+ messages in thread From: Florian Weimer @ 1999-11-28 0:00 UTC (permalink / raw) kilgallen@eisner.decus.org (Larry Kilgallen) writes: > In article <87u2m8exf8.fsf@deneb.cygnus.argh.org>, Florian Weimer <fw@s.netic.de> writes: > > > It is considered close to impossible to recover the password from > > the hash value if the cryptographic hash function is one of the most > > commonly used and thoroughly analyzed (i.e. MD5 or SHA-1). > > But that consideration is only of interest to mathematicians. Eh, maybe. ;) > Security folk realize that passwords freely chosen by humans > are highly susceptible to brute force guessing attacks. The > common defenses are: > > Include a secret per-user pseudo-random seed number > in the hash, to prevent pre-computation of hashes for > a particular username. There's no such thing like a `secret per-user pseudo-random seed number'. The application needs to know it in order to verify the password, which means it can't that secret. Of course, a password salt will tremendously increase the size of a precomputed dictionary without much effort on the application programmer's side. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-28 0:00 ` Florian Weimer @ 1999-11-28 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 10+ messages in thread From: Larry Kilgallen @ 1999-11-28 0:00 UTC (permalink / raw) In article <87hfi6q4k4.fsf@deneb.cygnus.argh.org>, " "@deneb.cygnus.argh.org (Florian Weimer) writes: > kilgallen@eisner.decus.org (Larry Kilgallen) writes: > >> In article <87u2m8exf8.fsf@deneb.cygnus.argh.org>, Florian Weimer <fw@s.netic.de> writes: >> >> > It is considered close to impossible to recover the password from >> > the hash value if the cryptographic hash function is one of the most >> > commonly used and thoroughly analyzed (i.e. MD5 or SHA-1). >> >> But that consideration is only of interest to mathematicians. > > Eh, maybe. ;) > >> Security folk realize that passwords freely chosen by humans >> are highly susceptible to brute force guessing attacks. The >> common defenses are: >> >> Include a secret per-user pseudo-random seed number >> in the hash, to prevent pre-computation of hashes for >> a particular username. > > There's no such thing like a `secret per-user pseudo-random seed number'. > The application needs to know it in order to verify the password, > which means it can't that secret. Of course, a password salt will > tremendously increase the size of a precomputed dictionary without much > effort on the application programmer's side. Keeping secrets is just one reason why we have operating systems. Any operating system smart enough to keep the hash result secret can keep the seed secret. If you don't like "operating system", try "protected subsystem" where the trusted code (and for a mail system, this _is_ part of the TCB) has the only access to the seed. Larry Kilgallen ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-27 0:00 ` Larry Kilgallen 1999-11-28 0:00 ` Florian Weimer @ 1999-11-29 0:00 ` Samuel T. Harris 1 sibling, 0 replies; 10+ messages in thread From: Samuel T. Harris @ 1999-11-29 0:00 UTC (permalink / raw) Larry Kilgallen wrote: > > In article <87u2m8exf8.fsf@deneb.cygnus.argh.org>, Florian Weimer <fw@s.netic.de> writes: > > > It is considered close to impossible to recover the password from > > the hash value if the cryptographic hash function is one of the most > > commonly used and thoroughly analyzed (i.e. MD5 or SHA-1). > > But that consideration is only of interest to mathematicians. > > Security folk realize that passwords freely chosen by humans > are highly susceptible to brute force guessing attacks. The > common defenses are: > > Include a secret per-user pseudo-random seed number > in the hash, to prevent pre-computation of hashes for > a particular username. > > Enforce rules regarding password choice that effectively > prevent the use of dictionary words (e.g., punctuation > and numeric characters required). > > Larry Kilgallen A third alternative is to not let the user select the password at all. I remember using WWMCCS (World Wide Military Command and Control System) computers and the password was a 20+ character sequence generated randomly. Classified users had to memory this beast or keep it stored double sealed in the classified vaults. Some users needed access to several nodes in the system. Each node had its own password for that user. What a pain that was, but necessary for a secure environment. It could take 20 minutes to get your password list and get logged in, do 5 minutes of work, and then take 10 minutes resealing your password list and getting back into the safe. -- Samuel T. Harris, Principal Engineer Raytheon, Scientific and Technical Systems "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Saving and Encoding Passwords 1999-11-26 0:00 ` Florian Weimer 1999-11-27 0:00 ` Larry Kilgallen @ 1999-12-01 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 10+ messages in thread From: Robert I. Eachus @ 1999-12-01 0:00 UTC (permalink / raw) Florian Weimer wrote: > Do you need the passwords themselves, or do you want to check whether > the password entered by the user is correct? In the latter case, you > should not store the password itself, but a cryptographic hash of it. > It is considered close to impossible to recover the password from > the hash value if the cryptographic hash function is one of the most > commonly used and thoroughly analyzed (i.e. MD5 or SHA-1). > > If your program needs the passwords themselves (for example, to > authenticate itself with a POP mail server) and you don't want any user > interaction, you can't get much security, because your software must > be able to decrypt the passwords -- and so is a possible attacker. Hmmm... Cryptographic protocols--lots of fun! If the idea is to store multiple passwords for a single user in a fashion that allows the user to enter a single password to access all acounts, the best idea would be to use a hash of the user-entered password as a symmetric (say 3DES) key to decrypt the stored passwords. (Of course you should "whiten" the key by using say the SHA-1 hash of the user-entered password as the ky.) This way a particular user needs only to enter one password to access multiple accounts, even if several people have access to the stored data. One last point, you probably should store ALL information about the accounts, including the number of accounts an individual has, encoded using 3DES. The reason for this is that the user may not want others with access to the same machine to know which accounts he has.... -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~1999-12-01 0:00 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-11-16 0:00 Saving and Encoding Passwords Josh Highley 1999-11-17 0:00 ` Gisle S�lensminde 1999-11-17 0:00 ` Ted Dennison 1999-11-17 0:00 ` Josh Highley 1999-11-26 0:00 ` Florian Weimer 1999-11-27 0:00 ` Larry Kilgallen 1999-11-28 0:00 ` Florian Weimer 1999-11-28 0:00 ` Larry Kilgallen 1999-11-29 0:00 ` Samuel T. Harris 1999-12-01 0:00 ` Robert I. Eachus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox