DS5 – All sections should be reviewed. This section covers nearly all COBIT detailed control objectives.

DS5 – All sections should be reviewed. This section covers nearly all COBIT detailed control objectives.

−

==Best Practices ==

−

* '''Authentication is only as strong as your user management processes''', and in particular the user issuance and evidence of identity policies. The stronger the requirement for non-repudiation, the more expensive the process is.

+

==Architectural Goals==

−

* '''Use the most appropriate form of authentication suitable for your asset classification'''. For example, username and password is suitable for low value systems such as blogs and forums, SMS challenge response is suitable for low value e-commerce systems (in 2005), whilst transaction signing is suitable for high value systems such as high value e-commerce (all e-commerce sites should consider it by 2007), banking and trading systems.

+

All applications should take into account the following architectural and detailed design goals:

−

* '''Re-authenticate the user for high value transactions and access to protected areas''' (such as changing from user to administrative level access)

+

* All applications within your organization SHOULD share a well-debugged and trusted authentication mechanism if possible

+

* All secured functions and secured resources SHOULD be protected by a common authentication mechanism within the one application

+

* All applications MUST use the lowest possible privilege service account to access back end systems such as directories, web services, database and message queues

−

* '''Authenticate the transaction, not the user'''. Phishers rely on poorly implemented ''user'' authentication schemes. User authentication is valuable, but the real business value comes not from authenticating users because usernames and passwords can be stolen. Real security value stems from identifying fraudulent transactions. Unfortunately this can be significantly more complex.

+

* Credentials SHOULD be transmitted only over encrypted links, particularly weak authentication mechanisms such as passwords

+

* Credentials MUST be stored after being one-way hashed and salted using acceptable hashing algorithms

* Credential stores SHOULD be designed to implement several hashing algorithms as these will be replaced soon and as change is inevitable, your application should plan today for this transition

−

* '''Passwords are trivially broken and are unsuitable for high value systems'''. Therefore, the controls should reflect this. Passwords shorter than 16 characters are very susceptible to brute force attacks, so set your password policy to be reasonable:

+

* Applications SHOULD have the facility to alert the user as to failed login attempts and offer to allow them to change their password (if applicable)

−

# Train your users as to suitable password construction

+

* Applications SHOULD have the facility to notify the user of their last logged in time, and subsequently report a fraudulent login if they disagree with that date and time

−

# Allow your users to write down their passwords as long as they keep them safe

+

* Authentication and registration processes, particularly login failures, SHOULD provide no information as to if an account exists or password or is wrong. A single error message for the end user covering both scenarios is more than adequate

−

# Encourage users to use pass phrases instead of passwords

+

* All pages SHOULD have an effective logout button on every single page in a common location

−

# Relax password expiry requirements upon the strength of the password chosen – passwords between 8 and 16 that cannot be easily cracked should have an expiry of no less than 30 days, and pass phrases above 16 characters probably do not need a hard expiry limit, but a gentle reminder after, for example, 90 days instead.

+

* Applications SHOULD possess administrative functions to detail and manage never logged in accounts, idle accounts, and accounts that have been administratively- or soft- locked

+

* Passwords MUST be easily changed. Applications MAY include password strength indicators or provide a random password generator function

−

==Common web authentication techniques ==

+

* There SHOULD be a logical difference between administrative lockout and failed login lockout, so that re-enabling all users en masse does not unlock administratively locked users

−

'''Basic and Digest authentication'''

+

* Medium value applications SHOULD and High value applications MUST provide a mechanism to re-authenticate or transaction sign high value transactions

+

* Applications MUST protect credentials from common authentication attacks as detailed in the Testing Guide. Following the sections in this chapter will produce such an outcome

−

Nearly all web and application servers support the use of Basic and Digest authentication. This requires the web browser to put up a dialog box to take the user’s name and password, and send them through to the web server, which then processes them against its own user database, or in the case of IIS, against Active Directory.

+

Things not to do:

−

* Basic authentication sends the credential in the clear. It should not be used unless in combination with SSL. All communication must be done over HTTPS during the user’s session because obfuscated credentials are sent with every request.

+

* Applications MUST NOT store any secret part of the credential in the clear (passwords or questions and answers if implemented)

+

* Applications MUST NOT expose the credential in untrusted locations, such as cookies, headers or hidden fields

+

* Applications MUST NOT implement CAPTCHA as there is case law against them with respect to universal access and ineffective

+

* Applications MUST NOT implement questions and answers as they are contrary to most privacy regimes and ineffective

+

* Applications SHOULD NOT rely on infrastructure authentication, such as REFERER headers or the client's DNS or IP address as these can be faked

−

* HTTP 1.0 Digest authentication only obfuscates the password using easily-reversible Base64 encoding. It should not be used.

All authentication systems are designed to be open to anonymous, unauthenticated users. Therefore, they are open to denial of service and brute force attacks.

−

The primary reason against the use of Basic or Digest authentication is due to:

+

Applications implementing their own authentication systems should consider a threshold governor to prevent the over-use of the following paths:

−

* Insecure transmission of credentials

+

* Account registration processes (if any)

+

* Primary authentication path

+

* Step up authentication (such as two factor tokens)

+

* Password change**

+

* Password resets**

−

* Both forms of authentication suffer from replay and [[man-in-the-middle attack|man-in-the middle]] attacks

+

(**Low value systems only - Most medium and all high value systems should not be using passwords, and thus do not possess password reset capabilities)

−

* Both require SSL to provide any form of confidentiality and integrity

+

OWASP's ESAPI project contains a reference implementation of a basic threshold governor, which is in turn linked to the intrusion logging mechanism based upon a certain number of failed events being raised in a particular time period. You may wish to use this mechanism in your own code by adopting ESAPI and overriding the necessary classes as you see fit.

−

* The user interface is reasonably ugly and can be confusing to some users and thus bad for usability

+

===Sequence Diagram===

−

* Does not provide a great deal of control to the end application. These authentication mechanisms are typically handled by the web server before requests reach the application in question. Linking these authentication mechanisms to arbitrary user data stores such as a custom database can be difficult and require writing web server pugins in languages such as C or Perl rather than the application implementation language.

+

TBA

−

This is not to say that Basic or Digest authentication is not useful. It can be used to shield development sites against casual use or to protect low value administrative interfaces, but other than that, this form of authentication is not recommended.

+

===Suggested Timeouts===

−

'''Forms based authentication'''

+

The following timeouts are suggested, but any value will do as long as it severely impacts both vertical and horizontal brute force attacks.

−

Forms based authentication provides the web application designer the most control over the user interface and user data store, and thus it is widely used. It is available and well-supported for both J2EE and ASP.NET platforms.

+

* One failed attempt: At least 5 seconds

+

* Two failed attempts: At least 15 seconds

+

* Three failed attempts: At least 45 seconds

−

Forms based authentication requires the application to do a fair amount of work to implement authentication and authorization. Rarely do web applications get it right. The sections on how to determine if you are vulnerable have upwards of 15 specific controls to check, and this is the minimum required to authenticate with some safety.

+

If there's an obvious brute force attempt (for example, more than 100 attempts per minute), the IP address and/or session should be banned for a period of time, such as 15 minutes. In such cases, error messages should make it clear why this action has been taken.

−

If at all possible, if you choose to use forms based authentication, try to re-use a trusted access control component rather than writing your own.

+

===Distributed Brute Force===

−

Forms based authentication suffers from:

+

If in case of a distributed brute force, the application should monitor the total number of failed authentication attempts per minute, and have a configurable threshold above which the authentication system automatically injects a configurable 45+ second delay between authentication attempts. This will make all but the largest distributed brute force attempt infeasible, even when looking for a single account with a well known password.

−

* Replay attacks

+

==Authenticating Value Transactions with Transaction Signing==

−

* Man in the middle attacks

+

Any system can benefit from the use of transaction signing. Transaction signing requires a user to interact with some out of bound device, such as a two factor token calculator or SMS message to complete a high value transaction. For example, if a bank wishes to establish an online credit card registration process, they could get the user to verify that this transaction is valid by completing a transaction verification. In the case of mobile phones, this could simply include sending a random value to the user's phone or ringing them with a IVR system and digitally read a set of digits to be entered.

−

* Clear text credentials if not used over HTTPS

+

===SMS Based Transaction Signing Sequence Diagram===

−

* Luring attacks

+

For low end through to moderate high value systems, the use of a second factor such as a mobile phone is an excellent low cost alternative to two factor authentication fobs. This mechanism is actually stronger than most two factor authentication fobs as to attack it, the attacker would have to involve individual users to perform the same sort of attacks as they would do today.

−

* Weak password controls

−

And many other attacks as documented in the “How to determine if you are vulnerable”

+

There is a single weakness in this model - mobile phone registration and updating. If attackers can register their phone before the real user or update the user's profile to become their number, the attacker can perform high value transactions with impunity. The application MUST enforce that any one number is only linked to a single account, and to ensure that appropriate safeguards are in place, for example if the same number is being used in multiple accounts at different times as these are signs of phishing.

−

It is vital that you protect login interchanges using SSL, and implement as many controls as possible. A primary issue for web application designers is the cost to implement these controls when the value of the data being protected is not high. A balance needs to be struck to ensure that security concerns do not outweigh a complex authentication scheme.

+

Physically requiring proof of identity to register or update the mobile phone produces the strongest results.

−

'''Integrated authentication'''

+

===Token Based Transaction Signing Sequence Diagram===

−

Integrated authentication is most commonly seen in intranet applications using Microsoft IIS web server and ASP.NET applications. Most other web servers do not offer this choice. Although it can be secure – on a par with client-side certificate authentication due to the use of Kerberos-based Active Directory integration (which means no credentials need to be stored by the application or typed by the user), it is not common on Internet facing applications due to its Window- and Active Directory-centric nature.

+

For the highest value systems, the use of transaction signing calculators as sold by a number of token manufacturers would be the best alternative. These take a portion of the transaction's details and combine it with a private key signing on the calculator. Attackers would have to get the user to log in, type in the values and then subsequently give them the result before fraud would occur. This is extremely unlikely and is not amenable to widespread phishing attacks.

−

If you are developing an intranet application and your development environment supports integrated authentication, you should use it. It means less work for you to develop authentication and authorization controls, one less credential for users to remember, and you can re-use pre-existing authentication and authorization infrastructure.

+

==Authenticating With Multi-Factor Systems==

−

'''Certificate based authentication'''

+

TBA

−

Certificate based authentication is widely implemented in many web and application servers. The web site issues certificates (or attempts to trust externally issued certificates). The public certificates are loaded into the web server’s authentication database, and compared with an offering from incoming browser sessions. If the certificates match up, the user is authenticated.

+

===What is two factor authentication, really?===

−

The quality of authentication is directly related to the quality of the public key infrastructure used to issue certificates. A certificate issued to anyone who asks for them is not as trustworthy as certificates issued after seeing three forms of photo identification (such as passport, driver’s license or national identification card).

+

Two factor authentication is using more than one of:

−

There are some drawbacks to certificate-based logon:

+

* Something you know (account details or passwords)

+

* Something you have (tokens or mobile phones)

+

* Something you are (biometrics)

−

* Many users share PCs and they need to have bring their certificates along with them. This is non-trivial if the user had the application install the certificate for them – most users are completely unaware of how to export and import certificates

+

to logon or process a transaction.

−

* The management of certificates on a browser is non-trivial in many instances

+

If you can create another factor, such as a special token on a particular computer based upon a set of something you know or a single biometric reading, this is effectively single factor authentication. For example, some banks implement a scheme that requires you to type a username, passwords and answer a personal question, and if you get those right, your computer will be marked as a physical factor. It's obvious that this scheme is open to many attacks, but the primary weakness is that the system is not truly a two factor solution as it is based upon a simple set of "something you know" and thus you can make <i>any</i> computer a second factor if you know these details.

−

* Certificate revocation with self-issued certificates is almost impossible in extranet environments

+

Typical two factor solutions involve registering a hardware device such as a token, phone or biometric device on top of the "something you know". In all cases, the two factors should be used together for best results.

−

* Trust of “private” certificate servers requires end-user trust decisions, such as importing root CA certificates. End users are typically not qualified to make this trust decision

+

Lastly, biometric devices are known weak against simple physical attacks, have a known false positive and known false negative authentication rate, thus making them less than desirable as a non-repudiation mechanism. Additionally, biometrics are expensive compared to the cost of phone- and token- based two factor authentication schemes. Until the technology significantly improves, becomes price competitive with cheap phone and tokens, and is relatively universal, biometric devices should not be considered except in highly specialist circumstances.

−

* The cost of certificates and their part in the business model of public certificate companies is not related to the cost of provision, and thus it is expensive to maintain a public certificate database with a large number of users

+

===Sequence Diagram===

−

Coupled with the poor management of many CA’s, particularly regarding certificate renewal, the implementation of certificate-based logon schemes has often failed. A good example is Telstra’s online billing service. At one stage, only digital certificates were acceptable. Now, this requirement is being relaxed.

+

TBA

−

==Strong Authentication ==

+

===Weaknesses===

−

Strong Authentication uses two or more authentication factors to verify an identity. Typically strong authentication is achieved using multiple security controls that belong to atleast two different classes of authentication factors. Most common classification of authentication factors is:

+

−

* Something you know

+

−

* Something you have

+

−

* Something you are

+

−

Strong authentication (such as tokens, certificates, etc) can provide a higher level of security than username and passwords alone. The generalized form of strong authentication is “something you know, something you hold”. Therefore, anything that requires a secret (the “something you know”) and authenticator like a token, USB fob, or certificate (the “something you hold”) is a stronger control than username and passwords (which is just “something you know”) or biometrics (“something you are”).

+

Simple two factor tokens and one time pads, such as German banking TAN lists, are subject to man in the middle attacks. The attacker will put up a realistic looking login page, and instead of logging in directly, the attacker will use the token or TAN to log in first and perform value transactions such as transferring all the money out from a bank account, and then present an error to the user. Once they log in properly, they will discover their account has been attacked.

−

'''When to use strong authentication'''

+

As such, cheap two factor tokens by themselves do not immediately decrease fraud rates. Only transaction signing can do that.

−

Certain applications should use strong authentication:

+

==Single-Sign On (SSO) Authentication==

−

* For high value transactions (note that the definition of a high-value transaction may well be determined in part by the cost of implementing so-called strong authentication)

+

TBA. Discuss LDAP, AD, TAM, SiteMinder.

−

* Where privacy is a strong or legally compelled consideration (such as health records, government records, etc)

+

===Sequence Diagram===

−

* Where audit trails are legally mandated and require a strong association between a person and the audit trail, such as banking applications

+

TBA

−

* Administrative access for high value or high risk systems

+

==Federated Authentication==

−

'''What does high risk mean? '''

+

TBA

−

Every organization has a certain threshold for risk, which can range from complete ignorance of risk all the way through to paranoia.

+

===Sequence Diagram===

−

For example, forum software discussing gardening most likely does not require strong authentication, whereas administrative access to a financial application processing millions of dollars of transactions daily should be mandated to use strong authentication.

+

TBA

−

'''Using Biometric Authentication for Web Applications'''

+

==Authentication For Low Value Systems==

−

Biometric authentication is not as strong as other forms of authentication for remotely accessible web applications becausehe devices are in the control of the attacker – and most low end biometric devices are not tamperproof nor do they have strong replay protection.

+

Low value systems, such as blogs, social networks and so on, should be free to implement weak authentication mechanisms. Given the chance, users should be able to adopt stronger authentication mechanisms if you have them available.

−

You should always use biometrics along with other authentication factors, as otherwise, it significantly weakens the trust in the authentication mechanism. Note that using only biometric (single factor authentication) is not strong authentication.

+

===Registration===

−

*Remote enrollment cannot be trusted – users might substitute others, enroll a glass eye, or a picture out of a magazine.

+

Self-registration can be problematic, particularly for highly sought after resources such as free mail accounts.

−

*The biometric features being measured cannot be revoked – you only have two eyes, ten fingers and one face. This is a deadly combination for high value systems – attackers have previously shown they will cut off fingers to obtain a car. Biometrics are thus too risky for high value systems.

+

===Password Sequence Diagram===

−

*The biometric features being measured do not change; USB keys with inbuilt crypto engines and other fobs have a pseudo-random output that changes every 30 seconds. Distinguishing features such as loops and whirls do not.

+

TBA

−

*There are high false positive rates compared to the cost of the authentication mechanism. With other forms of strong authentication, there are no false accepts.

+

===Logging On Using ESAPI===

−

+

−

*Most consumer biometric devices are easily spoofed or subject to replay attacks. The more expensive devices are not necessarily much better than their affordable counterparts, but for the same price as a high end biometric device, you can own 50 or 60 fobs and upwards of 1000 smart cards.

+

−

+

−

When used in a single factor authentication method (for example, just a thumbprint with no username or password), biometrics are the weakest form of authentication available and are unsuitable for even moderate risk applications. Such usage should be restricted to devices the user owns without sensitive or risky data.

+

−

+

−

'''Relative strengths and uses of strong authentication'''

+

−

+

−

'''One-time passwords'''

+

−

+

−

One time password fobs are cheap – many can be obtained for as little as $5-10, but they only protect against password replay. One time password fobs usually have a number displayed on a screen, and the user will type in their username, pass phrase and the one time password.

+

−

+

−

One time passwords do not help with man-in-the-middle attacks and as they do not present any details of the use to the user, so spoofed web sites could collect a one time password and log on as the user and perform a transaction.

+

−

+

−

'''Soft certificates'''

+

−

+

−

Soft certificates (also known as client-side certificate authentication) are a little stronger than passwords, but suffer from the same problems as passwords and any authentication method which automatically processes credentials. The usability and infrastructure issues with certificate-based authentication have been mentioned previously.

+

−

+

−

'''Connected hard certificates'''

+

−

+

−

USB, PC Card, or otherwise connected tokens which can be programmatically interrogated by the user’s system seem like the best way to store a credential. Although they typically protect against unauthorized duplication of the credential and tampering of the algorithm, as the device is connected to an untrusted host, the hard certificate might be used by an attacker’s site directly, bypassing the otherwise robust authentication mechanism provided.

+

−

+

−

Most tokens pop up a window that asks the user for permission to supply the credential. An attacker could pop up a similar window, obtain the authentication blob, and forward it to the real system whilst performing an entirely different transaction. This attack works due to two reasons:

+

−

+

−

* Chrome on authentication request window – the pop up has no clear relationship between application and authentication. This is a problem with all JavaScript alerts, and not unique to this functionality

+

−

+

−

* User brain bypass – most users familiar with an application will simply agree to a dialog they see all the time. As long as the attacker makes a good facsimile of the authentication approval window, they will agree to it

+

−

+

−

Many other issues surround connected devices, including desktop support issues if the drivers for the hard certificate interfere with the operation of the user’s computer.

Challenge response tokens work by taking a value (challenge) from the system and processing them in a cryptographically secure fashion to derive a result.

+

−

+

−

Challenge response calculators have a keypad, and therefore the password is usually considered to the be the PIN required to access the calculator. The user enters their username and response into the system, which is verified by the authentication server.

+

−

+

−

Although protecting against replay attacks, challenge response tokens suffer from authentication disconnection issue discussed above. The user is approving ''something'', but it is not clear what.

+

−

+

−

'''SMS Challenge Response'''

+

−

+

−

SMS challenge works in countries with a high penetration of text message capable mobile phones. The typical method is to enrol the user in a trusted fashion, registering their mobile phone number. When an authentication or transaction signing is required, the application sends the user a transaction number to their mobile phone, hopefully with some surrounding text to verify what is being signed (such as the reference ID of the transaction).

+

−

+

−

Problems with SMS challenge response include:

+

−

+

−

* It’s a public path; do not send sensitive information with the challenge

+

−

+

−

* If sending the transaction amount, the user may trust this figure, but an attacker may send the user one figure and approve another

+

−

+

−

* You are not the only source of SMS messages; the user can not verify the source of the SMS beyond only expecting them when they are using the system

+

−

+

−

Despite this, SMS challenge response is significantly stronger than username and password with minimal cost overheads. It can be effective as long as the account was set up properly in the first place (and not by an attacker). SMS challenge response can help to prevent the subversion of legitimate accounts.

+

−

+

−

'''Transaction Signing'''

+

−

+

−

Transaction signing is performed by offline challenge response calculators. The user will be presented with various items to enter into the calculator, and it will calculate a response based upon these inputs. This is the strongest form of authentication as the user has to enter the transaction details – any other transaction will fail to produce a suitable response. This type of authentication has strong non-repudiation properties, is robust against man in the middle attacks, cannot be replayed, and is robust against differing transaction limits.

+

−

+

−

For the best effect, at least the following should be stirred into the challenge:

+

−

+

−

* Reference ID

+

−

+

−

* From account

+

−

+

−

* Amount of the transaction

+

−

+

−

The tokens are usually date and time based, so there’s only a little to be gained by entering the transaction date. The downsides of these tokens are

+

−

+

−

* It can take up to 20 to 40 keystrokes to complete a transaction, which is problematic if the user has to approve each and every transaction

+

−

+

−

* If a token is connected to the user’s computer or uses some form of automated entry, although the human factors are better (no details to enter), the non-repudiation property is removed as the user no longer is required to think about the value of the transaction – they just approve the signing window, which is no better than a soft-certificate.

+

−

+

−

Therefore, although most of the calculators for transaction signing allow connection to the client computer, this functionality should not be used or made available.

+

−

+

−

Although transaction signing calculators and EMV (smart card) style calculators are identical in functionality from the application’s point of view, they have different values to the user. A calculator will be left on a desk for all to see, whereas an EMV smart card masquerading as the user’s corporate credit card has the appropriate value to the user – they will not leave them on the desk or in their unlocked drawer. The value of the system should decide which type of transaction signing token is provided to the user.

+

−

+

−

'''Challenges to using strong authentication'''

+

−

+

−

Most common application frameworks are difficult to integrate with strong authentication mechanisms, with the possible exception of certificate-based logon, which is supported by J2EE and .NET.

+

−

+

−

Your code must be integrated with an authentication server, and implicitly trust the results it issues. You should carefully consider how you integrate your application with your chosen mechanism to ensure it is robust against injection, replay and tampering attacks.

+

−

+

−

Many organizations are wary of strong authentication options as they are perceived to be “expensive”. They are, but so are passwords. The costs of user management are not usually related to the cost of the authentication infrastructure, but relate instead to the issuance and maintenance of the user records. If there is a requirement to have strong non-repudiation the most formidable and costly aspect of user management is enrolment, maintenance and de-enrolment. Simply sending any user who asks for an account a token or certificate provides no certainty that the user is who they say they are. A robust trusted enrolment path is required to ensure that the authentication system is “strong”.

+

−

+

−

==Federated Authentication ==

+

−

+

−

Federated authentication allows you to outsource your user database to a third party, or to run many sites with a single sign on approach. The primary business reason for federated security is that users only have to sign on once, and all sites that support that authentication realm can trust the sign-on token and thus trust the user and provide personalized services.

+

−

+

−

Advantages of federated authentication:

+

−

+

−

* Reduces the total number of credentials your users have to remember

+

−

+

−

* Can be appropriate when your site(s) are part of a large trading partnership, such as an extranet procurement network

Kim Cameron, Identity Architect of Microsoft has established a group blog focusing on the risks surrounding federated identity schemes. The blog established a set of papers, with seven laws of identity. These are:

+

−

+

−

# '''User Control and Consent''': Digital identity systems must only reveal information identifying a user with the user's consent.

+

−

# '''Limited Disclosure for Limited Use''': The solution which discloses the least identifying information and best limits its use is the most stable, long-term solution.

+

−

# '''The Law of Fewest Parties''': Digital identity systems must limit disclosure of identifying information to parties having a necessary and justifiable place in a given identity relationship.

+

−

# '''Directed Identity''': A universal identity metasystem must support both "omnidirectional" identifiers for use by public entities and "unidirectional" identifiers for private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.

+

−

# '''Pluralism of Operators and Technologies''': A universal identity metasystem must channel and enable the interworking of multiple identity technologies run by multiple identity providers.

+

−

# '''Human Integration''': A unifying identity metasystem must define the human user as a component integrated through protected and unambiguous human-machine communications.

+

−

# '''Consistent Experience Across Contexts''': A unifying identity metasystem must provide a simple consistent experience while enabling separation of contexts through multiple operators and technologies.

It is unclear at the time of writing if these “laws” will end up changing the identity landscape, but many of the issues discussed in the laws should be considered by implementers of federated authentication.

+

−

+

−

'''SAML'''

+

−

+

−

SAML is a part of the Liberty Alliance’s mechanism to provide federated authentication, although it is not just for federated authentication.

+

−

+

−

At the time of writing, there is no direct support for SAML in any major off-the-shelf application framework (J2EE, PHP, or .NET). Third party libraries, including open source implementations, are available for J2EE. Microsoft has (very) limited support for SAML in the Web Services Enhancement 2.0 SP2, which requires .NET Framework 1.1.

+

−

+

−

For more details on how the SAML protocol works, see the Web Services chapter.

+

−

+

−

'''Microsoft Passport'''

+

−

+

−

Microsoft Passport is an example of federated authentication, used for Hotmail, delivery of software, instant messaging, and for a time, by partners such as eBay. Microsoft’s .NET framework supports Passport sign-on. There is limited support on other platforms. However, Microsoft has withdrawn partner Passport usage, so essentially Passport is no longer a viable option and is not discussed further.

+

−

+

−

'''Considerations'''

+

−

+

−

Adoption of federated authentication has been limited thusfar, and unless your business requirements state that you need to support single-sign on with many different bodies, you should avoid the use of federated sign-on.

+

−

+

−

==Client side authentication controls ==

+

−

+

−

Client-side validation is most often used in combination with forms-based authentication. Client-side validation scripts (usually written in JavaScript) are a good control to provide immediate feedback for users if they violate business rules. This can lighten the load of the web server by eliminating requests from round trips that are bound to fail. However, client-side validation is trivially bypassed. It is of benefit largely to web site usability and should not be considered a legitimate security precaution.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

To test, reduce the login page to just a basic form as a local static HTML file, with a POST action against the target web server. You are now free to violate client-side input validation. This form is also much easier to use with automated attack tools.

+

−

+

−

Also, web request proxy tools can be used to submit a legitimate login request via a browser and then change the values in transit before the reach the web application server. If you are able to use web proxies to submit invalid logon data to server-side logon routines then the application might be vulnerable if it does not properly handle the malformed inputs.

+

−

+

−

'''How to protect yourself'''

+

−

+

−

To protect your application, ensure that every validation and account policy / business rule is checked on the server-side.

+

−

+

−

For example, if you do not allow blank passwords (and you shouldn’t), this should be tested at the least on the server-side, and optionally on the client-side. This goes for “change password” features, as well.

+

−

+

−

For more information, please read the Validation section in this book.

+

−

+

−

==Positive Authentication ==

+

−

+

−

Unfortunately, a generic good design pattern for authentication does not fit all cases. However, some designs are better than others. Authentication should be a fail-closed process; a user is assumed to be anonymous until they have positively identified themselves to the system.

+

−

+

−

If an application uses the following pseudo-code to authenticate users, any form of fall through will end up with the user being authenticated due to the false assumption that users mostly get authentication right:

+

<pre>

<pre>

−

''bAuthenticated := true''

−

−

''try {''

−

−

''userrecord := fetch_record(username)''

−

−

''if userrecord[username].password != sPassword then''

−

−

''bAuthenticated := false''

−

−

''end if''

−

−

''if userrecord[username].locked == true then''

−

−

'' bAuthenticated := false''

−

−

''end if''

−

−

'' …''

−

−

''}''

−

−

''catch {''

−

−

'' // perform exception handling, but continue''

−

−

''}''

−

</pre>

−

−

'''How to determine if you are vulnerable'''

−

−

To test, try forcing the authentication mechanism to fail.

−

−

If a positive authentication algorithm is in place, it is likely that any failure or part failure will end up allowing access to other parts of the application. In particular, test any cookies, headers, or form or hidden form fields extensively. Play around with sign, type, length, and syntax. Inject NULL, Unicode and CRLF, and test for XSS and SQL injections. See if race conditions can be exploited by single stepping two browsers using a JavaScript debugger.

−

−

'''How to protect yourself'''

−

−

The mitigation to positive authentication is simple: force negative authentication at every step:

−

−

<pre>

−

''bAuthenticated := false''

−

−

''securityRole := null''

−

−

''try {''

−

−

''userrecord := fetch_record(username)''

−

−

''if userrecord[username].password != sPassword then''

−

−

'' throw noAuthentication''

−

−

''end if''

−

−

''if userrecord[username].locked == true then''

−

−

'' throw noAuthentication''

−

−

''end if''

−

−

''if userrecord[username].securityRole == null or banned then''

−

−

'' throw noAuthentication''

−

−

''end if''

−

</pre>

−

−

−

'' … other checks …''

−

−

<pre>

−

''bAuthenticated := true''

−

−

''securityRole := userrecord[username].securityRole''

−

−

''}''

−

−

''catch {''

−

−

''bAuthenticated := false''

−

−

''securityRole := null''

−

−

−

−

''// perform error handling, and stop''

−

−

''}''

−

−

''return bAuthenticated''

−

</pre>

−

−

−

By asserting that authentication is true and applying the security role right at the end of the try block stops authentication fully and forcefully.

−

−

==Multiple Key Lookups ==

−

−

Code that uses multiple keys to look up user records can lead to problems with SQL or LDAP injection. For example, if both the username and password are used as the keys to finding user records, and SQL or LDAP injection is not checked, the risk is that either field can be abused.

−

−

For example, if you want to pick the first user with the password “password”, bypass the username field. Alternatively, as most SQL lookup queries are written as “select * from table where username = username and password = password, this knowledge may be used by an attacker to simply log on with no password (ie truncating the query to “select * from username=’username’; -- and password = ‘don’t care’’”). If username is unique, it is the key.

−

−

'''How to determine if you are vulnerable'''

−

−

Your application is at risk if all of the following are true:

−

−

* More than just the username is used in the lookup query

−

−

* The fields used in the lookup query (eg, username and password) are unescaped and can be used for SQL or LDAP injection

−

−

To test this, try:

−

−

* Performing a SQL injection (or LDAP injection) against the login page, masking out one field by making it assert to true:

−

−

<pre>

−

Login: a’ or ‘1’=’1

−

−

Password: password

−

−

Login: a)(|(objectclass=*)

−

−

Password: password

−

</pre>

−

−

If the above works, you’ll authenticate with the first account with the password “password”, or generate an error that may lead to further breaks. You’d be surprised how often it works.

In general, the threshold governor (see above) should be implemented to prevent any one IP address monopolizing authentication CPU, network, and IO resources. If necessary, such as for compliance with a national security standard, a configurable soft lockout of approximately 15-30 minutes should apply, with an error message stating the reason and when the account will become active again.

−

SqlCommand cmd = new SqlCommand(selectString, conn);

+

Ensure any lockout mechanism protects against both same username, many passwords and many usernames and same password attacks. This can only be done using the threshold governor approach as shown above.

Applications MUST be designed to allow selection of multiple algorithms, as the USA's NIST is currently running an hashing algorithm competition, which will choose a successor to SHA-256, SHA-384, and SHA-512. Your application MUST be able to transition to the new hashing algorithm by no later than one year after the new algorithm's release. This doesn't mean that MD5 will be dead at that point, but your application should cope with the idea that insecure algorithms such as MD5 or SHA-1 can be retired at some point.

+

==Authentication Anti-Patterns==

−

SqlDataReader myReader = cmd.ExecuteReader();

+

Do not implement any of these features - they are either dangerous, illegal, ineffective, or all of the above.

−

If ( myReader.

+

===Default Accounts===

−

// do the work of making the user record active in some way.

+

Do not ship your software with any default accounts such as "YourProductName", "sa", "root", "administrator", or any hard coded service accounts. Do not include any screen shots or text in the documentation indicating a preferred username or password for a particular application ID or service.

−

myReader.Close();

+

===Remember Me===

−

}

+

Implementing remember me functionality can be incredibly hard. Often software will just embed the username and password in headers or cookies, or a hash or crypto blob of the same. Based upon your risk profile, your application:

−

catch (…) {

+

* High value applications MUST NOT possess remember me functionality.

+

* Medium value applications SHOULD NOT contain remember me functionality. If present, the user MUST opt-in to remember me. The system SHOULD strongly warn users that remember me is insecure particularly on public computers

+

* Low value applications MAY include an opt-in remember me function. There should be a warning to the user that this option is insecure, particularly on public computers.

−

…

+

ESAPI's reference implementation has basic "remember me" functionality based upon an AES encryption of the username and password, but this is not recommended for medium value systems, and should be used with care on low value systems.

−

}

+

===Hard Coded Credentials===

−

</pre>

+

−

==Referer Checks ==

+

Do not include any credentials in your source code, including (but not limited to) usernames, passwords, certificates, token IDs, or phone numbers.

−

Referer is an optional HTTP header field that normally contains the previous location (ie the referrer) from which the browser came from. As the attacker can trivially change it, the referrer must not be used to make security decisions, as attackers are more likely to use the correct referrer to bypass controls in your application than to use invalid or damaging content.

+

Such constants belong in properly protected properties or configuration files. ESAPI has an encrypted properties mechanism you can use to protect clear text credentials in such files.

−

In general, applications are better off if they do not contain any referrer code.

+

===CAPTCHA===

−

'''How to determine if you are vulnerable'''

+

CAPTCHA (Completely automated Turing Tests To Tell Humans and Computers Apart) are illegal in any jurisdiction that prohibits discrimination against disabled citizens. This is essentially the entire world. Although CAPTCHAs seem useful, they are in fact, trivial to break using any of the following methods:

−

The vulnerability comes in several parts:

+

* Optical Character Recognition. Most common CAPTCHAs are solvable using specialist CAPTCHA breaking OCR software.

+

* Break a test, get free access to <i>foo</i>, where <i>foo</i> is a desirable resource

+

* Pay someone to solve the CAPTCHAs. The current rate at the time of writing is $12 per 500 tests.

−

* Does your code check the referrer? If so, is it completely necessary?

+

Therefore implementing CAPTCHAs in your software is most likely to be illegal in at least a few countries, and worse - completely ineffective.

−

* Is the referrer code simple and robust against all forms of user attack?

+

===Secret Questions And Answers===

−

* If you use it to construct URLs? Don’t as it’s nearly impossible test all valid URLs

+

Questions and answers are back door credentials - they equate to the username and password for the user. Often such schemes use "Mother's Maiden Name" or other easily found information. If all systems use the same Q&As, it will be possible to break into many accounts using the same information.

−

For example, if login.jsp can only be invoked from http://www.example.com/index.jsp, the referrer should check that the referrer is this value.

+

They are unacceptable for the following reasons:

−

'''How to protect yourself'''

+

* Collection of information about people without their explicit consent (such as "Mother's maiden name") is illegal in most privacy regimes. Such collection is subject to privacy laws, review and correction by the subject, and so on.

−

+

* IT Security Policies and standards such as ISO 27000 prohibit the clear text storage of passwords, but almost all Q&A schemes store both the question and answer in the clear

−

For the most part, using the referer field is neither desirable nor useful as it so easily modified or spoofed by attackers. Little to no trust can be assigned to its value, and it can be hard to sanitize and use properly.

+

* The information in the answers is public for a goodly portion of the users of the Internet, and thus is found using public sources

−

+

−

Programs that display the contents of referrer fields such as web log analyzers must carefully protect against XSS and other HTML injection attacks.

+

−

+

−

If your application has to use the referrer, it should only do so as a defense in depth mechanism, and not try to sanitize the field, only reject it if it’s not correct. All code has bugs, so minimize the amount of code dealing with the referrer field.

+

−

+

−

For example, if login.jsp can only be invoked from http://www.example.com/index.jsp, the referrer could check that the referrer is this value.

* Oracle – a large number of known accounts with passwords (fixed with later versions of Oracle)

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

* Determine if the underlying infrastructure has no default accounts left active (such as Administrator, root, sa, ora, dbsnmp, etc)

+

−

+

−

* Determine if the code contains any default, special, debug or backdoor credentials

+

−

+

−

* Determine if the installer creates any default, special, debug credentials common to all installations

+

−

+

−

* Ensure that all accounts, particularly administrative accounts, are fully specified by the installer / user.

+

−

+

−

There should be no examples or images in the documentation with usernames in them

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* New applications should have no default accounts.

+

−

+

−

* Ensure the documentation says to determine that the underlying infrastructure has no default accounts left active (such as Administrator, root, sa, ora, dbsnmp, etc)

+

−

+

−

* Do not allow the code to contain any default, special, or backdoor credentials

+

−

+

−

* When creating the installer, ensure the installer does not create any default, special, credentials

+

−

+

−

* Ensure that all accounts, particularly administrative accounts, are fully specified by the installer / user.

+

−

+

−

* There should be no examples or images in the documentation with usernames in them

+

−

+

−

==Choice of usernames ==

+

−

+

−

If you choose a username scheme that is predictable, it’s likely that attackers can perform a denial of service against you. For example, banks are particularly at risk if they use monotonically increasing customer numbers or credit card numbers to access their accounts.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

* Bad username forms include:

+

−

+

−

* Firstname.Lastname

+

−

+

−

* E-mail address (unless the users are random enough that this is not a problem … or you’re a webmail provider)

+

−

+

−

* Any monotonically increasing number

+

−

+

−

* Semi-public data, such as social security number (US only – also known as SSN), employee number, or similar.

+

−

+

−

* Bank account numbers (they can easily be observed on paper checks)

+

−

+

−

In fact, using the SSN as the username is illegal as you can’t collect this without a suitable purpose.

+

−

+

−

'''How to protect yourself'''

+

−

+

−

Where possible, allow users to create their own usernames. Usernames only have to be unique.

+

−

+

−

Usernames should be HTML, SQL and LDAP safe – suggest only allowing A..Z, a..z, and 0-9. If you wish to allow spaces, @ symbols or apostrophes, ensure you properly escape the special characters (see the Data Validation chapter for more details)

+

−

+

−

Avoid the use of Firstname.Lastname, e-mail address, credit card numbers or customer number, or any semi-public data, such as social security number (US only – also known as SSN), employee number, or similar.

+

−

+

−

==Change passwords ==

+

−

+

−

Where the user has to remember a portion of the credential, it is sometimes necessary to change it, for example if the password is accidentally disclosed to a third party or the user feels it is time to change the password.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

To test:

+

−

+

−

* Change the password then change the password again – if there are minimum periods before new passwords can be chosen (often 1 day), it should fail.

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* Ensure your application has a change password function.

+

−

+

−

* The form must include the old password, the new password and a confirmation of the new password

+

−

+

−

* Use AUTOCOMPLETE=off to prevent browsers from caching the password locally

+

−

+

−

* If the user gets the old password wrong too many times, lock the account and kill the session

+

−

+

−

For higher risk applications or those with compliance issues, you should include the ability to prevent passwords being changed too frequently, which requires a password history. The password history should consist only of previous hashes, not clear text versions of the password. Allow up to 24 old password hashes.

+

−

[[Category:FIXME|I notice that usually there is more of a suggestion than a rule. Here it says to allow 24 old password hashes.]]

+

−

+

−

==Short passwords ==

+

−

+

−

Passwords can be brute forced, rainbow cracked (pre-computed dictionary attack), or fall to simple dictionary attacks. Unfortunately, they are also the primary method of logging users onto applications of all risk profiles. The shorter the password, the higher the success rate of password cracking tools.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

* Determine if the application allows users no password at all. This should never be allowed.

+

−

+

−

* Determine if the application allows users to use dangerously short passwords (less than four characters). Applications with a stronger authentication requirement will not allow this. Average applications should warn the user that it’s weak, but allow the change anyway. Poor applications will just change the password

+

−

+

−

* Change the password to be increasingly longer and longer until the application warns the user of excessive password size. A good application will allow arbitrary password lengths, and thus will not warn at all

+

−

+

−

On each iteration, see if a shorter version of the password works (often only 8 or 16 characters is needed)

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* Ensure your application does not allow blank passwords

+

−

+

−

* Enforce a minimum password length. For higher risk applications, prevent the user from using (a configurable) too short password length. For low risk apps, a warning to the user is acceptable for passwords less than six characters in length.

+

−

+

−

* Encourage users to use long pass phrases (like “My milk shake brings all the boys to the yard” or “Let me not to the marriage of true minds Admit impediments”) by not strictly enforcing complexity controls for passwords over 14 characters in length

+

−

+

−

* Ensure your application allows arbitrarily long pass phrases by using a decent one-way hash algorithm, such as AES-128 in digest mode or SHA-256 bit.

+

−

+

−

==Weak password controls ==

+

−

+

−

ISO 17799 and many security policies require that users use and select reasonable passwords, and change them to a certain frequency. Most web applications are simply non-compliant with these security policies. If your application is likely to be used within enterprise settings or requires compliance with ISO 17799 or similar standards, it must implement Basic authentication controls. This does not mean that they need to be turned on by default, but they should exist.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

Determine if the application

+

−

+

−

* Allows blank passwords

+

−

+

−

* Allows dictionary words as passwords. This dictionary should be the local dictionary, and not just English

+

−

+

−

* Allows previous passwords to be chosen. Applications with stronger authentication or compliance needs should retain a hashed password history to prevent password re-use

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* Allow for languages other than English (possibly allowing more than one language at a time for bi-lingual or multi-lingual locales like Belgium or Switzerland)

+

−

+

−

* The application should have the following controls (but optionally enforce):

For higher risk applications, use a weak password dictionary helper to decide if the user’s choice for password is too weak.

+

−

+

−

'''Note: Complex frequently changed passwords are counterproductive to security. It is better to have a long-lived strong passphrase than a 10 character jumble changed every 30 days. The 30 days will ensure that PostIt™ notes exist all over the organization with passwords written down.'''

+

−

+

−

==Reversible password encryption ==

+

−

+

−

Passwords are secrets. There is no reason to decrypt them under any circumstances. Help desk staff should be able to set new passwords (with an audit trail, obviously), not read back old passwords. Therefore, there is no reason to store passwords in a reversible form.

+

−

+

−

The usual mechanism is to use a cryptographic digest algorithm, such as MD5 or SHA-1. However, some forms have recently shown to be weak, so it is incumbent to move to stronger algorithms unless you have a large collection of old hashes.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

For custom code using forms-based authentication, examine the algorithm used by the authentication mechanism. The algorithm should be using AES-128 in digest mode, SHA-1 in 256 bit mode, with a salt.

+

−

+

−

* Older algorithms such as MD5 and SHA-1 (with 160 bit hash output) have been shown to be potentially weak, and should no longer be used.

+

−

+

−

* No algorithm (ie you see a clear text password) is insecure and should not be used

+

−

+

−

* Algorithms, such as DES, 3DES, Blowfish, or AES in cipher mode, which allow the passwords to be decrypted should be frowned upon.

+

−

+

−

'''How to protect yourself'''

+

−

+

−

If you don’t understand the cryptography behind password encryption, you are probably going to get it wrong. Please try to re-use trusted password implementations.

+

−

+

−

* Use AES-128 in digest mode or SHA-1 in 256 bit mode

+

−

+

−

* Use a non-static salting mechanism

+

−

+

−

* Never send the password hash or password back to the user in any form

+

−

+

−

==Automated password resets ==

+

−

+

−

Automated password reset mechanisms are common where organizations believe that they need to avoid high help desk support costs from authentication. From a risk management perspective, password reset functionality seems acceptable in many circumstances. However, password reset functionality equates to a secondary, but much weaker password mechanism. From a forthcoming study (see references), it appears that password reset systems with five responses are the equivalent to two character passwords and require reversible or clear text passwords to be stored in the back end system, which is contrary to security best practices and most information security policies.

+

−

+

−

In general, questions required by password reset systems can be answered by information easily found from public records (mother’s maiden name, car color, etc). In many instances, the password reset asks for data that is illegal or highly problematic to collect, such as social security numbers. In most privacy regimes, you may only collect information directly useful to your application’s needs, and disclose to the user why you are collecting that information.

+

−

+

−

In general, unless the data being protected by your authentication mechanism is practically worthless, you should not use password reset mechanisms.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

Password reset mechanisms vary in complexity, but are often easily abused.

+

−

+

−

* If password reset uses hints, check the hints for publicly known or semi-public information such as date of birth, SSN, mother’s name, etc. It should not use these as they can be found out from other sources and from social engineering.

+

−

+

−

* There should no further clues in the underlying HTML.

+

−

+

−

* If password reset uses the e-mail address as the key to unlocking the account, the resulting e-mail should not contain a password itself, but a one-time validation token valid only for a short period of time (say 15 minutes). If the token is good for a long period of time, check to see if the token is predictable or easy to generate.

+

−

+

−

* If the e-mail contains a clickable link, determine if the link can be used for phishing.

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* High value transaction systems should not use password reset systems. It is discouraged for all other applications.

+

−

+

−

* Consider cheaper and more secure systems, such as pre-sending the user a password reset token in a sealed envelope which is replenished upon use.

+

−

+

−

* If the questions and answers are used to identify the user to the help desk, simply generate a random number in the “How to call the help desk” page on your web site and verify this number when the user calls in.

+

−

+

−

* Be careful when implementing automated password resets. The easiest to get right is “e-mail the user” as it creates an audit trail and contains only one secret – the user’s e-mail address. However, this is risky if the user’s e-mail account has been compromised.

+

−

+

−

* Send a message to the user explaining that someone has triggered the password reset functionality. Ask them if they didn’t ask for the reset to report the incident. If they did trigger it, provide a short cryptographically unique time limited token ready for cut and paste. Do not provide a hyperlink as this is against phishing best practices and will make scamming users easier over time. This value should then be entered into the application which is waiting for the token. Check that the token has not expired and it is valid for that user account. Ask the user to change their password right there. If they are successful, send a follow up e-mail to the user and to the admin. Log everything.

+

−

+

−

If you have to choose the hint based alternative, use free-form hints, with non-public knowledge suggestions, like “What is your favorite color?” “What is your favorite memory,” etc. Do not use mother’s maiden name, SSN, or similar. The user should enter five hints during registration, and be presented with three when they reset the password. Also consider allowing users to create their own questions and answers as long as they are advised against using questions that can be answered by discoverable, semi-public data. With appropriate user education this can produce password reset “credentials” that are significantly less discoverable

+

−

+

−

Obviously, both password reset mechanisms should be over SSL to provide integrity and privacy.

+

−

+

−

==Brute Force ==

+

−

+

−

A common attack is to attempt to log on to a well-known privileged account name or otherwise guessed account and attempt brute-force or dictionary attacks against the password. Users are notorious at choosing really bad passwords (like “password”), and so this approach works surprisingly well.

+

−

+

−

Applications should be robust in the face of determined automated brute force and dictionary attack, such as from Brutus or custom scripts. Determined brute force attacks cannot easily be defeated, only delayed.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

To test the application:

+

−

+

−

* Use a brute force application, such as Brutus or a custom Perl script. This attack only works with tools.

+

−

+

−

* Use multiple dictionaries, not just English

+

−

+

−

* Use “common password” dictionaries. You’d be surprised how often “root”, “password”, “”, and so on are used

+

−

+

−

* Does the error message tell you about what went wrong with the authentication? If it does then the application is disclosing information that is potentially useful to an attacker searching for accounts to brute force.

+

−

+

−

* Are the logs for failed authentication attempts tied to a brute force mechanism? Does it lock your IP or session out?

+

−

+

−

* Can you restart the brute force by dropping the session with n-1 attempts left? ie, if you get your session destroyed at 5 attempts, does using 4 then starting a new session work?

+

−

+

−

If the application allows more than five attempts from a single IP address, or a collection rate in excess of 10 requests a second, it’s likely that the application will fall to determined brute force attack.

+

−

+

−

'''How to protect yourself'''

+

−

+

−

An application should:

+

−

+

−

* Have a delay between the user submitting the credential and a success or failure is reported. A delay of three seconds can make automated brute force attacks almost infeasible. A progressive delay (3 seconds then 15 then 30 then disconnect) can make casual brute force attacks completely ineffective

+

−

+

−

* Warn the user with a suitable error message that does not disclose which part of the application credentials are incorrect by using a common authentication error page.

+

−

[[Category:FIXME|there was a colon at the end of this sentence, was there supposed to be something here, like a graphic?]]

* (For applications requiring stronger controls) Block access from abusive IP addresses (ie accessing more than three accounts from the same IP address, or attempting to lock out more than one account). This must be done with care because NAT firewalls and other technologies can shape network traffic in ways not anticipated by web application designers.

+

−

+

−

* For online forms, generate a one-time key each time the login page is requested, store a copy in the session, and wait a couple of seconds before sending the form to the user's browser with the key as a hidden field. If the keys don't match when the form is posted, log the failed attempt and destroy the session without even looking at the other details.

+

−

+

−

* Destroy the session after too many retries.

+

−

+

−

In such a scenario, log analysis might reveal multiple accesses to the same page from the same IP address within a short period of time. Event correlation software such as Simple Event Correlator (SEC) can be used to define rules to parse through the logs and generate alerts based on aggregated events. This could also be done by adding a Snort rule for alerting on HTTP Authorization Failed error messages going out from your web server to the user, and SEC can then be used to aggregate and correlate these alerts.

+

−

+

−

==Remember Me ==

+

−

+

−

On public computers, “Remember Me?” functionality, where a user can simply return to their personalized account can be dangerous. For example, in Internet Cafes, you can often find sites previous users have logged on to, and post as them, or order goods as them (for example with eBay).

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

* Does the application possess “remember me” functionality?

+

−

+

−

* If so, how long does it last? If permanently, how long does the cookie last before expiry?

+

−

+

−

* Does it use a predictable cookie value? If so, can this be used to bypass authentication altogether?

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* If your application deals with high value transactions, it should not have “Remember Me” functionality.

+

−

+

−

* If the risk is minimal, it is enough to warn users of the dangers before allowing them to tick the box.

+

−

+

−

* Never use a predictable “pre-authenticated” token. The token should be kept on record to ensure that the authentication mechanism is not bypassable

+

−

+

−

* Force all users to positively authenticate themselves before being allowed to engage in even moderate-value activities. Using “Remember Me” functionality to authenticate the user to maintain UI preferences may be all right, but using it to allow users to modify account information is most likely not acceptable.

+

−

+

−

==Idle Timeouts ==

+

−

+

−

Applications that expose private data or that may cause identity theft if left open should not be accessible after a certain period of time.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

* Log on to the application

+

−

+

−

* Does the application have a keep alive or “log me on automatically” function? If so, the likelihood is high that the application will fail this test.

+

−

+

−

* Wait 20 minutes

+

−

+

−

* Try to use the application again.

+

−

+

−

* If the application allows the use, the application is at risk.

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* Determine a suitable time out period with the business

+

−

+

−

* Configure the time out in the session handler to abandon or close the session after the time out has expired.

+

−

+

−

==Logout ==

+

−

+

−

All applications should have a method of logging out of the application. This is particularly vital for applications that contain private data or could be used for identity theft.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

* Does the application contain a logout button or link somewhere within it?

+

−

+

−

* Does every view contain a logout button or link?

+

−

+

−

* When you use logout, can you re-use the session (ie copy and paste a URL from two or three clicks ago, and try to re-use it)?

+

−

+

−

* (High risk applications) When logout is used, does the application warn you to clear the browser’s cache and history?

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* Implement logout functionality

+

−

+

−

* Include a log out link or button in every view and not just in the index page

+

−

+

−

* Ensure that logout abandons or closes out the session, and clears any cookies left on the browser

+

−

+

−

* (High risk applications) Include text to warn the user to clear their browser’s cache and history if they are on a shared PC

+

−

+

−

==Account Expiry ==

+

−

+

−

Users who have to sign up for your service may wish to discontinue their association with you, or for the most part, many users simply never return to complete another transaction.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

* Does the application have a mechanism to terminate the account?

+

−

+

−

* Does this remove all the user’s records (except records required to provide adequate transaction history for taxation and accounting purposes?)

+

−

+

−

* If the records are partially scrubbed, do they eliminate all non-essential records?

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* Users should have the ability to remove their account. This process should require confirmation, but otherwise should not overly make it difficult to the user to remove their records.

+

−

+

−

* Accounts that have not logged in for a long period of time should be locked out, or preferably removed.

+

−

+

−

* If you retain records, you are required by most privacy regimes to detail what you keep and why to the user in your privacy statement.

+

−

+

−

When partially scrubbing accounts (ie you need to maintain a transaction history or accounting history), ensure all personally identifiable information is not available or reachable from the front end web application, i.e. export to an external database of archived users or CSV format

+

−

+

−

==Self registration ==

+

−

+

−

Allowing self-registration can help reduce maintenance and support costs, but the anonymous nature of self-registration can have significant security ramifications. Any application implementing self-registration should include steps to protect against the abuse of this facility.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

* Does the self-registration feature allow full access to all features without human intervention?

+

−

+

−

* If there are limits, are they enforced if you know about them? Many applications simply don’t let you see a particular URL, but does that URL work when cut-n-paste from a more privileged account?

+

−

+

−

* Can the process for maximizing the account’s capabilities be forced or socially engineered?

+

−

+

−

'''How to protect yourself'''

+

−

+

−

* Implement self-registration carefully based upon the risk to your business. For example, you may wish to put monetary or transaction limits on new accounts.

+

−

+

−

* If limits are imposed, they should be validated by business rules, and not just by security through obscurity.

+

−

+

−

* Ensure the process to maximize the features of an account is simple and transparent.

+

−

+

−

* When accounts are modified, ensure that a reasonable trace or audit of activity is maintained

The usual reason for implementing a CAPTCHA is to prevent spammers from registering and polluting the application with spam and pornographic links. This is a particularly bad problem with blog and forum software, but any application is at risk if search engines can index content.

+

−

+

−

'''How to determine if you are vulnerable'''

+

−

+

−

The primary method of breaking CAPTCHAs is to grab the image and to use humans to crack them. This occurs with “free day passes” to adult web sites. A person who wants to look at free images is presented with the captured CAPTCHA and more often than not, they will type the letters in for a small reward. This completely defeats the CAPTCHA mechanism.

+

−

+

−

Visual or audible CAPTCHA mechanisms by their nature are not accessible to blind (or deaf) users, and as a consequence of trying to defeat clever optical character recognition software, often locks out color blind users (which can be as high as 10 % of the male population).

+

−

+

−

'''Note: Any web site that is mandated or legally required to be accessible must not use CAPTCHAs. '''

+

−

+

−

'''How to protect yourself'''

+

−

+

−

Do not use CAPTCHA tags. They are illegal if you are required to be accessible to all users (often the case for government sites, health, banking, and nationally protected infrastructure, particularly if there is no other method of interacting with that organization).

+

−

+

−

If you have to use CAPTCHA:

+

−

+

−

* Always provide a method by which a user may sign up or register for your web site offline or via another method

+

−

+

−

* Deter the use of automated sign ups by using the “no follow” tag. Search engines will ignore hyperlinks and pages with this tag set, immensely devaluing the use of link spamming

+

−

+

−

* Limit the privileges of newly signed up accounts or similar until a positive validation has occurred. This can be as simple as including a unique reference ID to a registered credit card, or requiring a certain amount of time before certain features are unlocked, such as public posting rights or unfettered access to all features

+

−

+

−

==Further Reading ==

+

−

+

−

* NIST Special Publication 800-63 Version 1.0.2, "Electronic Authentication Guideline" Recommendations of the National Institute of Standards and Technology.

* van der Stock, A., “''On the entropy of password reset systems''”, unpublished research paper. If you’d like participate in the survey portion of this research, please contact vanderaj@owasp.org

+

−

+

−

==Authentication ==

+

−

[[Category:FIXME|is this a separate article?]]

+

−

Web and application server authentication can be thought of as two different controls. Web server authentication is controlled by the web server administration console or configuration files. These controls do not need to interact with the application code to function. For example using Apache you modify the http.conf or .htaccess files; or for IIS modify the IIS MMC. Basic authentication works by sending a challenge request back to a user’s browser consisting of the protected URI. The user must then respond with the user-ID and password, separated by a single colon, encoded using base64. See '''''Authentication''''' chapter in this guide for more information. Application level authentication occurs at a layer after the web server access controls have been processed. This section examines how to use ColdFusion to authentication and authorize users to resources at the application level.

+

−

+

−

+

−

+

−

[[Image:Web and Application Server Access Controls.gif]]

+

−

+

−

+

−

+

−

ColdFusion allows you to authenticate against multiple system types. These types include LDAP, text files, Databases, NTLM, Client-Side certificates via LDAP, or others via custom modules. The section below describes using these credential stores according to best practice.

+

−

+

−

+

−

+

−

'''Best Practices'''

+

−

+

−

*When a user enters an invalid credential into a login page, do NOT return which item was incorrect instead show a generic message. For example, “Your login information was invalid!”

+

−

+

−

*Never submit login information via GET request always use POST.

+

−

+

−

*Use SSL to protect login page delivery and credential transmission.

+

−

+

−

*Remove dead code and client-side viewable comments from all pages.

+

−

+

−

*Set application variables in the Application.cfc. The values you use ultimately depend on the function of you application; however for best practices use the following.

+

−

+

−

<pre>

+

−

+

−

applicationTimeout = #CreateTimeSpan(0,8,0,0)#

+

−

+

−

loginStorage = session

+

−

+

−

sessionTimeout = #CreateTimeSpan(0,0,20,0)#

+

−

+

−

sessionManagement = True

+

−

+

−

scriptProtect = All

+

−

+

−

setClientCookies = False (Use JSESSIONID)

+

−

+

−

setDomainCookies = False

+

−

+

−

name (This value application dependent; however it should be set)

+

−

</pre>

+

−

+

−

*Do not depend on client-side validation. Validate input parameters for type and length on the server, using Regular Expressions or string functions.

*Database connections should be made created using a lower privileged account. Your application should not login to the database using (sa or dbadmin)

+

−

+

−

*Hash passwords in a database or flat file using SHA-256 or greater with a random salt value for each password. For example, Hash(password + salt, “SHA-256”)

+

−

+

−

*Call StructClear(Session) to completely clear a users session. Issuing <cflogout> when using LoginStorage=Session removes the SESSION.cfauthorization variable from the Session scope, but does not clear current user’s session object.

+

−

+

−

*Prompt the user to close their browser to ensure that header authentication information has been flushed.

+

−

+

−

+

−

'''Best Practices In-Action'''

+

−

+

−

To help demonstrate the use some of these best practices, let’s assume you want to protect a page called “protected.cfm”. To protect this content we need the Application.cfc, a login page (login.cfm) and code to perform our authentication and logout (Auth.cfc). Note all the filenames and variables used in this section are arbitrary.

+

−

+

−

'''Application.cfc'''

+

−

+

−

+

−

<pre>

+

−

+

−

<cfcomponent >

+

−

+

−

<cfscript>

+

−

+

−

This.name = "OWASP_Sample";

+

−

+

−

This.applicationTimeout = CreateTimeSpan(0,8,0,0);

+

−

+

−

This.sessionManagement = true;

+

−

+

−

This.sessionTimeout = CreateTimeSpan(0,0,20,0);

+

−

+

−

This.loginStorage = "session";

+

−

+

−

This.scriptProtect = "All";

+

−

+

−

</cfscript>

+

−

+

−

+

−

+

−

<cffunction name = "onRequestStart">

+

−

+

−

<cfargument name = "thisRequest" required="true"/>

+

−

+

−

<cfset Request.DSN = "owaspDB"><!--- <cflogout> --->

+

−

+

−

<cfif isDefined('Form.logout')>

+

−

+

−

<cfinvoke

+

−

+

−

component="auth"

+

−

+

−

method="logout"

+

−

+

−

loginType="simple">

+

−

+

−

</cfif>

+

−

+

−

<cflogin>

+

−

+

−

<cfif NOT isDefined('cflogin')>

+

−

+

−

<cfinclude template="login.cfm"><cfabort>

+

−

+

−

<cfelse>

+

−

+

−

<cfif len(trim(cflogin.name)) AND len(trim(cflogin.password))>

+

−

+

−

<cfinvoke

+

−

+

−

component="auth"

+

−

+

−

method="LoginUser"

+

−

+

−

returnvariable="result"

+

−

+

−

strUserName="#cflogin.name#"

+

−

+

−

strPassword="#cflogin.password#">

+

−

+

−

</cfinvoke>

+

−

+

−

<cfif result.authenticated>

+

−

+

−

<cfloginuser

+

−

+

−

name="#cflogin.name#"

+

−

+

−

password="#cflogin.password#"

+

−

+

−

roles="#result.roles#" >

+

−

+

−

<cfelse>

+

−

+

−

<cfset Request.boolError = true>

+

−

+

−

<cfinclude template="login.cfm"><cfabort>

+

−

+

−

</cfif>

+

−

+

−

<cfelse>

+

−

+

−

<cfset Request.boolError = true>

+

−

+

−

<cfinclude template="login.cfm"><cfabort>

+

−

+

−

</cfif>

+

−

+

−

</cfif>

+

−

+

−

</cflogin>

+

−

+

−

</cffunction>

+

−

+

−

<cffunction name="onSessionEnd">

+

−

+

−

<cfargument name="thisSession" required="true"/>

+

−

+

−

<cfargument name="thisApp" required="false" />

+

−

+

−

<cfinvoke

+

−

+

−

component="auth"

+

−

+

−

method="logout"

+

−

+

−

loginType="simple">

+

−

+

−

</cffunction>

+

−

+

−

</cfcomponent>

+

−

+

−

</pre>

+

−

+

−

+

−

+

−

+

−

+

−

'''protected.cfm'''

+

−

[[Category:FIXME|I am not sure why this isn't formatting as a heading]]

Probably the second most widely used method of authenticating users on the web after Basic Authentication is database login. The code snippet below shows how to accomplish database authentication using best practices.

In addition to using controls available via IIS and using the browser dialog box, ColdFusion allows you to authenticate users via a web form using NTLM. The code snippet below shows how to accomplish NTLM authentication using best practices.

Credential stores SHOULD be designed to implement several hashing algorithms as these will be replaced soon and as change is inevitable, your application should plan today for this transition

Applications SHOULD have the facility to alert the user as to failed login attempts and offer to allow them to change their password (if applicable)

Applications SHOULD have the facility to notify the user of their last logged in time, and subsequently report a fraudulent login if they disagree with that date and time

Authentication and registration processes, particularly login failures, SHOULD provide no information as to if an account exists or password or is wrong. A single error message for the end user covering both scenarios is more than adequate

All pages SHOULD have an effective logout button on every single page in a common location

Applications SHOULD possess administrative functions to detail and manage never logged in accounts, idle accounts, and accounts that have been administratively- or soft- locked

Passwords MUST be easily changed. Applications MAY include password strength indicators or provide a random password generator function

There SHOULD be a logical difference between administrative lockout and failed login lockout, so that re-enabling all users en masse does not unlock administratively locked users

Medium value applications SHOULD and High value applications MUST provide a mechanism to re-authenticate or transaction sign high value transactions

Applications MUST protect credentials from common authentication attacks as detailed in the Testing Guide. Following the sections in this chapter will produce such an outcome

Things not to do:

Applications MUST NOT store any secret part of the credential in the clear (passwords or questions and answers if implemented)

Applications MUST NOT expose the credential in untrusted locations, such as cookies, headers or hidden fields

Applications MUST NOT implement CAPTCHA as there is case law against them with respect to universal access and ineffective

Applications MUST NOT implement questions and answers as they are contrary to most privacy regimes and ineffective

Applications SHOULD NOT rely on infrastructure authentication, such as REFERER headers or the client's DNS or IP address as these can be faked

Thresholds Governor

All authentication systems are designed to be open to anonymous, unauthenticated users. Therefore, they are open to denial of service and brute force attacks.

Applications implementing their own authentication systems should consider a threshold governor to prevent the over-use of the following paths:

Account registration processes (if any)

Primary authentication path

Step up authentication (such as two factor tokens)

Password change**

Password resets**

(**Low value systems only - Most medium and all high value systems should not be using passwords, and thus do not possess password reset capabilities)

OWASP's ESAPI project contains a reference implementation of a basic threshold governor, which is in turn linked to the intrusion logging mechanism based upon a certain number of failed events being raised in a particular time period. You may wish to use this mechanism in your own code by adopting ESAPI and overriding the necessary classes as you see fit.

Sequence Diagram

TBA

Suggested Timeouts

The following timeouts are suggested, but any value will do as long as it severely impacts both vertical and horizontal brute force attacks.

One failed attempt: At least 5 seconds

Two failed attempts: At least 15 seconds

Three failed attempts: At least 45 seconds

If there's an obvious brute force attempt (for example, more than 100 attempts per minute), the IP address and/or session should be banned for a period of time, such as 15 minutes. In such cases, error messages should make it clear why this action has been taken.

Distributed Brute Force

If in case of a distributed brute force, the application should monitor the total number of failed authentication attempts per minute, and have a configurable threshold above which the authentication system automatically injects a configurable 45+ second delay between authentication attempts. This will make all but the largest distributed brute force attempt infeasible, even when looking for a single account with a well known password.

Authenticating Value Transactions with Transaction Signing

Any system can benefit from the use of transaction signing. Transaction signing requires a user to interact with some out of bound device, such as a two factor token calculator or SMS message to complete a high value transaction. For example, if a bank wishes to establish an online credit card registration process, they could get the user to verify that this transaction is valid by completing a transaction verification. In the case of mobile phones, this could simply include sending a random value to the user's phone or ringing them with a IVR system and digitally read a set of digits to be entered.

SMS Based Transaction Signing Sequence Diagram

For low end through to moderate high value systems, the use of a second factor such as a mobile phone is an excellent low cost alternative to two factor authentication fobs. This mechanism is actually stronger than most two factor authentication fobs as to attack it, the attacker would have to involve individual users to perform the same sort of attacks as they would do today.

There is a single weakness in this model - mobile phone registration and updating. If attackers can register their phone before the real user or update the user's profile to become their number, the attacker can perform high value transactions with impunity. The application MUST enforce that any one number is only linked to a single account, and to ensure that appropriate safeguards are in place, for example if the same number is being used in multiple accounts at different times as these are signs of phishing.

Physically requiring proof of identity to register or update the mobile phone produces the strongest results.

Token Based Transaction Signing Sequence Diagram

For the highest value systems, the use of transaction signing calculators as sold by a number of token manufacturers would be the best alternative. These take a portion of the transaction's details and combine it with a private key signing on the calculator. Attackers would have to get the user to log in, type in the values and then subsequently give them the result before fraud would occur. This is extremely unlikely and is not amenable to widespread phishing attacks.

Authenticating With Multi-Factor Systems

TBA

What is two factor authentication, really?

Two factor authentication is using more than one of:

Something you know (account details or passwords)

Something you have (tokens or mobile phones)

Something you are (biometrics)

to logon or process a transaction.

If you can create another factor, such as a special token on a particular computer based upon a set of something you know or a single biometric reading, this is effectively single factor authentication. For example, some banks implement a scheme that requires you to type a username, passwords and answer a personal question, and if you get those right, your computer will be marked as a physical factor. It's obvious that this scheme is open to many attacks, but the primary weakness is that the system is not truly a two factor solution as it is based upon a simple set of "something you know" and thus you can make any computer a second factor if you know these details.

Typical two factor solutions involve registering a hardware device such as a token, phone or biometric device on top of the "something you know". In all cases, the two factors should be used together for best results.

Lastly, biometric devices are known weak against simple physical attacks, have a known false positive and known false negative authentication rate, thus making them less than desirable as a non-repudiation mechanism. Additionally, biometrics are expensive compared to the cost of phone- and token- based two factor authentication schemes. Until the technology significantly improves, becomes price competitive with cheap phone and tokens, and is relatively universal, biometric devices should not be considered except in highly specialist circumstances.

Sequence Diagram

TBA

Weaknesses

Simple two factor tokens and one time pads, such as German banking TAN lists, are subject to man in the middle attacks. The attacker will put up a realistic looking login page, and instead of logging in directly, the attacker will use the token or TAN to log in first and perform value transactions such as transferring all the money out from a bank account, and then present an error to the user. Once they log in properly, they will discover their account has been attacked.

As such, cheap two factor tokens by themselves do not immediately decrease fraud rates. Only transaction signing can do that.

Single-Sign On (SSO) Authentication

TBA. Discuss LDAP, AD, TAM, SiteMinder.

Sequence Diagram

TBA

Federated Authentication

TBA

Sequence Diagram

TBA

Authentication For Low Value Systems

Low value systems, such as blogs, social networks and so on, should be free to implement weak authentication mechanisms. Given the chance, users should be able to adopt stronger authentication mechanisms if you have them available.

Registration

Self-registration can be problematic, particularly for highly sought after resources such as free mail accounts.

Deleting a User Using ESAPI

Password Guidelines

Store the password in a strongly hashed and salted format to prevent rainbow table attacks.

Pass phrases (long passwords over 20 characters in length) should be encouraged

Short passwords should be prohibited

Do not force folks to change passwords frequently as this results in the users writing the passwords down insecurely

Where suitable, try to share the credential with as many low value systems as possible to encourage one single high quality password

Allow expert users to store strong passwords in approved password managers. Encourage them to use unique random passwords for each service

Lockouts

Lockouts are counter-productive if implemented badly.

In general, the threshold governor (see above) should be implemented to prevent any one IP address monopolizing authentication CPU, network, and IO resources. If necessary, such as for compliance with a national security standard, a configurable soft lockout of approximately 15-30 minutes should apply, with an error message stating the reason and when the account will become active again.

Ensure any lockout mechanism protects against both same username, many passwords and many usernames and same password attacks. This can only be done using the threshold governor approach as shown above.

Minimum hash strength

The minimum hash strength SHOULD be SHA-256 for the next few years.

Applications MUST be designed to allow selection of multiple algorithms, as the USA's NIST is currently running an hashing algorithm competition, which will choose a successor to SHA-256, SHA-384, and SHA-512. Your application MUST be able to transition to the new hashing algorithm by no later than one year after the new algorithm's release. This doesn't mean that MD5 will be dead at that point, but your application should cope with the idea that insecure algorithms such as MD5 or SHA-1 can be retired at some point.

Authentication Anti-Patterns

Do not implement any of these features - they are either dangerous, illegal, ineffective, or all of the above.

Default Accounts

Do not ship your software with any default accounts such as "YourProductName", "sa", "root", "administrator", or any hard coded service accounts. Do not include any screen shots or text in the documentation indicating a preferred username or password for a particular application ID or service.

Remember Me

Implementing remember me functionality can be incredibly hard. Often software will just embed the username and password in headers or cookies, or a hash or crypto blob of the same. Based upon your risk profile, your application:

High value applications MUST NOT possess remember me functionality.

Medium value applications SHOULD NOT contain remember me functionality. If present, the user MUST opt-in to remember me. The system SHOULD strongly warn users that remember me is insecure particularly on public computers

Low value applications MAY include an opt-in remember me function. There should be a warning to the user that this option is insecure, particularly on public computers.

ESAPI's reference implementation has basic "remember me" functionality based upon an AES encryption of the username and password, but this is not recommended for medium value systems, and should be used with care on low value systems.

Hard Coded Credentials

Do not include any credentials in your source code, including (but not limited to) usernames, passwords, certificates, token IDs, or phone numbers.

Such constants belong in properly protected properties or configuration files. ESAPI has an encrypted properties mechanism you can use to protect clear text credentials in such files.

CAPTCHA

CAPTCHA (Completely automated Turing Tests To Tell Humans and Computers Apart) are illegal in any jurisdiction that prohibits discrimination against disabled citizens. This is essentially the entire world. Although CAPTCHAs seem useful, they are in fact, trivial to break using any of the following methods:

Optical Character Recognition. Most common CAPTCHAs are solvable using specialist CAPTCHA breaking OCR software.

Break a test, get free access to foo, where foo is a desirable resource

Pay someone to solve the CAPTCHAs. The current rate at the time of writing is $12 per 500 tests.

Therefore implementing CAPTCHAs in your software is most likely to be illegal in at least a few countries, and worse - completely ineffective.

Secret Questions And Answers

Questions and answers are back door credentials - they equate to the username and password for the user. Often such schemes use "Mother's Maiden Name" or other easily found information. If all systems use the same Q&As, it will be possible to break into many accounts using the same information.

They are unacceptable for the following reasons:

Collection of information about people without their explicit consent (such as "Mother's maiden name") is illegal in most privacy regimes. Such collection is subject to privacy laws, review and correction by the subject, and so on.

IT Security Policies and standards such as ISO 27000 prohibit the clear text storage of passwords, but almost all Q&A schemes store both the question and answer in the clear

The information in the answers is public for a goodly portion of the users of the Internet, and thus is found using public sources

Secret Questions and Answers have been publicly abused, most notably by the attack on Sarah Palin's e-mail account, exposing her use of her Yahoo free mail account for government business.