Saving and Encoding Passwords

Saving and Encoding Passwords

[Josh Highley]

  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

Re: Saving and Encoding Passwords

[Gisle S�lensminde]

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 )   

Re: Saving and Encoding Passwords

[Ted Dennison]

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.

Re: Saving and Encoding Passwords

[Josh Highley]

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

Re: Saving and Encoding Passwords

[Florian Weimer]

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.

Re: Saving and Encoding Passwords

[Larry Kilgallen]

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

Re: Saving and Encoding Passwords

[Larry Kilgallen]

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

Re: Saving and Encoding Passwords

[Florian Weimer]

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.

Re: Saving and Encoding Passwords

[Samuel T. Harris]

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!"

Re: Saving and Encoding Passwords

[Robert I. Eachus]

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...