| 4.4 Access Control
19. No Stored Password | |
|---|
| 4.4.19. No Stored Password: | | 1. It is a business requirement that passwords cannot be stolen and if they are stolen they are encrypted in a way that cannot be reversed. A solution is not to store a persons password, but to compute the password as and when needed. | | 2. It is a business requirement for customers, suppliers and business associates to be able to sign-in and view their own data. In fact, it is a legal right for any person to request a copy of their own data or to be granted access rights to view their own data. A subject Access Request (SAR) can be costly and time consuming to prepare manually, but to grant a person access to the own data could be much more effective. | | 3. For the last decade, a unique benefit over all competitors is that passwords are assigned by the application service, rather than entered by each person. The logical way to exploit that advantage is to no longer store the assigned password. |
| 2. Principal: | | 1. Any CRM record hold about forty field values and many of those values are relatively stable from one year to the next. An algorithm is used to extract certain numbers from dates and time and then use those numbers to extract certain characters from certain fields. Look up tables and base 51 modulo arithmetic is used to scramble the result into a password that is not reversable. | | 2. All fields in a CRM record are encrypted to make them meaningless to a criminal, bit the real secret is that the password is never stored, it is always calculated when needed. |
| 3. How Does It Work: | | 1. When a person signs in they enter (1) user name, (2) email address and (3) password. | | 2. The user name and email address are used to find a unique CRM record. | | 3. Many different fields in that CRM record are used to compute the assigned password. | | 4. The entered password is checked against the assigned password to make sure they match. | | 5. People are granted the right to access their data when the three fields they enter match an unique CRM record that never stored the password. |
| 4. Secret Algorithm: | | 1. The secret is to only use field values that are relatively stable and to hold field values like date of birth and place of birth that are stable. Date and time fields provide many digits that are used to extract certain characters from certain fields. The actual fields and characters extracted are unique to every person based on fixed field values that are unknown to any criminal. The characters extracted are transformed using several methods including lookup tables to create true entrope to the result. Transformation includes calculating the remainder when dividing one character string by another character string. | | 2. The secret algorithm is easy to hide and even if criminals gained access to it, it is worthless without its lookup tables and CRM records. As it is not common practice for passwords to be calculated, criminals may spend more time looking for the password table than looking for the password aglogithm. | | 3. A date is hidden in the CRM record and this is used to make sure that when a new password needs to be generated, it will be unique because of the inclusion of this generation date. |
| 5. Misdirection: | | 1. Legal obligations are that passwords must be stored using a published encryption method such as RSA. The complementary legal obligation is that law enforcement can demand to be told the encryption key. | | 2. Each CRM record may hold a field called "password" that contains a very long and complex RSA encrypted password where the key can be provided upon request. The fact that people are never told this password and do not know it exists is a classic privacy misdirection. |
| 6. Basic Example: | | 1. A CRM record created on 8 Sep 2016 at 15:16:17 holds a persons name as "Able Baker" and an email as "able.baker@mycompany.co.uk". The name and email are each fragmented into two fields while the date and time are each fragmented into three fields. | | 2. Each character of name and email is transformed into groups of base-51 character codes. Extra character codes are generated by adding together each pair of base-51 character codes and dividing by a constant. Each digit is transformed into another number using lookup tables. Extra digits are generated by looking up a number from each pair of digits. The first 24 digits are used to select (1) a specific character code group or to select (b) a specific character in that group, resulting in 12 character codes. The base-51 character codes are used to lookup latin character codes - some upper case and some lower case and some as digits (few or no symbols). The 12 character codes are scrambled and used as the assigned password that can be quickly calculated from the CRM record when needed. | | 3. The RSA encryption algorithm will typically go through many thousands of iterations - the above algorithm is much faster. The RSA algorithm uses an encryption key and salt (another field in the CRM), while the above algorithm uses more than ten standard CRM field values and external lookup tables. By never storing the password, yet being able to compute the password at sign-in time has many privacy and security benefits. |
| 7. Unique: | | 1. No other ASP is able to use the no stored password principal because all others choose to let people manually enter their own simplistic passwords that are easy to crack. The security world is driven by Governments who dare not let people have privacy or security, so crackable passwords are mandated. The privacy of the lookup tables are paramount, but it is easy to hide short srrings of characters inside images or to repurpose another perfectly normal string of characters such as some build names. | | 2. When passwords are not stored a data breach cannot happen and fines by the Information Commissioners Office will never happen. All customers are protected from a password data breach - their reputation is maintained. |
| Passwords: | | 1. Different passwords are deployed as: | | (1) Permanent password as 12 to 16 characters. | | (2) One-Time (or permanent) password as 10 digits in 15 character string with "+28" identifier. | | (3) One-Time password as 8 digits without identifier. | | (4) One-Time password as 4 digits like pin. | | 2. The permanent password is automatically generated from a number of static person specific field values A one-way algorithm is used so even the person who knowns their password would have little idea how it was derived. | | 3. The one-time password is automatically generated from a number of static person specific field values A one-way algorithm is used so a person who knowns many one-time passwords will not be able to derive how they were derived. By accident, the ten-digit one-time password does not expire and may be used many times - this may have to be reviewed. An alternative option is a shorter 8 digit one-time password that expires in one hour - even a 4 digit pin that expires in one hour could be fit-for-purpose. |
| Authentication; the GDPR generation | | 1. The possibility of a data breach must be eliminated. | | 2. A data breach is where PII is lost or stolen. | | 3. Extreme measures must be deployed to ensure that this data is stored in a way that is meaningless and plausible to say such data does not exist and so cannot be stolen. | | 4. While all HR data could be imagined as PII, in reality, the only fields that can identify a specific person are:- | | UAP23 User Name: authentication handle stored in 23+24. | | UAP26 User Email: authentication mail stored in 25+26. | | UAS25 Pass Phrase: authentication pass stored in 23+24+25+26. | | UAP49 User Job Title: unused reference only. | | UAP31 User Phone: unused reference only. | | UAP33 User Mobile: unused reference only. |
| Name Token | | 1. A list of peoples names is used in many places to show who created and who last changed a record - this list is indexed by the person key that acts as a 6 digit token. | | 2. A distinct table (ZUNA) of first name, family name and token is maintained so a persons name does not need to be stored in a persons record - the primary key of the persons record is the token to the name table. |
| Mail Encryption | | 1. Every email address is split into 2 lower-case parts that are each encrypted using different methods that are stored as two numbers. | | 2. A distinct table (ZUDO) of domain and token is maintained so a persons email domain is stored as a token to the domain table. | | 3. The email prefix is encrypted as a long number that remains sortable and filterable. |
| Pass Encryption | | 1. The pass phrase is never used as a distinct field value so it is one-way hashed with the person name, mail and date created. | | 2. Modulus arithmetic is used to ensure that this hash cannot be reversed - data is lost during the hash calculation that cannot be recovered. | | 3. The resulting pass number is stored as a series of integer values in the authentication table rather than the persons record. |
| Reference Encryption | | 1. Any reference data is encrypted with a reversable method that stores the field value as a long number that is meaningless. | | 2. Telephone numbers are translated into a character string that is then encrypted using a reversable method. |
| Upgrade | | 1. UAP and UAS separate each person record into two tables to keep the more secure data in a different place to data that is changing. | | 2. ZUNA is a bespoke table of current person names that acts as a fast look up table by token. | | 3. ZUDO is a bespoke table of email suffix domain name that provides a token to be stored in the persons record. |
| Document Control: | | 2016 Nov 4 : Latest edition as (public) page 164419. Part of common ITIL application service. |
|
|