NL2032663B1

NL2032663B1 - Method for securely storing a password in a database

Info

Publication number: NL2032663B1
Application number: NL2032663A
Authority: NL
Inventors: Roskam Pieter
Original assignee: Roskam Pieter
Priority date: 2022-08-02
Filing date: 2022-08-02
Publication date: 2024-02-07

Abstract

A method for securely storing a password in a database, comprising the steps of: receiving a password to be stored in a database, the password comprising one or more characters; performing a 5 ﬁrst transformation, comprising: determining numerical values on the basis of the one or more characters of the password, and converting the password to a numerical sequence representative of the password based on the determined numerical values, accessing a unique table, associated with the database, the unique table comprising one or more predeﬁned numerical values respectively corresponding to one or more predeﬁned character strings, performing a second transformation, 10 comprising: matching the numerical sequence to one or more predeﬁned values of the unique table, and converting the numerical sequence to a substitute password by combining one or more the predeﬁned character strings corresponding to the one or more matched predeﬁned numerical values of the unique table, performing a third transformation, comprising: converting the substitute password to a hashed password by hashing the substitute password, storing the hashed password in 15 the database.

Description

METHOD FOR SECURELY STORING A PASSWORD IN A DATABASE

FIELD OF THE DISCLOSURE

The present disclosure relates to a method for securely storing a password in a database, as well as a method for securely verifying an input password. The methods are preferably computer- implemented methods. The present disclosure also relates to an electronic device, a computer program, and a computer-readable medium.

BACKGROUND

A large number of companies and government entities with an online presence allow for users of their product and services to login to an environment or platform containing information relating to the specific user (e.g., a user account). such as their order history or private information, ¢.g., their home address or credit card information. In order to make an account, or login to an online platform, the user generally inputs a user ID (such as e-mail address) and a password. Upon creation of a user account, the password chosen by the user is generally hashed (e.g., by means of a hash function such as MD5), and the result is saved in a database or the like. When the user logs into the online platform, the user provides the password, which is hashed again, and the result of the hashing is then compared to the result saved in the database earlier. In case the hashed password corresponds to the hash saved in the database, the user is granted access to the personal information in the online platform (e.g., the user account).

A disadvantage of this method is that, whilst time-consuming, hashed information which is obtained in illicit manner may be cracked by using brute-force methods. Especially hashes of short passwords may be retrievable in a reasonable timeframe, depending on the hashing methods used.

In turn, users are prone to using the same password for several different online platforms.

Accordingly, if a database of one platform is hacked, and the illicitly obtained hashed password is cracked, this password may then subsequently be used to login to other platforms where the user used the same password.

Generally, users are encouraged to use long, complex passwords, and to use a different password for each online platform to prevent others from misusing their password in case it is illicitly obtained. Programs such as password managers are available, which assist users in managing a large variety of long and complex password. Furthermore, users are encouraged to enable additional security measures, such as two-factor authentication (2FA). However, many users tend to ignore such safety measures in favor of convenience, thus not improving the overall protection of the broader general public, in practice. In other words, a large number of users will keep using short, simple passwords, and reusing their password for many online platforms, services, and environments, despite the known security risks.

SUMMARY

Itis an object of the present disclosure, amongst other objects, to mitigate at least part of the aforementioned disadvantages of the prior art. Specifically, one object of the present disclosure is to mitigate security risks associated with password storage for the broader general public, without sacrificing convenience.

In view of this object, a method for securely storing a password in a database according to a first aspect of the present disclosure is provided. The method preferably being computer-implemented.

The method comprising the steps of: - receiving a password to be stored in a database, the password comprising one or more characters; - performing a first transformation, comprising: - determining numerical values on the basis of the one or more characters of the password, and - converting the password to a numerical sequence representative of the password based on the determined numerical values; - accessing a unique table, associated with the database, the unique table comprising one or more predefined numerical values respectively corresponding to one or more predefined character strings; - performing a second transformation, comprising: - matching the numerical sequence to one or more predefined numerical values of the unique table, and - converting the numerical sequence to a substitute password by combining one or more the predefined character strings corresponding to the one or more matched predefined numerical values of the unique table; - performing a third transformation, comprising: - converting the substitute password to a hashed password by hashing the substitute password; - storing the hashed password in the database.

In the above method, the password of the user is not simply hashed and saved in a database, but exposed to three transformations. The database is provided with a unique table, associated to the database, which contains numerical values that correspond to one or more character strings.

Preferably, those character strings comprise a relatively large number of characters, such as more than 100 characters. The table is unique to the database, or more specifically to the entity managing the database. For instance, the entity is a company or government entity, and the database is part of the online platform of the entity which a user of the entity can log onto. Accordingly, each entity making use of the above method for securely storing passwords has their own unique table. The first transformation transforms the original password of the user to a numerical sequence, for instance by assigning numbers to characters (e.g., ASCTI-encoding). In the second transformation, the numerical sequence is essentially compared against the predefined numerical values of the unique table, and the character strings linked to these predefined numerical values are used to construct a substitute password on the basis of the numerical sequence. As mentioned earlier, such string may comprise, for instance, more than 100 characters. Hence, the outcome of the second transformation can be a very long password, even though the original password of the user can be short and simple. Lastly, in the third transformation, the substitute password (instead of the original password, as used in the prior art) is hashed, and the hashed password is saved (or stored) in the database.

Using the above method has at least two distinct advantages. Firstly, the substitute password generated is different for each entity which uses the method, due to the unique table. Secondly, the substitute password can be a very long and complex password. The time required for brute-forced cracking of a hashed password is generally proportional to the length of the original password (in this case the substitute password), such that cracking the hash of the present method is impractical and perhaps impossible with modem technology, or at least infeasible due to the huge amount of time involved. Even if the hash could be cracked. the substitute password is obtained, and not the original password of the user. Even with the obtained substitute password a successful login is impossible, as the substitute password is not equal to the original password. Accordingly, trying to login with the substitute password instead of the original password would lead to the substitute password being transformed, through the above transformations, to another substitute password, which would not grant a successtul login. This means that even a user using a very simple password for multiple online environments is sufficiently protected from hacking attempts by using the above method. In addition, as the method is performed by the entity and not the user, in contrast to password managers or 2FA, or the like, the user’s convenience is not compromised.

Optionally, in the method of the first aspect. the first transformation comprises: transforming the one or more characters of the password to the one or more numerical values by means of character encoding, preferably wherein the character encoding is ASCll-encoding. Character encoding is a proven and reliable method for converting a set of characters to numerical values, and can readily be implemented.

Optionally, in the method of the first aspect, the second transformation comprises: before matching the numerical sequence to one or more predefined values of the unique table, modifying the numerical sequence by applying at least one predefined mathematical function to the numerical sequence. As a simple example, the individual digits of the numerical sequence may be added together, or the like. Optionally, multiple mathematical functions may be applied to the numerical sequence, sequentially or in parallel. For instance, doing multiple different mathematical functions in parallel allows for the creation of a plurality of numerical sequences that may be used to construct the substitute password. The mathematical functions add another layer of complexity to the method, thus reducing the likelihood of the method being cracked by persons with bad intentions. The mathematical functions may optionally be unique for each entity.

Optionally, in the method of the first aspect, the unique table comprises a plurality of unique sub- tables. Preferably, the second transformation comprises: matching the numerical sequence to one or more predefined numerical values of each of the plurality of unique sub-tables, and converting the numerical sequence to the substitute password by combining one or more predefined character strings corresponding to the one or more matched predefined numerical values of each of the plurality of unique sub-tables. For example, three unique sub-tables may be comprised in the unique table. Each unique sub-table may provide part of the substitute password on the basis of the numerical sequence. For instance, for each sub-table a different mathematical function may be applied to the numerical sequence, wherein each mathematical function ahs a different outcome that may be matched to one or more predefined numerical values in the sub-tables, which are each linked to one or more predefined character strings. The predefined characters strings from these sub-tables may then be used to construct a substitute password.

Optionally, in the method of the first aspect, the third transformation comprises: hashing the substitute password using a standard hash function, preferably wherein the standard hash function is SHA-256. Other standard hash functions may also be used, such as MD5, SHA-2, or SHA-3.

Hash functions such as SHA-256 are very secure and hard to crack with modern technology.

However, future technology may potentially enable cracking of such hashes. Even when MD5- hashing is used, for which successful attacks have been demonstrated, the present method still provides significant security due to the potential length and complexity of the substitute password, asthe time to crack a hash is generally proportional to the length of the input to the hash function.

Even then, if the substitute password is illicitly obtained, it cannot be used to login, as noted above, due to being different from the original password.

Optionally, in the method of the first aspect, each predefined numerical value of the unique table 5 corresponds to a plurality of predefined character strings. For instance, a predefined numerical value may correspond to two or more predefined character strings. For example, when a numerical value of the numerical sequence is matched with a predefined numerical value in the unique table, one of the plurality of predefined character strings corresponding to the predefined numerical value may be used, depending on the position of the numerical value in the numerical sequence. Other methods of selecting the one of the plurality of predefined character strings can also be envisaged.

Optionally, in the method of the first aspect, the unique table is read-only. Preferably, the unique table is encrypted to prevent potential misuse by persons with bad intentions (e.g., hackers). It is preferred that the unique table is non-fungible, to retain the ability of matching a password input by the user (c.g., whilst logging in) with the hashed password stored on the database.

Optionally, in the method of the first aspect, the unique table is associated with a unique ID of the database. The unique table may be associated with a hardware identifier of the database, ora software-defined identifier. The unique table may additionally or alternatively be associated with a network identifier of the database, or the like.

Optionally, in the method of the first aspect, the unique table is uniquely associated with one unique entity. Preferably, each table is unique to a business or government entity. It is preferred that the above method, performed by each of these entities, uses a different unique table for each of these entities. A managing entity, managing the implementation of the method at various entities, may be tasked with ensuring the uniqueness of the tables for each entity. For instance, the managing entity may comprise a database, or other form of memory or ledger, comprising an (encrypted) version of each unique table, referenced to the entity using the specific unique table.

According to second aspect of the present disclosure, a method for securely verifving an input password is provided. The method preferably being computer-implemented. The method comprising the steps of: - receiving an input password to be verified. the input password comprising one or more characters: - performing a first transformation, comprising:

- determining numerical values on the basis of the one or more characters of the input password, and - converting the input password to a numerical sequence representative of the input password based on the determined numerical values; - accessing a unique table, associated with a database comprising a stored hashed password, the unique table comprising one or more predefined numerical values respectively corresponding to one or more predefined character strings; - performing a second transformation, comprising: - matching the numerical sequence to one or more predefined numerical values of the unique table, and - converting the numerical sequence to a substitute input password by combining one or more the predefined character strings corresponding to the one or more matched predefined numerical values of the unique table: - performing a third transformation, comprising: - converting the substitute input password to a hashed input password by hashing the substitute input password; - comparing the hashed input password to the stored hashed password in the database.

Preferably, the input password is verified when the hashed input password matches the stored hashed password in the database. Accordingly, the verification of the input password preferably fails when the hashed input password does not match the stored hashed password in the database.

Preferably, the stored hashed password in the database is associated with a user ID.

The method of the second aspect is complementary to the method of the first aspect. The method of the first aspect is used when making a user account, which user account is stored on the database and comprises at least a password. and preferably also a user ID. The method of the second aspect is subsequently used for logging in the user to the created user account. To login, the user provides, ¢.g., his user ID, and an input password. The method of the second aspect verifies that the input password corresponds to the password stored on the database (which is associated to the user account) as a result of the method of the first aspect. Accordingly. in the method of the second aspect, the input password should go through the same transformation steps as defined in the method of the first aspect, in order to be able to compare the hashed input password to the stored hashed password in the database. When the hashed input password is equal to the stored hashed password, the correct password was entered for the specific user account, and the login can be effected by the system (e.g., server comprising the database, or the like).

According to a third aspect of the present disclosure, an electronic device is provided, the device comprising a processor, and a memory coupled with the processor, wherein the processor is configured to execute a computer program code stored in the memory to perform the method steps as defined in the method of the first aspect and/or the second aspect. Preferably, the electronic device is comprised in a server, the server preferably comprising the database. Hence, the electronic device has the benefits of the methods as detailed above and below in the detailed description.

According to a fourth aspect of the present disclosure, a computer program is provided, the computer program comprising instructions which. when the program is executed by a computer, cause the computer to carry out the method of the first aspect and/or the second aspect. Hence, the computer program has the benefits of the methods as detailed above and below in the detailed description.

According to a fifth aspect of the present disclosure, a computer-readable medium is provided, the medium comprising instructions which, when executed by a computer. cause the computer to carry out the method of the first aspect and/or the second aspect. Preferably, the computer-readable medium is a non-transitory computer-readable medium. Hence, the medium has the benefits of the methods as detailed above and below in the detailed description.

BRIEF DESCRIPTION OF DRAWINGS

The present invention will hereinafter be elucidated by means of illustrative examples with reference to the attached drawings, wherein:

FIG. | depicts an exemplary method for transforming a password to a hashed password:

FIG. 2 depicts an exemplary system for storing and verifying passwords;

FIG. 3 depicts an exemplary database layout;

FIG. 4 depicts an exemplary account creation flow; and

FIG. 5 depicts an exemplary account login flow.

It is noted that the figures presented herein are for illustrative purposes only, and are not to be construed as limiting the scope of protection in any way.

DETAILED DESCRIPTION

In FIG. 1, an exemplary method 100 for transforming a password 101 is shown. The input to the method 100 is a password 101, and the output of the method is a hashed password 104. Three separate transformations 110, 120, 130 are performed to transform the password 101 to the hashed password 104. The method 100 may be implemented on a computer (or other suitable electronic device), e.g., as a computer program comprising instructions for carrying out the method 100.

Firstly, a first transformation 110 is applied to the password 101, which converts the password 101 to a numerical sequence 102. For instance, the first transformation 110 may comprise determining numerical values on the basis of the one or more characters of the password 101, and converting the password 101 to a numerical sequence 102 representative of the password 101 based on the determined numerical values. The numerical values may for instance be determined by using the

ASCII character encoding of the one or more characters of the password 101.

Secondly, a second transformation 120 is applied to the numerical sequence 102 that has resulted from the first transformation 110. The second transformation 120 converts the numerical sequence 102 to a substitute password 103. For instance, the second transformation 120 may comprise matching the numerical sequence 102 to one or more predefined numerical values of a unique table, and converting the numerical sequence 102 to a substitute password 103 by combining one or more the predefined character strings corresponding to the one or more matched predefined numerical values of the unique table. The unique table may be predefined, and may be associated with a specific database, the unique table may comprise one or more predefined numerical values respectively corresponding to one or more predefined character strings. Accordingly, the unique table is used in the second transformation 120 to obtain a substitute password 103.

Thirdly, a third transformation 130 is applied to the substitute password 103 that has resulted from the second transformation 120. The third transformation 130 converts the substitute password 103 to a hashed password 104. For instance, the third transformation 130 may comprise converting the substitute password 103 to a hashed password 104 by hashing the substitute password 103, e.g., by using a hashing function such as SHA-256.

The hashed password 104 may for instance be stored in a database, or compared to a pre-existing value, For instance, the method 100 may be used in an account creation process, wherein a user input a password 103, which is subsequently output to a database as a hashed password 104, which can be securely saved in a database. The method 100 may subsequently be used in a login process, wherein a user provides an input password 103, which is output as a hashed input password 104 that may subsequently be compared to a stored hashed password 104 in a database. If the hashed input password 104 corresponds to the stored hashed password 104. the login is successful (i.c., the input password matches the password originally used in the account creation process).

FIG. 2 illustrates an exemplary system 2 for storing and verifying passwords. The system 2 comprises an electronic device 20, which in tum comprises a processor 200 and a memory 201 which are functionally coupled to each other. The electronic device 20 is communicatively coupled to a database 21 (or altemative storage medium 21). In the present example, the database 21 is external to the electronic device 20, but it may also be internal to the electronic device 20 in other examples, or may be part of the memory 201 of the device 20. The database 21 may be configured to store user account information, that comprises stored hashed passwords. The processor 200 of the device 20 may be configured to execute a computer program code stored in the memory 201 to perform a method for transforming a password to a hashed password, such as the method 100 for transforming a password 101 to a hashed password 104 of FIG. 1. The device 20 is further communicatively coupled to an input interface 22, which may be a physical or virtual unit. User input may be provided to the device 20 through the interface 22, and the device 20 may provide output to a user through the interface 22. For instance, a user creating a user account may provide a new password to the device 20 through the interface 22, which the processor 200 transforms to a

I5 hashed password, which is subsequently communicated to the database 21 which stores the hashed password. In another example, the user logging into its user account may provide an input password to the device 20 through the interface 22 which the processor 200 transforms to a hashed input password, which is subsequently communicated to the database 21 and compared to a stored hashed password, stored in the database 21. The device 20 may convey the result of the comparison to the user as output through the interface 22. In particular, when the hashed input password corresponds to the stored hashed password, associated with the user account of the user, the user is successfully logged into its user account.

In FIG. 3, an exemplary database layout 300 is shown. The layout 300 uses columns 301, 302 and rows 303 to organize data (¢.g., email address and associated passwords). In this example, email addresses are saved in an email column 301, and passwords are saved in a password column 302.

Each of these columns 301, 302 comprises rows 303, wherein an email in a specific row (e.g., row number 5) is associated with a password in said specific row (e.g., row number 5). Email addresses can be saved as a string datatype in the email column 301, and associated passwords can be stored asa binary large object (blob) datatype. Generally, passwords stored in databases are hashed passwords, for security reasons. Hashes are usually not saved as numeric or alphanumeric values, but as blob. In a user account creation process, a user typically inputs its email address and a password. The password is subsequently transformed to a hashed password, for instance by use of the method 100 for transforming a password 101 to a hashed password 104 of FIG. 1. The email address is saved in the email column 301 as string datatype and the associated hashed password is saved in the password column 302 as blob datatype. Both are saved on the same row 303. In a user login process, the user may input an email address and an input password, wherein the input password is transformed to a hashed input password, for instance by use of the method 100 for transforming a password 101 to a hashed password 104 of FIG. 1. The email address may then be looked up in the email column 301 and the hashed input password may be compared to the stored hashed password associated with the email address in the password column 302 on the same row 303 as the email address.

FIG. 4 shows an exemplary account creation flow 400 for creating a user account. The user is referred to here as actor A. The flow 400 is started by the actor A by submitting an account form 401, which contains at least a password and preferably also a user ID, to a create account page 410.

The create account page 410 sends the information submitted by the actor A as actor data 402 to the create account service 420, which handles the creation of the user account for the actor A. In order to securely store the password submitted by the actor A, the create account service 420 submits the password 403 to the password protector 430, which performs a method for transforming the password 403 to a protected password 404, which is then retumed to the create account service 420. The actor data 405, including the protected password 404, is then submitted to the database 440 which saves the protected password. The method for transforming the password 403, that is executed by the password protector 430, is preferably the method 100 of FIG. 1.

FIG. 5 shows an exemplary account login flow 500 for logging into a user account. The user is referred to here as actor A, similar to the flow 400 of FIG. 4. In order to login to the user account, the actor A submits its login information 501, which contains a password and preferably also a user

ID. to the login page 510. The login page 510 sends the login information 501 provided by the actor A as information to be checked 502 to the login service 520, which handles the login process.

During the account creation process (e.g. the account creation flow 400 of FIG. 4) the password of the actor A was stored as a protected password in a database. Accordingly, the input password 303 has to be transformed to a protected password 504, which can be compared with the stored protected password in the database. Hence. the mput password 503 is transmitted to the password protector 330 by the login service 520. The password protector 530 of FIG. 5 may be the same as the password protector 430 of FIG. 4. The method for transforming the input password 503, that is executed by the password protector 530, is preferably the method 100 of FIG. 1. The password protector 530 outputs the protected password 504 to the login service 520, which is subsequently transmitted as protected password to be compared 505 to a comparator 540. The comparator 540 compares the protected password to be compared 505 to a stored protected password of the actor

A, and thereby determines whether the input password 503 used in the login information 501 corresponds to the stored password provided by the actor A during the preceding account creation process (e.g., the account creation flow 400 of FIG. 4). If the protected password to eb compared 505 is equal to the stored protected password, the login succeeds. Otherwise. the login fails, i.e. the actor A is not granted access to the user account.

The illustrative embodiments or examples described above are not to be construed as limiting the scope of protection, which is determined by the appended claims.

Claims

CONCLUSIONS

I. Computer-implemented method for securely storing a password in a database, comprising the steps of: receiving a password to be stored in a database, the password comprising one or more characters: performing a first transformation . comprising: determining numerical values based on the one or more characters of the password, and converting the password into a numerical sequence representative of the password based on the determined numerical values: accessing a unique table , associated with the database, wherein the unique table comprises one or more predetermined numerical values corresponding respectively to one or more predetermined character strings. performing a second transformation, comprising: matching the numeric sequence with one or more predetermined numeric values of the unique table, and converting the numeric sequence into a replacement password by combining one or more of the predetermined strings corresponding to the one or more matched predetermined numerical values of the unique table: performing a third transformation, comprising: converting the replacement password to a hashed password by hashing the replacement password: storing the hashed password in the database.

2. Method according to claim 1, wherein the first transformation comprises: transforming the one or more characters of the password into the one or more numerical values by means of character encoding, preferably wherein the character encoding is ASCII encoding is.

A method according to claim 1 or 2, wherein the second transformation comprises: prior to matching the numerical sequence with one or more predetermined values of the unique table, modifying the numerical sequence by applying at least one predetermined mathematical function on the numerical sequence.

4. Method according to any one of the preceding claims, wherein the unique table comprises a plurality of unique sub-tables.

The method of claim 4, wherein the second transformation includes: matching the numeric sequence with one or more predetermined numeric values from each of the plurality of unique sub-tables, and converting the numeric sequence to the replacement password by combining one or more predetermined strings corresponding to the one or more matched predetermined numerical values from each of the plurality of unique sub-tables.

6. Method according to any one of the preceding claims, wherein the third transformation comprises: hashing the replacement password using a standard hash function, preferably wherein the standard hash function is SHA-256.

7. Method according to any one of the preceding claims, wherein each predetermined numerical value of the unique table corresponds to a plurality of predetermined character strings.

8. Method according to any one of the preceding claims, wherein the unique table is read-only.

9. Method according to any one of the preceding claims, wherein the unique table is associated with a unique ID of the database.

10. Method according to any one of the preceding claims, wherein the unique table is uniquely associated with one unique entity.

11. Electronic device, comprising: a processor; and a memory coupled to the processor, wherein the processor is arranged to execute a computer program code stored in the memory for carrying out the method steps as defined in any of the preceding claims.

12. Server, comprising the electronic device according to claim 11.

13. Computer program, comprising instructions that, when the program is executed by a computer, ensure that the computer executes the method steps according to any of the claims 1 - 10.

14. Computer-readable medium, comprising instructions that, when executed by a computer, ensure that the computer carries out the method according to any one of claims 1 to 10.

The computer-readable medium of claim 14, wherein the computer-readable medium is a non-transitory computer-readable medium.