One-way encryption: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>Pat Palmer
No edit summary
(28 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{subpages}}
{{subpages}}
{{main|cryptography}}
{{TOC|left}}
{{Image|Password_creation.jpg|right|450px|Storing a new password}}
<onlyinclude>
{{Image|password_authentication.jpg|right|450px|Authenticating via an existing password}}
{{Image|Password_creation.jpg|right|300px|FIGURE 1. Storing a new password}}
When passwords are stored on a computer, it is essential that they be kept secret.  To do so, programmers apply '''one-way encryption''' to a password before storing it on disk. When a user later enters their password to authenticate with the site, the plain-text password typed by the user gets re-hashed and then compared to the stored, encrypted string.
{{Image|password_authentication.jpg|right|300px|FIGURE 2. Authenticating an existing password}}


The password is always scrambled via a [[Hash digest|hash digest]] function, where the result for every string is always a fixed-size, large integer.   An example of a hash digest is SHA-1, which dates from 1994; the SHA-1 [[Algorithm|algorithm]] takes a string as input and always outputs a 160-bit number (20 bytes of storage)Because 48 decimal digits would be required to express this number, but it is usually displayed to humans as a 28-character, [[Base-64 encoded string|base-64 encoded string]]. Here are some examples:
When passwords are stored on a computer, it is essential that they be kept secret. To do so, programmers apply '''one-way encryption''' to a password before storing it on diskWith this type of encryption, there is no known way to decrypt an already encrypted string.  When a user later enters their password to authenticate with the site, the plain-text password typed by the user must be rescrambled and then compared to the stored, encrypted string.


  Hello World  z7R8yBtZz0+eqead7UEYzPvVFjw=
==Hash digests==
  VB            L1SHP0uzuGbMUpT4z0zlAdEzfPE=
For password scrambling, programmers use a ''[[Hash_(cryptography)|hash digest]]'' function, where the result for any input string is always a fixed-size, large integer.  An example of a hash digest is [[Hash_(cryptography)#SHA-1|SHA-1]], which dates from 1994; the SHA-1 [[Algorithm|algorithm]] takes a string as input and always outputs a 160-bit number (20 bytes of storage).  Because 48 decimal digits would be required to express this number, it is usually displayed to humans as a 28-character, [[Wikipedia:Base64|base-64 encoded string]].  Here are some examples:
  vb            eOcnhoZRmuoC/Ed5iRrW7IxlCDw=
 
  Vb            e3PaiF6tMmhPGUfGg1nrfdV3I+I=
  '''Hello World'''   z7R8yBtZz0+eqead7UEYzPvVFjw=
  vB            gzt6my3YIrzJiTiucvqBTgM6LtM=
  '''VB'''           L1SHP0uzuGbMUpT4z0zlAdEzfPE=
  '''vb'''           eOcnhoZRmuoC/Ed5iRrW7IxlCDw=
  '''Vb'''           e3PaiF6tMmhPGUfGg1nrfdV3I+I=
  '''vB'''           gzt6my3YIrzJiTiucvqBTgM6LtM=
   
   
In the examples above, even very similar strings produce quite different hash digests; the resultant hash string does not give any hint about the length of source string, or its starting character, or anything else about it.  SHA-1 is useful because it produces collision-free results. Below is C# (v2.0) code for producing an SHA-1 hash digest from a string:
In the examples above, even very similar strings produce quite different hash digests; the resultant hash string does not give any hint about the length of source string, or its starting character, or anything else about it.  SHA-1 is useful because it produces collision-free results.
 
==Code to hash (encrypt) a string==
Below is C# (v2.0) code for producing an SHA-1 hash digest from a string:


<blockquote>
<syntaxhighlight lang="C#" line>
  Byte[] bytSource; // byte array for plain text string
  Byte[] bytSource; // byte array for plain text string
  Byte[] bytHash;  // byte array for cipher string
  Byte[] bytHash;  // byte array for cipher string
Line 32: Line 38:
  // return a displayable base64-encoded string
  // return a displayable base64-encoded string
  return Convert.ToBase64String(bytHash);
  return Convert.ToBase64String(bytHash);
</blockquote>
</syntaxhighlight>
 
Because hash digests are unique signatures, they can be used to verify that a file has not changed.  The hash digest of a file can be taken before transmitting it and appended to the file transmission, and the receiving computer can also hash the file, compare its computed hash with the transmitted hash, and if they are identical, presume that the file was not corrupted by accidental signal noise on the transmission channel.


==Use of one-way encryption for password storage and authentication==
==Salting passwords==
When implementing password security, it is best to use a tried and true software library which has already been developed and debugged, because the process of handling passwords is a little more complicated than merely creating a hash digest of a password.  It turns out, that to minimize the likelihood of a [[Dictionary attack|dictionary attack]] on a password, it is necessary to ''salt'' the password by either prepending or appending a unique, randomly created string to it before it hashing and storage (new password) or hashing and comparison (existing password).  There is a very good tutorial on salting passwords in the OAuth blog ("Adding Salt to Hashing: A Better Way to Store Passwords"<ref>OAuth blog: [https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/ Adding Salt to Hashing: A Better Way to Store Passwords], last access 10/8/2020</ref>).
When implementing password security, it is best to use a tried-and-true software library which has already been developed and debugged, because the process of handling passwords is a little more complicated than merely creating a hash digest of a password.  It turns out, that to minimize the likelihood of a [[Dictionary attack|dictionary attack]] on a password, it is necessary to ''salt'' the password by either prepending or appending a unique, randomly created string to it before it hashing and storage (new password) or hashing and comparison (existing password).  There is a very good tutorial on salting passwords in the OAuth blog ("Adding Salt to Hashing: A Better Way to Store Passwords"<ref>OAuth blog: [https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/ Adding Salt to Hashing: A Better Way to Store Passwords], last access 10/8/2020</ref>).


==Use of one-way encryption for verification of file integrity==
==Verification of file integrity==
Because hash digests are unique signatures, one-way encryption via hash digests can be used to verify that a file has not changed.  The hash digest of a file can be taken before transmitting it and appended to the file transmission, and the receiving computer can also hash the file, compare its computed hash with the transmitted hash, and if they are identical, presume that the file was not corrupted by accidental signal noise on the transmission channel.


==References==
==References==
{{reflist}}
{{reflist}}
</onlyinclude>
[[Category:Reviewed Passed]]

Revision as of 15:45, 8 April 2024

This article is developing and not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.
FIGURE 1. Storing a new password
FIGURE 2. Authenticating an existing password

When passwords are stored on a computer, it is essential that they be kept secret. To do so, programmers apply one-way encryption to a password before storing it on disk. With this type of encryption, there is no known way to decrypt an already encrypted string. When a user later enters their password to authenticate with the site, the plain-text password typed by the user must be rescrambled and then compared to the stored, encrypted string.

Hash digests

For password scrambling, programmers use a hash digest function, where the result for any input string is always a fixed-size, large integer. An example of a hash digest is SHA-1, which dates from 1994; the SHA-1 algorithm takes a string as input and always outputs a 160-bit number (20 bytes of storage). Because 48 decimal digits would be required to express this number, it is usually displayed to humans as a 28-character, base-64 encoded string. Here are some examples:

Hello World   z7R8yBtZz0+eqead7UEYzPvVFjw=
VB            L1SHP0uzuGbMUpT4z0zlAdEzfPE=
vb            eOcnhoZRmuoC/Ed5iRrW7IxlCDw=
Vb            e3PaiF6tMmhPGUfGg1nrfdV3I+I=
vB            gzt6my3YIrzJiTiucvqBTgM6LtM=

In the examples above, even very similar strings produce quite different hash digests; the resultant hash string does not give any hint about the length of source string, or its starting character, or anything else about it. SHA-1 is useful because it produces collision-free results.

Code to hash (encrypt) a string

Below is C# (v2.0) code for producing an SHA-1 hash digest from a string:

 Byte[] bytSource; // byte array for plain text string
 Byte[] bytHash;   // byte array for cipher string
 
 System.Text.UnicodeEncoding uEncode = new System.Text.UnicodeEncoding();
 
 System.Security.Cryptography.SHA1CryptoServiceProvider sha1 = 
       new System.Security.Cryptography.SHA1CryptoServiceProvider();
  
 // fill byte array with Unicode chars from plain text source string
 bytSource = uEncode.GetBytes(strSource);
 
 // encrypt the source byte array into the result array
 bytHash = sha1.ComputeHash(bytSource);
 
 // return a displayable base64-encoded string
 return Convert.ToBase64String(bytHash);

Salting passwords

When implementing password security, it is best to use a tried-and-true software library which has already been developed and debugged, because the process of handling passwords is a little more complicated than merely creating a hash digest of a password. It turns out, that to minimize the likelihood of a dictionary attack on a password, it is necessary to salt the password by either prepending or appending a unique, randomly created string to it before it hashing and storage (new password) or hashing and comparison (existing password). There is a very good tutorial on salting passwords in the OAuth blog ("Adding Salt to Hashing: A Better Way to Store Passwords"[1]).

Verification of file integrity

Because hash digests are unique signatures, one-way encryption via hash digests can be used to verify that a file has not changed. The hash digest of a file can be taken before transmitting it and appended to the file transmission, and the receiving computer can also hash the file, compare its computed hash with the transmitted hash, and if they are identical, presume that the file was not corrupted by accidental signal noise on the transmission channel.

References