What are some password related security threats?


The simplest way to discover someone’s password is to have them tell you it. This can be done by persuading them to type it into a website you control (commonly known as phishing), by installing a keylogger (either hardware or software) on a computer, or by reading traffic on an unencrypted wireless or wired network. For intruders these methods have the great benefit that it does not matter how long or complex a password the user has chosen: the intruder can simply read it. Cracking of hashes/brute force If the intruder cannot obtain the password then he can simply use a program to generate billions of possible passwords (often using the same techniques as are suggested for choosing passwords) and try each of them against the account. The crudest way to do this is to simply attempt to log in using each generated password: the resulting flood of password failures should be easy for a system administrator to spot, but since attackers continue to use this approach it seems it is still reasonably successful. Attempts may be made against obscure authenticated services, such as SSH and LDAP, to reduce the chances of detection.

Offline cracking 

Brute force attacks are much less obvious if the intruder can obtain a copy of an encrypted password, for example if a system’s password file can be downloaded, if a hash has been included in a public file, or if an unknown machine can join an authentication group. Once the intruder has one or more encrypted passwords he can do the brute force guessing on his own machine (using modern hardware and algorithms this may take only a few minutes for short passwords), or even use a cloud service, and then return to login to the target once the correct password has been discovered. 

Password recovery/reset systems 

An intruder may not need to get the password from the user if he can persuade the authentication system to either mail it to him or change it to something of his choice. Systems to allow the legitimate user to recover or change a password they have forgotten can also let other people do the same. Helpdesk operators need to be particularly careful to check the identity of anyone asking for a password reset. On-line systems that rely on “secret questions” such as “name of first school” or “birthday” are trivial to defeat if that information can be found on a social network. Systems that send reminders to a backup e-mail address or phone number can fail if the user changes address or number allowing the abandoned backup to be registered by someone else. Educated guesswork It should be obvious that the same techniques used to guess the answers to secret questions can also be used to guess passwords. Anything based on something your friends will know, or that is available from a website, is a very poor choice as a password.

Reuse of Passwords 

Most people now have many different accounts on different systems in both their private and work lives. Although best practice is to have a different password for every account, unfortunately it’s much more common to reuse the same password on different services. That means that an organisation doesn’t just have to worry about the above attacks against its own systems, it has to worry about the same attacks on all other systems where the same password has been used. This probably means that an organisation can no longer completely control whether its passwords are secure: it should also develop plans and systems to detect and respond when a password has been compromised. 

Default passwords 

Equipment and software often has standard pre-configured passwords which, of course, are well known to intruders. Such passwords should always be changed, though it can still be hard to find out where they may have been used. A related problem is where a password is set for the user by a local administrator. Unless the user is required to change the password to one that the administrator does not know, doubt can always be raised which of the two people who knew the password was actually logged in and responsible for the account’s activity. If there are reasons that users cannot be forced to change their passwords on first use then procedures need to be carefully designed and followed to ensure that suspicion does not fall on the wrong person. 

Password embedded in code 

Passwords are also sometimes disclosed by being included in scripts or programs. While this may appear an easy way to automate access to an interactive system it carries high risks of disclosure and alternatives should be used wherever possible. If there is no other alternative then the script or program must be very carefully protected against deliberate or accidental access. The worst possible outcome is for a script containing a plaintext password to end up on a public website.


Difference between non-authenticated and pre-authenticated application assessment?

Prior to testing it's important to determine what parts of the application require authentication and authorization. Security testing should approach the application from both a non-auth and pre-auth perspective. The goal of the non-authenticated assessment is to identify any security risks which are openly exposed by the application. The authenticated assessment is to identify the security risks once a valid user logs in. For an authenticated assessment ensure that the project team provides credentials in advance. 


What are some common application security testing tools?

Browser (e.g. Firefox, Chrome) Manual crawling of the application and support manual testing of the application. Firefox has a number of built-in plugins such as Web Developer and Firebug that can provide easily viewable information on the source including hidden fields and HTML parameters.

Burp Suite Pro Web proxying tool that supports automated crawling, intercept and manipulation of HTTP requests, replay, injections, randomness of session identifiers, etc. The pro version also supports passive and active scanning.

Nikto (Kali distro) Web server vulnerability scanner that can fingerprint the web server and identify any known vulnerabilities with the web server software or installed application components (e.g. Tomcat) residing on the web server.

Nmap (Kali distro) Port scanner that can quickly identify open application ports on the systems as well as fingerprint the services bound to each port. Nmap additionally provides power in the NSE scripts which can probe services for detailed information, e.g. SSL supported ciphers.

Web Inspect Automated vulnerability scanning of web applications and web services. This is particularly useful for large, complex applications.

SQLmap (Kali distro) SQL injection and blind SQL injection tool used to pinpoint and execute proof of concept SQL injections.

Dirbuster (Kali distro) Brute-force directory guessing to find hidden web interfaces (e.g. admin pages, server status pages).


Why is context important for application security testing?

In order to gain better understanding of the risk associated with a vulnerability, one must gather contextual information related to an application's use.

For example, a cross-site scripting (XSS) vulnerability found post-authentication on an internal app accessible to only 10 employees within the organization will have a lower risk of exploitation than a pre-authentication XSS found on an Internet-facing app.

Questions to ask: 

Business Purpose What business function does the application serve? How important is the application to the success of the business' goals?

User Population How many and what type of users are anticipated to use the application?

Data Types What type of data does the application process and/or store? Are there any PII or PCI elements?

Access Roles How many roles does the application offer and to what granularity?

Depth of the Application How many pages/components does the application consist of? [Crawl the application]

Web/application server What web and application server product does the application run on? [Fingerprint the front end]

Back end server Is data stored in a relational database (e.g. SQL) or flat file? [Fingerprint the back end]


Network/infrastructure testing cases - describe possible insecure wireless configuration issues.

Wireless access is enabled (and not required)? Wireless access is configured with open access? SSID suppressed/not broadcast? not ideal, will confuse users, hackers can find it.

MAC address filtering? not ideal, can be spoofed

Wireless access point uses WEP? Wireless passphrase is easily-guessable? 

Bluetooth access is enabled (and not required)? Bluetooth pairing is not configured with authentication?


Network/infrastructure testing cases - describe possible insecure DNS configuration issues.

Does the DNS service allow unauthorized zone transfers? Is the DNS service vulnerable to cache poisoning? Does the DNS service allow unauthorized dynamic updates?


Network/infrastructure testing cases - describe possible insecure NTP configuration issues.

Is the system configured for NTP? Is NTP from an authenticated and authorized source?


Network/infrastructure testing cases - describe possible unnecessary services.

Is FTP (21/TCP) enabled? Is anonymous FTP login allowed? Is TFTP enabled and not necessary? Is DHCP enabled and not necessary? Is DNS enabled and not necessary? Are unnecessary routing protocols (e.g. BGP, EIGRP, OSPF, RIP, VRRP, GLBP, VTP, DTP) enabled? Are other unnecessary protocols (e.g. echo, finger, chargen) enabled?


Network/infrastructure testing cases - describe possible insecure remote administration issues.

Is Telnet (23/TCP) running on the system? Is HTTP login enabled on the system? If HTTPS is enabled, are weak ciphersand protocols suported? If SSH is enabled, is SSHv1 supported? Is SNMP v1 or 2c supported? Is the administrative interface accessible over other clear-text protocols (e.g. rlogin, rsh)?​


Application testing cases - describe possible injection scenarios

​Is the application vulnerable to SQL injection?
command injection?
LDAP injection? ​
XML injection?​


List some application types that would require application testing.

Custom-coded apps (both in-house and 3rd party), commercial of the shelf (COTS) app, web service, thick client/desktop app


Describe a security assessor's responsibilites when assigned to an IT project.

Review initial security scoping documents, submitted by the project team, for completeness and accuracy.

Review system requirements packages to ensure that projects address enterprise and compliance requirements, standards, and best practices. 

Review system design packages to assess the proposed system architecture, communication paths, roles, and functionality. Ensure you understand the as-is and to-be states. 

Perform source code review of in-house developed applications to identify vulnerable code. 

Conduct technical security testing of the application or system to identify vulnerabilities and determine risk exposure.

Work with the project team to address outstanding security findings. Complete your review providing a summary of the assessment, findings, mitigations, and recommendation.


How would you evaluate the security controls for various technology components?

Document a repeatable, comprehensive security testing methodology to evaluate the security controls for various technology types. ​​​This will better assure consistent, accurate testing of systems during the SDLC for projects.


What must a security assessor do prior starting an assessment?

Prior to any security assessment, have the PM/tech lead complete the scoping questionnaire. This will identify all in-scope and out-of-scope technologies and components and will allow the security engineer to estimate the level of effort to complete security testing. The in-scope items in the questionnaire will be reflected in the security test plan and confirmed by the PM/tech lead prior to security testing.

Wow you made it to the end. That's all we have so far. You probably have some inside knowledge of your own. Send it our way, we'll review, and post.

You can then come back and refresh your memory, with your own...memories.