diff --git a/Site/algorithm.html b/Site/algorithm.html index 1d801a05..b26b9002 100644 --- a/Site/algorithm.html +++ b/Site/algorithm.html @@ -200,10 +200,10 @@

Combining The Inputs

- The theory behind Master Password requires that all inputs are given by the user. The two main inputs are the master password that we used to determine the key and the site's name. There is a third input value, the password counter, which is a 32-bit unsigned integer value that is used to salt the input. Initially, the password counter should be zero, but a user may specify a non-zero counter value in case he wants to force the algorithm to produce a new output password for the site. + The theory behind Master Password requires that all inputs are given by the user. The two main inputs are the master password that we used to determine the key and the site's name. There is a third input value, the password counter, which is a 32-bit unsigned integer value. Initially, the password counter should be zero, but a user may specify a non-zero counter value in case he wants to force the algorithm to produce a new output password for the site.

- These input values are combined in a byte array, separated by a single NUL byte. In order, the input values are the site name (UTF-8 decoded), the master key, and a salt (this is the password counter, a 32-bit unsigned integer in network byte order). The byte array is hashed using the SHA-1 algorithm to yield the seed as a result. + These input values are combined in a byte array, separated by a single NUL byte. In order, the input values are the site name, the master key, and a counter. The byte array is hashed using the HMAC-SHA-256 algorithm to yield the seed as a result. 

                 seed = hmac-sha256( key, "com.lyndir.masterpassword" . site name length . site name . counter )
@@ -211,7 +211,7 @@
 
             
Generating The Output

             

-                We now have a seed which is a sufficiently long seemingly-arbitrary string of bytes that is unique to the site and the user.  This string of bytes, however, is not very useful for a user to use as a password.  We have two additional problems that need to be solved: The output password must be easy for a user to read and copy, but it should also be compatible with most password policies. 
+                We now have a seed which is a sufficiently long seemingly-arbitrary string of bytes that is unique to the site and the user.  This string of bytes, however, is not very useful for a user to use as a password.  We have two additional problems that need to be solved: The output password must be easy for a user to read and type in using a keyboard or smartphone, but it should also be compatible with most site's password policies. 
             

             

                 Password policies are strict rules imposed by applications on their users, designed to limit the types of passwords these users are allowed to use with the application.  Usually, these policies exist to force users into thinking about passwords with a healthy entropy.  Often, they exist purely as a side-effect of bad password handling such as storing the clear-text passwords in a database.
@@ -223,15 +223,14 @@
             

                 The following templates are defined:
                 

             

             

@@ -301,60 +296,51 @@
             

                 The following character groups (passChars) are defined:
                 

             

             

diff --git a/Site/css/screen.css b/Site/css/screen.css
index dacc8170..127cb7db 100644
--- a/Site/css/screen.css
+++ b/Site/css/screen.css
@@ -42,6 +42,9 @@ ul {
     font-size:                  90%;
     font-weight:                400;
 }
+ul.clean {
+    list-style:                 none;
+}
 blockquote {
     font-size:                  90%;
     font-weight:                400;