Login page password-guessing attack (Accunetix)

A common threat web developers face is a password-guessing attack known as a brute force attack. A brute-force attack is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until you discover the one correct combination that works.

This login page doesn’t have any protection against password-guessing attacks (brute force attacks). It’s recommended to implement some type of account lockout after a defined number of incorrect password attempts. Consult Web
references for more information about fixing this problem.

CVSS Base Score: 5.0
– Access Vector: Network
– Access Complexity: Low
– Authentication: None
– Confidentiality Impact: Partial
– Integrity Impact: None
– Availability Impact: None
Affected item /Admin/Login.aspx
Affected parameter
Variants 2

Blocking Brute-Force Attacks

A common threat Web developers face is a password-guessing attack known as a brute-force attack. A brute-force attack is an attempt to discover a password by systematically trying every possible combination of letters, numbers, and symbols until you discover the one correct combination that works. If your Web site requires user authentication, you are a good target for a brute-force attack. Continue reading “Login page password-guessing attack (Accunetix)”

How to create a hashed MD5 password?

While some systems have not heard of the MD5 vulnerability, they might require you to build up a hashed password.
Here’s the code in C# and VB.net. Once you’ve grabbed the code you need, have a read on the two links below detailing MD5 Hash collisions.

using System.Security.Cryptography;
 // step 1, calculate MD5 hash from input
    MD5 md5 = System.Security.Cryptography.MD5.Create();
    byte[] inputBytes = System.Text.Encoding.ASCII.GetBytes(input);
    byte[] hash = md5.ComputeHash(inputBytes);
// step 2, convert byte array to hex string
    StringBuilder sb = new StringBuilder();

    for (int i = 0; i < hash.Length; i++)
    return sb.ToString();


Private Function GetMd5Password(ByVal psStr AsString) As String 
Dim md5Hasher As New MD5CryptoServiceProvider()
Dim sBuilder As New StringBuilder()
Dim nX As Integer' Convert the input string to a byte array and compute the hash.
Dim byData As Byte() = md5Hasher.ComputeHash(ASCIIEncoding.Default.GetBytes(psStr))

' Create a new Stringbuilder to collect the bytes and create a string.
' Loop through each byte of the hashed data and format each one as a hexadecimal string.
For nX = 0 To byData.Length -1
' Return the hexadecimal 
End Function

MD5 was intended to be a cryptographic hash function, and one of the useful properties for such a function is its collision-resistance. Ideally, it should take work comparable to around 264264 tries (as the output size is 128128 bits, i.e. there are 21282128 different possible values) to find a collision (two different inputs hashing to the same output). (Actually, brute-forcing this is today almost in the range of possible, so this alone would be a reason not to use any small-output hash function like MD5.)

http://www.mscs.dal.ca/~selinger/md5collision/ Explanation of how MD5 collisions occur
http://www.links.org/?p=6 MD5 Collisions Visualised

Passwords – Authentication

Passwords and passcodes are the most common way of authenticating users. Examples of their use includes the PIN (Personal Identifier Number) you use with your debit and credit card as well as the many passwords you are expected to remember when logging in to computer-based services.

https://www.youtube.com/watch?v=CjLwSLxwEk0 Continue reading “Passwords – Authentication”

Website Security – Confidential Information?

corporate_confidentialSecurity doesn’t seem to be such a major issue on a corporate intranet as it is on the public Internet. After all, this network is not public. But business considerations can make security an important issue with which to deal.

If security on an intranet is centralized, it is usually controlled by a corporate organization. Many corporations currently do not have centralized security for their intranets, which is unfortunate as much of the hacking done today occurs on private rather than public networks.

If your corporation does have central control of intranet security, those in charge will have security standards that your application must meet before you can place it on the intranet. As with other corporate organizations, you will probably have to plan in advance to work with the corporate security department. Some intranets might even use centrally administered security for logon passwords and other security issues.

Most technicians find that security concerns often conflict with the technical considerations of their applications. Technical advances often outstrip the security department’s ability to accommodate them. You might devote your time to security modules that seem overly burdensome and might find that you are unable to implement some technologies on the intranet because of security requirements and concerns. But by planning ahead, you can prepare time in your design and construction schedules to accommodate these security needs.

Protecting Confidential Material

Another concern in intranet applications is protecting confidential material. It is true that your application is operating over corporate resources, but it can pass data that should not be seen by unauthorized employees, contractors, customers, and others who have access to the intranet. Many confidentiality issues discussed in Chapter 1 for the Internet also can be applied to intranet applications. Because the intranet and Internet are both TCP/IP networks, they have the same limitations and problems when plain text is transmitted across them.

One issue that requires a balancing act is the need for confidentiality versus the availability of information for the corporate community. Security and confidentiality issues are always cost-benefit tradeoffs.

Remember also that you might have to apply local, state, and even national laws to the information in your application even though it passes over your private intranet. Personnel and financial applications are often subject to these laws. Another interesting consideration that spans political jurisdictions-states, provinces, or even countries-is that various segments of the intranet might be subject to different laws when it comes to the confidentiality of the information carried on them.

Security Versus Availability

Maintaining security and confidentiality is a juggling act. On one side is the need to keep information secure and confidential, and on the other side is the need to make information available. There are no hard-and-fast rules for managing this dilemma. You could write an entire book on security and confidentiality issues. In a single chapter, I can provide only some guidelines by which you can develop your application.

You will need to examine two things to determine the level of security that your application requires. First, determine how sensitive your data is. Some data is easy. For example, if you are developing an organization chart application that will display information about your employees such as social security numbers, home addresses, and phone numbers, you are dealing with sensitive information that should be protected from unauthorized access. Other information is more subtle. Let’s say you’re working on a marketing application that will enable your managers and sales representatives to share information about current and potential customers. You might think that this information doesn’t need to be very tightly secured; after all, this is your internal network-your intranet. This brings us to the second consideration in the security versus availability dilemma.

Stop for a moment to consider the people who have access to your intranet. If you are part of a company of any size, you probably have all sorts of people in your intranet:

  • Employees
  • Temporary help
  • Consultants and vendors
  • Customers

Would you want all of these people to look at your data? Even subtle data can have an impact on your business. Let’s say you want to put your company newsletter online. Along with those announcements of company activities, the local bowling league scores, and the picture of the employee of the month is an article about your marketing strategy. If consultants, vendors, or customers had access to this information, it could give them (or their other customers) a competitive advantage in the future.

If your intranet has a mix of people on it, consider giving non-employees IDs that are easily identified, perhaps with special characters in certain positions. Secure all confidential or potentially damaging information with secured Web servers. Require access via ID and password. Your application can detect the special IDs and deny access to the information.

One interesting fact is that very few corporations have implemented internal firewalls on their intranets. You might consider implementing a firewall, especially if you are designing a sensitive divisional or departmental application that needs to be isolated from other divisions or departments.

How do you decide the security issues? Only you can do so. Look at the data, and then give some thought about the people who are using your intranet. If you have any doubt, secure the information. A few tips follow.

  • If you have any doubt about the security if your intranet, run your application on a secure server and pass information only to users with secure browsers to ensure that your sensitive information will not travel over your network as plain text.
  • Develop a central security system that can identify the various types of users by user ID and password.
  • Accept connections only from known, secure IP addresses. Make sure that machines that are accessible to unauthorized personnel cannot access your application. Use filters on your router, if appropriate, or refuse to send pages from your server to unknown IP addresses.

Change Passwords Periodically

Given a choice, most of us would select a password that was easy to remember, never change it, and use the same password everywhere. Your corporate security group probably has standards much stricter than that-for a reason. Easy passwords that never change are easy to crack, and once passwords are cracked, hackers can use them again and again.

Never send passwords via electronic mail unless the message is heavily encrypted. In fact, just to be safe, never send passwords through electronic mail, period!

If you must use passwords in your application, change them periodically. Once a month is typical, though your application might require more or less frequent changes. If you use the HTTP password capability, you will want a separate process for updating passwords. One way is to use corporate security files to obtain passwords. Another suggestion is to alter the passwords periodically yourself and distribute them to your users via a secure mechanism. Never send passwords in an electronic mail message unless the message is encrypted!