Protecting passwords is not a simple task. For material that is not highly sensitive, it is enough just to make it difficult for the hacker. That involves using passwords at least 8 characters in length and using a variety of characters (upper, lower, and special characters). The more characters used, the more difficult it is to guess. I have operated a fake mail server for many years, and I still get more than 200 attempts a day to guess the UserId/passwords, even though there are no actual accounts.
Using encryption helps with more sensitive material, but it does nothing to stop password guessing. Even temporarily suspending an account if too many attempts are made does not prevent password guessing. The hacker simply spreads out those guesses over time.
Any time a key or password is stored on a system, it is vulnerable no matter what extremes are used to try and protect it. Forward secrecy helps protect against key theft because the keys are not stored, and passwords should always be stored encrypted or hashed.
Then there is the problem of man-in-the-middle. Even with encryption, it does not take a lot of computer power to figure out the key used to encrypt short passwords. The best defense against that is to use Forward Secrecy, so that even if the hacker is able to figure it out for one session, the key is different for the next session. Even better yet would be to use a different password for every connection, encrypted or not. That is what I have attempted to do in this post.
The principle used in this program is to shuffle the password on each and every connection. To enable authentication of the password, one end must be able to un-shuffle the password, and this is accomplished by using a Seed. In this case, the Seed is calculated from the previous password. This is similar to the way the Visual Basic Rnd function works. Even though it is not truly random, the hacker does not know where in the cycle the client and server are at. Even if the hacker is able to determine the current password and establish a connection, the real client will be alerted on the next connection attempt, and take corrective action. This is the same principle used in Forward Secrecy, except that in this case the user is notified of the intrusion.
To demonstrate this technique, I am using the PicServer program previously posted, along with 2 special Web pages and a JavaScript file. In this case, I have chosen to manually enter the UserID into the database in order to control who can access the files. The user can then add the password. I needed a unique value in the browser, so I added a Time/Date stamp to the browser Local Storage at the same time as the UserID cookie is created. The password that the user enters is then used to calculate the Seed to shuffle the Time/Date stamp, thus forming the originating Password. The originating Password is then sent to the server, and the password cookie in the browser is updated. When the browser attempts a new connection, the UserID and Password cookies are sent to the server in the Get request. The server un-shuffles the Password cookie using the stored Password as the Seed, and compares it to the Password in it's database. If successful, the stored Password as well as the browser Password cookie are updated. The effect is that the stored Password in the server is always one step behind the browser Password cookie.
Using this technique, the user only has to login once. Thereafter, the authorization is automatic on every connection. I am using HTTP 1.1, which allows a connection to be maintained as long as there is traffic. That timeout varies with the browser, and I have yet to establish a timeout for the server. To reset the password, one only has to delete the Password cookie. This feature is currently a security risk. What is to prevent the hacker from learning the UserID and resetting the password? I am open to suggestions.
To prevent the user from directly accessing the JavaScript files, they have been hidden. To further restrict access, those files may have to be moved to a hidden directory.
If you think about it, this technique permits access from a specific browser. If you use a different browser or a different computer, it will require a different UserID.
This program should be considered a work in progress, and eventually will be converted to run as a service. It has only been tested it on 2 different FireFox browsers I have at my disposal. Constructive feedback is welcome.
Currently, access information (including the IP address) is displayed in the text box. and will be re-routed to a log file when it becomes a service. Setup instructions can be found in the Readme file.
J.A. Coutts
Using encryption helps with more sensitive material, but it does nothing to stop password guessing. Even temporarily suspending an account if too many attempts are made does not prevent password guessing. The hacker simply spreads out those guesses over time.
Any time a key or password is stored on a system, it is vulnerable no matter what extremes are used to try and protect it. Forward secrecy helps protect against key theft because the keys are not stored, and passwords should always be stored encrypted or hashed.
Then there is the problem of man-in-the-middle. Even with encryption, it does not take a lot of computer power to figure out the key used to encrypt short passwords. The best defense against that is to use Forward Secrecy, so that even if the hacker is able to figure it out for one session, the key is different for the next session. Even better yet would be to use a different password for every connection, encrypted or not. That is what I have attempted to do in this post.
The principle used in this program is to shuffle the password on each and every connection. To enable authentication of the password, one end must be able to un-shuffle the password, and this is accomplished by using a Seed. In this case, the Seed is calculated from the previous password. This is similar to the way the Visual Basic Rnd function works. Even though it is not truly random, the hacker does not know where in the cycle the client and server are at. Even if the hacker is able to determine the current password and establish a connection, the real client will be alerted on the next connection attempt, and take corrective action. This is the same principle used in Forward Secrecy, except that in this case the user is notified of the intrusion.
To demonstrate this technique, I am using the PicServer program previously posted, along with 2 special Web pages and a JavaScript file. In this case, I have chosen to manually enter the UserID into the database in order to control who can access the files. The user can then add the password. I needed a unique value in the browser, so I added a Time/Date stamp to the browser Local Storage at the same time as the UserID cookie is created. The password that the user enters is then used to calculate the Seed to shuffle the Time/Date stamp, thus forming the originating Password. The originating Password is then sent to the server, and the password cookie in the browser is updated. When the browser attempts a new connection, the UserID and Password cookies are sent to the server in the Get request. The server un-shuffles the Password cookie using the stored Password as the Seed, and compares it to the Password in it's database. If successful, the stored Password as well as the browser Password cookie are updated. The effect is that the stored Password in the server is always one step behind the browser Password cookie.
Using this technique, the user only has to login once. Thereafter, the authorization is automatic on every connection. I am using HTTP 1.1, which allows a connection to be maintained as long as there is traffic. That timeout varies with the browser, and I have yet to establish a timeout for the server. To reset the password, one only has to delete the Password cookie. This feature is currently a security risk. What is to prevent the hacker from learning the UserID and resetting the password? I am open to suggestions.
To prevent the user from directly accessing the JavaScript files, they have been hidden. To further restrict access, those files may have to be moved to a hidden directory.
If you think about it, this technique permits access from a specific browser. If you use a different browser or a different computer, it will require a different UserID.
This program should be considered a work in progress, and eventually will be converted to run as a service. It has only been tested it on 2 different FireFox browsers I have at my disposal. Constructive feedback is welcome.
Currently, access information (including the IP address) is displayed in the text box. and will be re-routed to a log file when it becomes a service. Setup instructions can be found in the Readme file.
J.A. Coutts