Browse Prior Art Database

User-Provided, Domain-Specific Password Salts to Prevent Password Reuse

IP.com Disclosure Number: IPCOM000224789D
Publication Date: 2013-Jan-03
Document File: 3 page(s) / 53K

Publishing Venue

The IP.com Prior Art Database

Abstract

Herein is described a method for salting passwords with user generated values.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 3

User-Provided, Domain-Specific Password Salts to Prevent Password Reuse

In 2012 there have been an increasing number of password breaches within major web sites. Passwords retrieved in plaintext from one server are used to attack other web sites with the same user/ID combination. The attacks are often successful because lazy users choose the same IDs and passwords for every web site.

Some users avoid this problem by salting their passwords using the domain name. For example, a clever user may salt their password to be "passw0rd-EXAMPLESITE", creating a unique value that is also easy to remember. However, lazy users are unlikely to make the effort, and simple predictable salts add little security in the long-run.

This invention proposes a number of methods to encourage or require users to create unique passwords for each site.

Even short or easily attacked site-specific portions of the password can be effective mitigation against automated password reuse attacks.

Potentially novel aspects of this invention:


1. Combining user passwords with mandatory site-specific passwords


2. Use of other media such as random pictures, video or text to generate simple user-specific content


3. Use of an inkblot in simple site-specific password entry


4. Use of CAPTCHAs or other server-generated content in simple site-specific password entry


5. Combination of multiple sever-generated elements for site-specific password entry


6. Validation of site-specific password using separate password complexity requirements

   7. Hashing of passwords and site-specific portions on the client to mitigate password exposures
Web sites would provide two forms for the user enter their password, one portion for a complex password that the user is likely to reuse, and one portion for a simple password unique to the visited site:

The web site's HTML then simply combines the two values, possibly using a site-unique 1-directional method, and that effectively becomes the user's password.

However, the separation in forms provides no incentive for users to generative a unique salt value for each site. Lazy users will still use the same values across sites, or just enter their password twice.

To encourage us...