Web application password protection
I want to talk about my own experience in protecting web applications used in enterprises / firms with a limited number of employees.
Let's talk about the system when users are authenticated only with passwords.
First of all, I advise you to read Habratopik.
')
I want to note that password protection is not the only way to authenticate, but at the moment the most familiar and used.
The first task that confronts the developer of the security system is reliable user authentication.
When choosing a password method, the developer has little room for maneuver.
He has fields for work:
1. Login
2. Password
Sometimes, to this can be added the input field of the domain, company, division.
In most cases, the login and any additional field (the company, etc.) are known to a wide range of people, and only the password is really confidential.
At the same time, the password cannot be complicated (see Where it is thin, it breaks there ).
The only thing that a developer may require from users is to periodically change the password to another, convenient user.
And, in fact, the entire security system is based on the method of the exchange of identification data (hereinafter - simply data) and the policy of the users in the system.
1. First of all - it is a secure transfer of user data.
SSL is ideal, but unfortunately not always possible.
Simple hashing using the md5 algorithm and transmission is not interesting for us.
Much more correct to use HMAC . This method allows you to hash and transfer data, as well as it allows you to protect yourself from the collection of original user data in the case of one-way interception.
By "one-way" I mean the transfer of data from the client to the server.
2. Using the virtual keyboard.
Reduces the possibility of data capture by key loggers.
3. Block user after 7-10 failed login attempts.
Practically eliminates password cracking by brute force.
4. Changing the user ID in the system (session) after authentication.
In our case - change after successful user login.
5. Binding user to current client.
Solved by binding to IP and browser.
This minimizes the damage from stealing a user's session.
6. In the session on the part of the user - no data!
Only her ID.
7. Request to re-authenticate the user after N minutes of inactivity.
8. The system of binding users to specific IP / days / hours of work.
There’s nothing for an ordinary manager Kate to do in the system on Saturday at 02:23 with the IP of the American university network :).
9. The fundamental impossibility of working with the system through a proxy server.
Especially true when working without SSL.
Unfortunately, in some cases it is impossible to track.
10. And the most important thing is constant monitoring of the system operation!
Logging in / out of users, blocking, incorrect password input / searching, scanning for vulnerabilities and so on, everything is in the hands of a paranoid developer :)
Let's talk about the system when users are authenticated only with passwords.
First of all, I advise you to read Habratopik.
')
I want to note that password protection is not the only way to authenticate, but at the moment the most familiar and used.
The first task that confronts the developer of the security system is reliable user authentication.
When choosing a password method, the developer has little room for maneuver.
He has fields for work:
1. Login
2. Password
Sometimes, to this can be added the input field of the domain, company, division.
In most cases, the login and any additional field (the company, etc.) are known to a wide range of people, and only the password is really confidential.
At the same time, the password cannot be complicated (see Where it is thin, it breaks there ).
The only thing that a developer may require from users is to periodically change the password to another, convenient user.
And, in fact, the entire security system is based on the method of the exchange of identification data (hereinafter - simply data) and the policy of the users in the system.
1. First of all - it is a secure transfer of user data.
SSL is ideal, but unfortunately not always possible.
Simple hashing using the md5 algorithm and transmission is not interesting for us.
Much more correct to use HMAC . This method allows you to hash and transfer data, as well as it allows you to protect yourself from the collection of original user data in the case of one-way interception.
By "one-way" I mean the transfer of data from the client to the server.
2. Using the virtual keyboard.
Reduces the possibility of data capture by key loggers.
controversial: Comment .
3. Block user after 7-10 failed login attempts.
Practically eliminates password cracking by brute force.
4. Changing the user ID in the system (session) after authentication.
In our case - change after successful user login.
5. Binding user to current client.
Solved by binding to IP and browser.
This minimizes the damage from stealing a user's session.
6. In the session on the part of the user - no data!
Only her ID.
7. Request to re-authenticate the user after N minutes of inactivity.
8. The system of binding users to specific IP / days / hours of work.
There’s nothing for an ordinary manager Kate to do in the system on Saturday at 02:23 with the IP of the American university network :).
9. The fundamental impossibility of working with the system through a proxy server.
Especially true when working without SSL.
Unfortunately, in some cases it is impossible to track.
10. And the most important thing is constant monitoring of the system operation!
Logging in / out of users, blocking, incorrect password input / searching, scanning for vulnerabilities and so on, everything is in the hands of a paranoid developer :)
update: Items 4-10 refer not so much to password protection as to the security of the application as a whole.
Source: https://habr.com/ru/post/3802/
All Articles