passwords and encryption

Secure passwords with hashes and salts

As we all know, the purpose of a password is above all to remain known to a person or a group of persons. Its disclosure then leads to the complete loss of its effectiveness and safety. When the password becomes known to a third party, the latter may, for example, appropriate rights over an application and compromise its normal operation. A password is extremely sensitive and coveted by hackers, regardless of the application that uses it.

What is a password?

Metaphorically, a password can be perceived as a critical opening door(s) to the one who holds it. Thus, this user appropriates additional rights that other people do not have. It is then up to him not to disclose it so that an evil third party does not misappropriate the privileges conferred on him.

When one / several passwords must be saved in an information system (database, configuration files…), it becomes more complicated. Indeed, security is only for one person but now depends on the security of the information system itself (physical access, identifiers to connect to it) as well as on the way these passwords are stored in the IS.

Password security in an information system

It is evident that increased password protection in the information system must be put in place. The storage of passwords in clear text in the information system then becomes impossible. Why? Why? Let us take the typical case of a database in which are stored the identifiers of the users of an extranet of a company. This implies that there is a security policy with several levels of rights.

A technician will not have the same privileges on the application as his superior. The latter will also not have the same rights as the Director of Human Resources or the CEO. In this type of application, the password is the guarantor of data security. We must, therefore, protect it assiduously. Encryption then becomes indispensable.

Why encrypt sensitive data?

The answer is simple. This is to keep confidential the password that has been assigned to the user outside of the application. There is also a part of deontology insofar as even the person in charge of the application should not have to know the personal identifiers of the users. It’s none of his business. Let us return to our example.

Extranet also means access to the application from the Internet. The data must then be encrypted via a secure HTTPS connection and the application protected against possible hacker access. Let us suppose that this extranet was poorly written and that it contains a SQL injection flaw. A hacker could then retrieve the passwords stored in the database and enter the application without any problem with the CEO’s credentials. If passwords are encrypted, it will be much harder for the hacker to retrieve their plaintext match. In this example, the attack comes from the outside but what if the weakness of the system is inside?

Indeed, let us suppose that it is necessary to maintain the database by connecting directly to it. The company that edited the application sends its database administrator into intervention. This technician intervenes on the spot but is not at all part of the company which uses the application. She’s going to manipulate the database. That is, she will most likely be able to see everything inside… including the login credentials. If the passwords had been recorded in plain text, he could have appropriated the accesses of any user on the extranet application… Nevertheless, nothing prevents him from creating a new user with all the rights directly in the database. We will, therefore, see later that traditional encryption is not enough to strengthen the security of a password.

Encryption methods

There are many of them. This can range from encryption algorithms (which can be decrypted with the appropriate algorithm and key) to hash algorithms. It is the latter that we tend to use today. Indeed, a hash algorithm can encrypt a string without the possibility of reverse operation. The hash result usually produces a single, fixed-length string. This is the case, for example, with MD5 and SHA1 algorithms. Thus, during an authentication phase, two passwords are no longer compared in plain text but two hashes of the password.

rsz_php_5_to_7

Migration from PHP 4 to PHP 5

PHP 4 support is a thing of the past. It is therefore becoming urgent to migrate to PHP 5 because in 2008 no new version of PHP 4 will be released (support will still be provided on security vulnerabilities until 08/08/2008).

The compatibility between PHP 5 and PHP 4 has been a major concern during the development of PHP 5, and a large majority of applications should be able to run on PHP 5 without problems, or require only minor modifications. There are however some differences and we will try to summarize them here to allow you a simple migration.

Why migrate?

New features
Better performance
Better security
Better stability
PHP 5 is strongly supported

What has changed with PHP 5?

the redesign of the PHP core which allows a complete support of object-oriented programming
XML support redesign
SQLite embedded database integration
integration of new extensions (JSON, Filter, ZIP, …)
the emergence of a common basis for managing database calls: PHP Data Object (PDO)
the use of object reflection ( introspection)
exceptions have appeared in PHP5
an E_STRICT error level has been added
appearance of the SPL (Standard PHP Library), a collection of useful internal classes

Although most existing PHP 4 scripts should work, it is worth noting some major differences that can lead to errors or different behaviors:

Object management (referencing)
the redesign of DOM support with the abandonment of the DomXML extension
MySQL extension is no longer included by default
new error mode E_STRICT
The new object model

The main novelty of PHP 5 is certainly the new object model. Object processing has been completely rewritten to achieve better performance and more functionality. To date the object model of PHP 5 is close to that of Java, it thus results from it a certain number of innovations: magic methods, visibility, (was already present in PHP4, the novelty it is the destroyer or more generally the magic methods), encapsulation, cloning, interfaces, abstract classes…

Objects are passed by reference

In PHP 4 the entire object was copied when it was assigned or passed as a parameter to a function. In PHP 5 objects are referenced by a pointer and not their value (one can think of a pointer as an object identifier).

Pass an object by reference

Objects are no longer passed by value but by reference. The result is that once transmitted to a function, a PHP 5 object will see its values evolve while in PHP 4 it is a copy that will be modified within the function, the original object will remain unchanged.

In PHP 4 to make an object pass as reference we could do it by prefixing the variable with the sign”&”. Test our Xxxx example by removing the”&” in the declaration of the “fctActionObject()” function, you will see that in one case the”$b” object is modified and in the other it is not (and because the modification was made on a temporary copy).