Databases
StackOverflow2013
Postsdbo
POChecksum for SSN
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POChecksum for SSN
    primarykey
    data
    text
    <p>I have a project that needs to do validation on the frontend for an American Social Security Number (format <code>ddd-dd-dddd</code>). One suggestion would be to use a hash algorithm, but given the tiny character set used (<code>[0-9]</code>), this would be disastrous. It would be acceptable to validate with some high probability that a number is correct and allow the backend to do a final <code>==</code> check, but I need to do far better than "has nine digits" etc etc. </p> <p>In my search for better alternatives, I came upon the validation checksums for <a href="https://secure.wikimedia.org/wikipedia/en/wiki/ISBN#ISBN-13" rel="nofollow">ISBN</a> numbers and <a href="https://secure.wikimedia.org/wikipedia/en/wiki/Universal_Product_Code" rel="nofollow">UPC</a>. These look like a great alternative with a high probability of success on the frontend.</p> <p>Given those constraints, I have three questions:</p> <ol> <li>Is there a way to prove that an algorithm like ISBN13 will work with a different category of data like SSN, or whether it is more or less fit to the purpose from a security perspective? The checksum seems reasonable for my quite large sample of one real SSN, but I'd hate to find out that they aren't generally applicable for some reason.</li> <li>Is this a solved problem somewhere, so that I can simply use a pre-existing validation scheme to take care of the problem?</li> <li>Are there any such algorithms that would also easily accommodate validating the last 4 digits of an SSN without giving up too much extra information?</li> </ol> <p>Thanks as always, Joe</p> <hr> <p>UPDATE:</p> <p>In response to a question below, a little more detail. I have the customer's SSN as previously entered, stored securely on the backend of the app. What I need to do is verification (to the maximum extent possible) that the customer has entered that same value again on <em>this</em> page. The issue is that I need to prevent the information from being incidentally revealed to the frontend in case some non-authorized person is able to access the page.</p> <p>That is why an MD5/SHA1 hash is inappropriate: namely that it can be used to derive the complete SSN without much difficulty. A checksum (say, modulo 11) provides nearly no information to the frontend while still allowing a high degree of accuracy for the field validation. However, as stated above I have concerns over its general applicability.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USJoseph Mastey
    1. USJoseph Mastey
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POChecksum for SSN
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POChecksum for SSN
      1. This table or related slice is empty.
      1. VTUpMod
    1. COWhy would it be disastrous to use sha1?
      singulars
      1. POChecksum for SSN
      1. USNick ODell
    2. CO@Nick It would be disastrous because you could quite quickly brute force numbers that size. Furthermore, the SSN is a set format, so not all numbers are valid, further reducing the search size. Modern hardware (especially GPUs) can calculate huge numbers of hashes quickly, so this is insufficient security for personally identifying information.
      singulars
      1. POChecksum for SSN
      1. USJoseph Mastey
    3. COI'm somewhat confused by the question. Aren't you transmitting the SSN in plaintext anyway?
      singulars
      1. POChecksum for SSN
      1. USNick ODell
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload