The importance of strong credential management
Passwords are the most commonly-used method by which users authenticate to online accounts, computers and other systems. The reason for the massive adoption of usernames and passwords is that they are simple to understand, operate and use. Since users understand how passwords work and find them easy to use, they are often unwilling to switch to more secure but potentially less transparent and usable alternatives.
One of the challenges associated with secure use of passwords is that it is a symmetric system. A computer or program validates a user’s identity by comparing login credentials provided by the user with a version stored within the application. If these two sets of credentials match, then the user is authenticated and provided access to the system.
However, this also requires the application to securely store its users’ login credentials. If authentication information is accessible to an attacker, they may be able to use it to access the user’s account and any sensitive data or functionality that it contains.
How credential management goes wrong
Secure credential management can be extremely challenging. Credential storage and processing (in authentication systems) can go wrong in a variety of different ways. In many cases, even a simple error — such as using an insecure cryptographic algorithm or misusing salts in password storage — can render all protections for the user’s credentials useless.
Hardcoded credentials, where account credentials are embedded in the code of an application or a device’s hardware, are a serious security error. Analysis of the application’s code or data leaks from the manufacturer can result in these credentials becoming publicly known. If these credentials cannot be changed, this leaves an application or device permanently vulnerable.
However, this kind of design error is extremely common, especially in Internet of (Read more...)
*** This is a Security Bloggers Network syndicated blog from Infosec Resources authored by Howard Poston. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/c7Txsz8ogio/