|Password Recovery Solutions|
(c) Vitas Ramanchauskas
The "document" paradigm is used by many, many applications; for example, Word document, Excel document, Access database - that is also a "document" for the Access application. A ZIP archive is a document for the WinZip archiver, and so on. Oftentimes, there is a need to secure documents with passwords, give user the opportunity to set the password, so that users without the password could not access the protected document.
The problem of implementing a reliable password protection is quite unique - in the sense that on one hand it doesn't imply anything overcomplicated, and at the same time many programmers, not familiar with cryptography, in the practice implement it wrong, making the most serious errors. Especially amazing is the fact that even such monster and leader in IT as Microsoft has spent over 20 years (!) to get password protection in their lead product into the shape, and even that implies major reservations.
In the beginning, let's briefly review what password protection is to look like in order to provide the security. Here is the most common route a programmer not familiar with cryptography takes to solve the password protection problem: the password is stored in the document, and the header of the document is marked that the document is password-protected. When the application opens such document - if the document is marked as having a password, the password is requested from user and then compared with the password stored in the document. If those two match, the document opens up. This kind of protection is easy to implement, but it is absolutely unreliable - all it takes to spot the password stored is to simply view the content of the document. Thus, in this and similar cases password can be recovered even without running any special software. Due to obvious stupidity of such implementation, some developers come up with storing password in document in the encrypted format. This makes it impossible to find out the password by just looking at the content of the document; nevertheless, it doesn't make the protection more reliable. It takes very little to create a program that would simply extract and decrypt the password; no security whatsoever is all this approach provides. If you think professional developers cannot commit stupidity of this kind, you are mistaking. This exact principle was used for building the security in MS Access up until version 2003; the situation has been changed only in Access 2007 (at the expense making a new mistake in the implementation).
Some advanced developers come up with storing not the actual password, and not even an encrypted version of it, but its hash. Hash is a certain function that can work only in one direction; i.e., a hash can be obtained from a password quickly and easily, but the reverse conversion is literally impossible. This feature makes it possible to verify whether a password is valid (calculate the hash for the entered password and then compare the result with the stored hash), but to recover the password - that, generally speaking, is impossible. Well, it is possible to attempt searching all possible sequences of characters, checking for each of them whether or not its hash would match the stored value, but if the password is long enough, this method may require an unacceptably long time span. This "brilliant" idea was hit upon, particularly, by the developers of VBA modules (macros) in Microsoft Office. But does the method provide the security? Certainly, it does not. Moreover, it has two vulnerabilities at once:
So, what's the right way to protect the document with password? There's only one way, and it is simple enough. The content of the document is to be encrypted with a professional and secure encryption algorithm. Moreover, for the encryption key the program is to use the user-chosen password. The password itself should under no circumstances be stored in the document. The application, having prompted user for password, uses it for decrypting the document and checking its integrity, whether or not it's been decrypted properly. If so, that indicates that the password entered was valid, and it is now possible to continue with the encrypted document. If the password is unknown, all the user not knowing the password has is the encrypted document he can do nothing about.
Now, let's watch the evolution of password protection in Microsoft Office - the lead product of the leader of IT.
Copyright © 1997-2019 LastBit.com. All rights reserved.