After 5 failed login attempts the brute force prevention system kicks in. Users will be forced to a 'waiting' screen before they can attempt to login again. The wait time is exponential to the number of failed login attempts. To illustrate:
|# of Failed Attempts||Next Wait Time||Total Time Waited|
|10||1 minute and 40 seconds||Over 5 minutes|
|100||Over 16 minutes||Over 3 days|
|1000||Over 11 days||Over 10 years|
To try 1000 passwords it would take a hacker over 10 years. To put that in perspective there are 1,265,319,018,496 permutations of a 6 character password using all keys on a standard keyboard. Dictionary attacks are also rendered useless because most word lists contain thousands of entries.
In the Framework Administration area there is a page where you can monitor failed login attempts. Anyone who looks suspucious you can add to the Blacklist. Brute force prevention applies to the front-end website as well as the backend service.
In order for users to create an account or change their password, their password must satisfy the password complexity rules. Complexity rules can be set on a per-Domain basis.
Where ever the user can create or update their password a password strength meter tells the user how strong their password is.
Users can be forced to change their password after a certain number of days.
When changing passwords, previously used passwords cannot be used if it has been within the allowed time period.
The Blacklist is a list of IP addresses that are not allowed to access the site. When a request is made by a user whose IP address is on the list they will be redirected to a page explaining why they cannot access the site and contact information if they feel they were banned by mistake. This goes not only for the front-end website but also for the backend service.
No one wants to maintain lists like these though - which is why we have a feature to automatically blacklist an IP address after a certain number of failed login attempts. You choose what that threshold is.
Each domain has the ability to restrict users to logging in from a range of IP addresses. This added protection will help ensure that only the users you intend to login are actually doing so.
Dormant accounts can be locked automatically after a certain number of days.
Cookies are used to persist authentication and are encrypted using ASP.NET Forms Authentication. Even if you could decrypt the cookie (very unlikely), the encrypted value is a User ID not a User Name. You can't use a User ID to login and knowing it serves no purpose.
A Service Oriented Architecture provides an added level of security. The front-end website can reside in your DMZ while the backend (WCF) service can reside in your internal network along with the database.
In order to access the backend service you must first obtain a validation ticket. Validation tickets contain a computed hashed and are checked whenever a service method contains a ValidationTicket type in its method signature. This technique can also be applied to services you create and integrate into the framework. It is a fast and easy and gives you great control over what users can do with your services.