Common Weakness Enumeration

 I was recently reminded of this enumeration. 

Read, learn, and live it.

CWE - 2022 CWE Top 25 Most Dangerous Software Weaknesses (mitre.org)

Generating Secure Passwords: A C++ Example

 For some reason, that escapes me at the moment, I needed to generate a few passwords.  And having spent most of my career as a Software Engineer, I don't spend the time brainstorming those bits, I write a program.  Or perhaps better, I let someone else write the program. 

So I did: I found someone's work, which was broken, fixed it, improved it, and now I'm sharing it with you.

Enjoy.

https://github.com/W1T3H4T/password-gen

Separation of Duties: Do not cross the Production and Test Streams

Here's a quick reference for justifying why an organization should never mix development, test, and production configurations and data.

 

PCI DSS 3.2.1

• 6.4 – Follow change control processes and procedures for all changes to system components.  The process must include the following:
• Development/test environments are separate from production environments with access control in place to enforce separation.
• A separation of duties between personnel assigned to the development/test environments and those assigned to the production environment.
• Production data (live PANs) are not used for testing or development.
• 6.4.1 – Separate development/test environments from production environments, and enforce the separation with access controls.
• Examine network documentation and network device configurations to verify that the development/test environments are separate from the production environment(s).
• Examine access controls settings to verify that access controls are in place to enforce separation between the development/test environments and the production environment(s).
• 6.4.2 Separation of duties between development/test and production environments
• Observe processes and interview personnel assigned to development/test environments and personnel assigned to production environments to verify that separation of duties is in place between development/test environments and the production environment.
• 6.4.3 – Production data (live PANs) are not used for testing or development
• Observe testing processes and interview personnel to verify procedures are in place to ensure production data (live PANs) are not used for testing or development.
• Examine a sample of test data to verify production data (live PANs) is not used for testing or development.

National Institute of Standards and Technology (NIST)

• SP.800-53
• CM-2(6) BASELINE CONFIGURATION | DEVELOPMENT AND TEST ENVIRONMENTS
• https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search#!/control?version=5.1&number=CM-2
• Maintain a baseline configuration for system development and test environments that is managed separately from the operational baseline configuration.

• CM-4(1) IMPACT ANALYSES | SEPARATE TEST ENVIRONMENTS
• https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search#!/control?version=5.1&number=CM-4
• Analyze changes to the system in a separate test environment before implementation in an operational environment, looking for security and privacy impacts due to flaws, weaknesses, incompatibility, or intentional malice

• Cybersecurity Framework Version 1.1
• https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.04162018.pdf
• PR.DS-7: The development and testing environment(s) are separate from the production environment     ·      
• CIS CSC 18, 20
• COBIT 5 BAI03.08, BAI07.04
• ISO/IEC 27001:2013 A.12.1.4
• NIST SP 800-53 Rev. 4 CM-2

International Organization for Standardization (ISO)

• https://www.unifiedcompliance.com/products/search-controls/control/6088/
• Testing of releases shall be conducted in a controlled acceptance test environment. (§ 9.3 ¶ 4, ISO 20000-1, Information Technology - Service Management - Part 1: Service Management System Requirements, Second Edition)
• Development, testing, and operational environments shall be separated to reduce the risks of unauthorized access or changes to the operational environment. (A.12.1.4 Control, ISO 27001:2013, Information Technology - Security Techniques - Information Security Management Systems - Requirements, 2013)
• The development, test, and operational systems should be separated to reduce the chance of unauthorized modification to the operational system. The test system should emulate the operational as closely as possible. (§ 10.1.4, § 12.5.1, ISO 27002 Code of practice for information security management, 2005)

 Center of Internet Security (CIS)

• https://controls-assessment-specification.readthedocs.io/en/0.0.1/control-18/control-18.9.html
• Maintain separate environments for production and non-production systems. Developers should not have unmonitored access to production environments.

CSPRNG: A Linux One-Liner

tl;dr

What is a CSPRNG?  

A CSPRNG is a Cryptographically Secure Pseudo Random Number Generator.  It is the cousin of the RNG, or Random Number Generator that we used decades ago.

In the past, rand and seed were used together to generate pseudo random numbers.  When a constant seed is provided (e.g., the number 125), the random numbers generated by rand are well-defined.  

These two functions actually complement each other well in fuzz-testing applications, since the sequence of randomness can be reproduced between invocations of the tool.

However, there's a problem: these functions are not viable for creating key material.  In cryptography, well-formed randomness is required.  As such, rand and seed are not candidates for generating key material.  What is needed is a source of randomness that mimics the real world: such as the path a leaf takes when falling to the ground.

In the cryptography discipline, CSPRNGs are used to generate private and public key material, such as those used for certificates, secure shell sessions, and cryptocurrency. 

Can I generate my own CSPRNG on Linux, using a shell?

Yes.  It turns that on Linux, it's a very easy task.

Every (or almost every) recent Linux implementation generates random data that can be accessed through /dev/random, /dev/arandom, and /dev/urandom.  There are differences between these implementations that you should be aware of when selecting them for any variety of solutions.  See here for more information: /dev/random vs /dev/urandom and are they secure?

For this example, we will use /dev/urandom.

The easiest method of obtaining random data is via cat.  We'll follow that by extracting a set number of bits, reformatting the data, and delivering a string of hexadecimal digits. 

The One-Liner:

cat /dev/urandom | head -c 2048| od -x | cut -b 8-40 | xargs | sed 's/ //g' | head -c 32

In this script, we grab 2048 characters of data (16384 bits), convert them to hexadecimal using od, and then grab the hex digits using cut, while removing the line-feeds.  We remove the spaces created by od, and then select a string of 32 bytes, which is 256 bits (32 x 8 == 256).

If you want a bit more sophistication, then here's a full script:

#!/bin/bash

#   =================================================================

#   File    :   csprng.sh

#   Function:   Generate a cryptographically secure random number

#   Who     :   David Means <www.w1t3h4t.com>

#   =================================================================

function doHelp()

{

    echo

    echo "Generate a cryptographically secure random number"

    echo

    echo "Usage: $(basename $0) {bits}"

    echo

    echo "Example: $(basename $0) 128"

}

if [ $# -eq 0 ] ; then

    doHelp

    exit

fi

bytes=0

bitCheck=$(($1 % 8))

if [ $bitCheck -eq 0 ]; then

    bytes=$(($1 / 8))

     cat /dev/urandom | head -c 2048 | od -x | cut -b 8-40 | xargs | sed 's/ //g' | head -c ${bytes}

     echo

else

    echo 

    echo "$1 not divisable by 8"

    echo

fi

The Only Valid Measurement of Security Quality

The CPU as a BlackBox

The black boxes you trust for all of your computations are not secure. They have their own backdoors.

This is why we do defense in depth.  While configuring our systems to run only authenticated software may seem to be over-kill, it may soon be the only reasonable solution.

Investigate ways to enable your systems to execute signed and authenticated software only.

BlackHat 2018

This talk will demonstrate what everyone has long feared but never proven: there are hardware backdoors in some x86 processors, and they're buried deeper than we ever imagined possible. While this research specifically examines a third-party processor, we use this as a stepping stone to explore the feasibility of more widespread hardware backdoors.

YouTube: GOD MODE UNLOCKED

BlackHat 2017

A processor is not a trusted black box for running code; on the contrary, modern x86 chips are packed full of secret instructions and hardware bugs. In this talk, we'll demonstrate how page fault analysis and some creative processor fuzzing can be used to exhaustively search the x86 instruction set and uncover the secrets buried in your chipset.

YouTube: Breaking the x86 Instruction Set

Password Policies in Finance

Developing a Password Policy

A password policy cannot be created in a vacuum, it must be derived from the Security Policy & Process of the Organization. Usually, this is called the ISMS, or Information Security Management System. In the general case, it will consist of a variety of policy documents addressing different aspects of information security.

For Banking and Payments, an ISMS will direct its Business Units to derive best practices from at least the following standards and regulatory artifacts:

• PCI SSC – Payment Card Industry Security Standards Council
• SOX – Sarbanes-Oxley Act
• GLBA – Gramm-Leach-Bliley Act
• … and potentially others.

Per PCI, SOX and GLBA requirements, your password needs will comply with these requirements:

PCI DSS

• 2.1 – Never use vendor-supplied defaults
• 2.3 – Encrypt all non-console administrative access using strong cryptography
• 3.6.6 – If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.
• 6.3.1 – Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
• See Requirement 8: Identify and authenticate access to system components

SOX

Sarbanes-Oxley experts and auditors recommend that to meet the minimum for compliance, passwords should:

• Be at least eight characters long;
• Include a combination of letters and numbers;
• Not contain personal information.

GLBA

Section 501 of the GLBA, “Protection of Nonpublic Personal Information,” requires financial institutions to establish appropriate standards related to the administrative, technical, and physical safeguards of customer records and information. The scope of these safeguards is defined in the GLBA Data Protection Rule, which states that financial institutions must:

• Ensure the security and confidentiality of customer data
• Protect against any reasonably anticipated threats or hazards to the security or integrity of such data
• Protect against unauthorized access to, or use of, such data that would result in substantial harm or inconvenience to any customer.

Security Policies

When creating any kind of Security Policy, avoid the temptation to first consider assets, such as information systems consisting of infrastructure, applications, and operating systems. Instead, focus on the sensitive information that requires protection. 

A Security Policy can be understood as follows:

It is a high-level statement (plan or framework) addressing security requirements and objectives. It may address an entire organization or be specific to an issue or system.

It is a type of governance in that it expresses the security framework established by management. It is the primary method by which an organization sets expectations for a variety of topics.

• The audience for the policy consists of architects, designers, implementers, installers, maintainers, and users of the Information the Organization needs to protect.
• Policies can be written to affect hardware, software, access, people, connections, networks, telecommunications, enforcement, and so forth.
• A good Security Policy cannot be drafted without a comprehensive understanding of the security standards that must be achieved.

Security Standards

While a Security Standard may be an internally developed, it is usually an external document authored by a regulatory organization (e.g., PCI SSC), or an organization tasked with developing best practices (e.g., NIST, ISO, ISACA).

• A Security Standard is an enumeration of actions or rules that must be performed or followed to implement a Best Practice. E.g., NIST SP-800-53, ISO 27001, COBIT

Process

• A Security Process defines a set of activities or related tasks that when combined, produce the desired result.

Procedures

• Procedures are step-by-step instructions to perform various tasks in accordance with established Policy and Process.

Guidelines

• Guidelines provide advice regarding how to achieve a goal of a Security Policy, or Process. They are a communication tool used to provide suggestions, they do not provide rules.

Developing an Information Security Policy

Data Identification and Scope

• Identify sensitive information that must be protected;
• Identify every location where sensitive information is scored;
• Develop data classifications and tag data;
• Determine in-scope information systems and out-of-scope information systems, tagging information systems appropriately;
• Determine the approved ways in which data may be accessed.

Develop a Risk Management Framework

• A Risk management framework helps you understand the risks associated with your information and how to manage those risks.

This is a key process to developing a password policy.

Establishing a risk assessment framework

• Identify risks
• Analyze risks
• Evaluate risks
• Select risk management options

Create the Risk Treatment Plan

• This involves creating and managing security controls to mitigate and remediate risks.

Putting it together

Once you understand the data that must be protected, and the systems that process that data, the risks to which you are most commonly exposed, you can then begin developing requirements for Information Systems relevant to:

• Regulatory requirements;
• Data classification;
• Best Practices;
• User Experience & Acceptance

The SDLC vs. An SDLC

Understanding how to implement the SDLC in your SDLC

In the 1960s, we developed a process called the System Development Life Cycle. In the 1990s and early 2000s, we began creating a process called the Security Development Life Cycle. Sometimes we shorten that to SDL (as in Lifecycle) but the intent is the same. In other instances, we emphasize only the development of secure software, incorrectly implementing a Secure Development Life Cycle.

In this post, I'm exploring the System Development and the Security Development life cycles. These process phases are not written in stone, but they do represent the general flow of development for a given information system. Your experience may vary.

The System Development Life Cycle

A product or system development life cycle generally consists of the following phases.

Initiation

In the initiation phase, product stakeholders develop concepts, business requirements and perform analysis. A requirements specification is developed. Executive approvals are generally obtained in this phase. 

Planning

In the planning phase, product stakeholders develop fundamental and architectural design constraints based on requirements. Primary use cases are developed.

Design

Information System designs are developed, less important implementation decisions are made using requirements documentation. Data classification and data dictionaries are developed. Use cases are refined and expanded.

Implementation

Coding begins and quality assurance designs (bug bars, quality gates) are specified and implemented. Minor design considerations are explored, tested and implemented. Components of the application are submitted for verification. 

Verification

Functional and non-functional testing is performed. The application may be pushed back into the implementation phase as components are tested. The product is moved towards production using one or more stages involving smoke testing, readiness testing, and a variety of reviews and approvals.

Release

The product is moved into production. The Product Team receives reports from consumers and concerned 3rd parties pertaining to features, bugs, and vulnerabilities. Based upon this information, the product lifecycle will restart in the Planning phase, ultimately resulting in major, minor, or patch releases.

Disposal

The product is decommissioned and potentially replaced with a different solution.

The Security Development Life Cycle & Alignment

The security development life cycle injects the system development life cycle with security best practices at each phase.

Initiation

Concepts and business requirements are reviewed for the application of customary security controls. General architectural security requirements are expressed and proposed.

Planning 

Architectural security requirements are reviewed, revised and established. Data flow diagrams are produced and threat modeling (e.g., STRIDE by element & interaction) is performed. Abuse cases are developed. General product security requirements are reviewed, revised and established.

Design 

Abuse cases are refined and developed. Product security requirements are reviewed and updated. Core components are reviewed for security requirements in alignment with architectural security requirements and industry best practice standards.

Implementation 

Product security requirements are implemented and built into the product; secure architecture design, abuse cases, and threat models instruct implementation. A variety of security testing is performed in conjunction with known attack vectors and threat actors. Test-driven development may be utilized; unit tests and security tools are developed and procured to exercise and expose the security qualities of the application.

Verification 

Additional security testing is performed for those things that cannot be easily confirmed with unit tests or test-driven development. Testing results are confirmed against abuse cases and product security requirements.

Release 

The information system is monitored for vulnerabilities in the applications, the operating systems, and the infrastructure. Observations are communicated to the product team. The PSIRT is engaged as necessary.

Disposal

Design documentation, data classification, and data dictionaries are reviewed. Plans are developed to retain or dispose of data in a secure manner.

Summary

The idea is to understand where key activities are taking place within the Development Life Cycle, so that we may insert the appropriate Security Development activities.  

Remember this key idea: just as Software Engineers develop applications using software and engineering best practices, Security Architects enable the development of Secure Qualities that can be traced to Security Standards and well-designed Product Security Requirements.

Surviving Payments in a Hackable World

I was once the Security Architect for a well-known payment gateway provider that served a wide variety of retail and hospitality customers.  Here’s how I changed my behaviors after being exposed to the payments world.

My Credit Online / Offline ToDo Checklist

• Expect that your Credit card will be eventually be compromised
• It's not the end-of-the-world.
• But ...
• Have a couple of credit cards: one you use routinely; the other as a back-up. 
• Use cash where you can. 
• Don't use Debit cards. 
• Seriously, put your checking account Debit card away. 
• Only use your checking account Debit card in emergency situations. 
• Use Credit cards in place of Debit cards 
• This will require some discipline, but not much more than avoiding that over-draft fee for using a Debit card too much. 
• Don't count on EMV to protect you. 
• EMV (chip-n-dip) provides Authentication, not Encryption. 
• The rise in on-line CC theft is due to EMV. The hackers simply shifted to a different vector (e.g., workstations, servers), using existing attack vectors to skim CC data. 
• Inspect card-insertion devices before you make use of them. 
• Hackers can compromise the Point of Interaction (POI) device with skimmers, or attach in-line devices and get your account information 
• Try to use merchants who have implemented P2PE
• This is difficult for the average person to ascertain, but ask your vendor.
• Encourage them to use only P2PE validated solutions.
• Believe it or not, not every POI device encrypts CC account data.
• Point-2-Point-Encryption is a PCI-SSC standard wherein the account information is encrypted by the POI device (magstripe/dip/NFC reader).
• P2PE equipment is not small, so small-ish ear-phone-like devices generally are not P2PE enabled
• Encryption performed by a Workstation or a Mobile device is NOT P2PE encryption.
• P2PE encryption is ALWAYS performed by the Card Reader (magstripe, dip, or NFC).
• Do not use "public" ATM machines. 
• Use only the ATM machines attached to your bank, with your bank's logo, at your bank's branch. 
• Old or cheap ATM means old tech, which means no magstripe reader encryption 
• Even newer ATM machines may not perform card account information encryption at the reader. 
• Be wary of gas pumps and very old technology at your favorite, In-Real-Life, places. 
• Never use a Debit Card at a gas pump unless absolutely necessary. 
• Gas pumps are expensive to build and replace. They have old tech: usually no encryption at the card reader. 
• Mag-stripe readers that don't do encryption are cheap. 
• They can be connected to windows & Linux machines that can do encryption, or not: perhaps they just use HTTPS to transfer your account information. 
• Connect the dots here. 
• Think twice about buying that item cheap, at that little known, online store. 
• Avoid storing your CC account information online.
• Use auto-pay services provided by your BANK, not the Retailer, Utility, or Service Provider. 
• Avoid storing your CC account information at Utility Companies, local/regional Service providers, and other Retail companies.
• Consider using a LOCAL (not cloud) password safe to keep your account information ready for that I-gotta-have-it-thinga-ma-jig-I-just-succumbed-to-buying. 
• Absent that, consider putting your private account details in an encrypted ZIP file, on an encrypted USB stick that is not connected to your computer until you're ready to use it.
• This is defense in depth 
• The USB is not always attached 
• The USB is encrypted 
• The ZIP file is encrypted (never use original/default PK-Zip encryption!)
• Use AES encryption in ZIP files 
• Don't forget to back up your files. 

Here's what I do

• Day-to-day
• I have one, shared CC account that I and my Wife use. 
• I never use my debit card. 
• Sharing & Encryption 
• We securely share and store our account information using 1Password and cloud filesystem services. 
• Online Activities 
• I allow a few companies I trust to keep my CC information online. 
• I use ApplePay whenever I can.
• When looking for online payment providers, look for wording like this:
• Your card number and identity aren’t shared with the merchant, and your actual card numbers aren’t stored on your device or on our servers.
• My Expectations
• Through normal use (e.g., gas pump, dining, shopping), I expect my CC to be compromised. I don't care. 
• It won't be my fault and either the Merchant or the CC company will bear the cost. 
• I'll use my backup CC in the event my card stolen, overcharged, or is canceled due to fraud. 
• It will be a minor inconvenience.
• How I manage the CC 
• I pay off the usage every couple of weeks. 
• I receive an email from my CC provider every time a charge is made. 
• When I don't recognize a charge, I call the CC company and report fraud. 
• This occurred recently. An online, international charge was made using my Wife's (shared) CC. 
• She got a new CC in a few days, the charge was removed from the account. 

There are probably other things that can be done.  Leave your best practices in the comment section.

Solving the 'no-start' car problem: Engineering Style

Mechanical Engineer:

- It's a broken starter.

Electrical Engineer:

- It's a dead battery.

Chemical Engineer:

- Must be bad gasoline.

Electrical Engineer:

- It's a bad fuse.

Civil Engineer:

- Blow it up and build a new one.

Engineering Manager:

- 30 seconds, three key turns and we still have nothing?

Software Engineer:

- Worked fine in my garage.

Helpdesk Engineer:

- Everyone get out of the car and get back in.

Security Engineer:

<quietly giggling>

Cleaning out Golden Tickets after a successful attack on Active Directory

Disclaimer: this is not my work, it is reproduced from an article posted to Peerlyst.  The original work, which provides more detail, is here and was created by @rootsecdev

If an attack made it into your active directory‍ environment and got a golden ticket‍, there is a specific set of steps you need to take to make sure you've cleaned out the adversary:

1. Disconnect the affected networks. Entirely.
2. Remediate any persistence mechanisms left behind
3. Reset passwords of ALL high privileged access accounts
4. Reset passwords of all VPN access credentials (+other remote access you may have)
5. Change the krbtgt‍ hash using https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51 run in it the order of using first option 1, then option 2 and then option 3: (https://cdn-images-1.medium.com/max/1000/1*Gk48jksjPuThTrPnJNHW-w.png)
6. Wait minimum 10 hours
7. Change the krbtgt hash again using https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51 run in it the order of using first option 1, then option 2 and then option 3: (https://cdn-images-1.medium.com/max/1000/1*Gk48jksjPuThTrPnJNHW-w.png)

VNC + SSH Tunnel: In a Pinch

So you need an encrypted tunnel to a workstation; you have PuTTY, VNC and SSH, but you're hitting a wall somewhere.  Good news: you're in luck - you have the tools you need and the configuration is simple.

Sometimes trying to configure three tools to work in harmony can be a daunting task when you've never performed a similar configuration, when you don't know what to expect, and certainly when you're pressed for time.

What You Will Do, What will Happen

You're going to configure an PuTTY SSH session to an SSH / VNC server in conjunction with a PuTTY SSH tunnel.  You will then log into the remote SSH server using your saved PuTTY session, and using VNC, you'll connect to the localhost PuTTY SSH tunnel.  The tunnel will be used for the encrypted session between your client and the SSH+VNC server.

Configure a PuTTY SSH+tunnel Session

If you don't have PuTTY, get a copy here.

Configure an SSH session for the SSH+VNC server you wish access, then save the configuration:

In this example, the session is saved as"MacTitan (VNC)".  The SSH server name is "MacTitan.local", and the port is the standard ssh port, 22.  I'll refer back to this configuration as your "PuTTY SSH+tunnel" session.

Next, open SSH -> Tunnels and add a configuration for the VNC host, then click "Add".

The "destination" is the SSH host you configured above, using this syntax: hostname:listening_port.

The "Source port" is your localhost host listening port for VNC.  Clicking "Add" makes a configuration available for use, but it's not permanent until you save the session.

Be certain you save this configuration to your freshly minted PuTTY SSH+tunnel session.

Start an SSH Tunnel Server on your SSH+VNC Host

Using your PuTTY SSH+tunnel session, log into your SSH server using your <username> and start an SSH tunnel using the following command:

$ ssh -N -f -L 5901:localhost:5900 <username>@localhost

ssh will prompt you for your password.

Next, verify that the server is running using "ps aux | grep ssh"

If it's not running, try using the "-v" switch to understand where the failure is occurring.

For more information on the SSH command, see here: explainshell.com

PuTTY: Login to SSH Server

Assuming you're already logged in via the previous step, you can skip this (you don't need to log in twice).

Using the PuTTY SSH+Tunnel  session login to the SSH/VNC server.

VNC to localhost

If you don't have VNC, you can download it here.  

Start a VNC session to the localhost (127.0.0.1).  You may specify the port (5900) like this (localhost:5900 or 127.0.0.1:5900), but it is not required.  

And enjoy your encrypted session:

To Do

Configure a solution that does not require one to open a terminal session into the server.

Password Hashing

I have an online account that uses multifactor authentication.  If you're not familiar with multifactor authentication systems, then a brief introduction is in order:

A multifactor authentication system is one that that requires more than one method of authentication, each sourced from independent categories of credentials.  These categories are divided into the following three domains:

1. Something you know
2. Something you have
3. Something you are

Something you know is a password or pass-phrase.
Something you have is a token generating key-fob or a key card with a magnetic stripe.
Something you are is a fingerprint, voice or retinal print.

The first two factors can be easily revoked, the last factor - something you are - cannot be revoked. That's why, along with false positive and false negative rates, something you are should never, ever be used as the primary method of proving identity: it must always be mixed with another factor.

Back to my online account.

I was attempting to log into this account one day when it refused to accept my password.  I reset the password 3 or 4 times - using a strong password each time - and finally called the support desk when I had successfully pulled out the remaining bits of my hair.  They gave me a reset password.  I tried using that password while on the phone with them: no go.

Then they said, 

"Did you also input your token from your authentication app?"

"Why, no.  I did not.  How do I do that?" 

"Enter the password, then follow the password with the authenticator passcode."

So I did just that, and presto: I was authenticated into the system.  Pretty neat.  Until you think about how it could be broken.

How Password Management Should Work

Storing passwords has always an Achilles' heel of Information Security. A lot of developers get it wrong. It's why companies like LinkedIn get pwn'd. In order to do it right, you have to implement several things.

Add some Salt

First, you must always employ a salt. IMO, a salt is at least 128 bits (16 bytes) of cryptographically secure random data. In other words, using srand() and rand() are right out. On Linux'ish systems you must use /dev/random or /dev/urandom (see here regarding the Myths of about /dev/urandom).

Windows has it's own way of providing cryptographically secure random numbers (Google is your friend).

Choose Speed or Memory

And by that I mean, never use SHA[what-ever] to hash your passwords.  Always use one of the following

1. bcrypt - time intensive
2. scrypt - memory intensive
3. PBKDF2 - time intensive

If you use anything other than those functions, you're doing it wrong.

If you don't add unique salts to your password, you're doing it wrong.

If your salt is compiled into your program, you're doing it wrong.

Save the Result

It's really that simple: save the hash and the salt right next to each other if you want to, but you must save the both.  Never save a password, even if you encrypt it with AES.  You must, however, employ proper security controls around the password store.  While encryption is always a preferred control when storing information, there are customary ways to make sure files are available only to the entity that needs them.  Specifically, file ownership and read/write/modify permissions.  On a Linux-ish system, that generally means a unique, hidden folder accessible only by the entity, and a file accessible only by the entity.  E.g.,

$ mkdir  .my_hidden_dir
$ touch  .my_hidden_dir/my_file
$ chown  -R user:group .my_hidden_dir
$ chmod  u=rwx,go-rwx .my_hidden_dir
$ chmod  u=rw,go-rwx .my_hidden_dir/my_file

When the user enters their password, grab the salt, add it to the password, execute your hashing algorithm and compare.  If you get the stored hash, you have the correct password.

How It Could be Done Wrong

Lets recall the facts: my online provider requires me to enter my password and my token at the same time, one appended to the other, like this:

• [password][token]

The problem is this: how does my provider know the length of my password?  In order to calculate the hash of my password, they need the salt and the password.  Since the information is input as one string, then there are only few ways that my password can be extracted from the string:

1. They're saving the length of my password with my password hash
• This is bad.  If the password database is exposed, then my hash, salt and password length will be exposed.  This reduces the time necessary to crack the password since an attacker needs only to create a dictionary of hashes based upon the length of my password - assuming that the attacker also knows the iteration count of the hash algorithm (e.g., the provider is not using SHA[what-ever]). 
2. They're saving my password (not hashed)
• Wrong all the way around, even if it's encrypted.  Don't do it.
3. The token is a fixed length
• A likely possibility.  But this breaks when the token generator changes the length of the token.
4. The password + token is not hashed before it reaches the web server
• This sounds dangerous, but actually the converse is more dangerous:
• If the password is hashed in the client (assuming a browser interface), then the attacker has full knowledge of the hashing algorithm used by the password management system.  Once that system is compromised and the password hashes are exposed, it will be a short order before they're all cracked using a dictionary attack.
• Never hash your passwords in the client

Conclusion

A proper implementation should request the one-time-token from the generator and match that pattern in the string provided by the user.  Where the match begins marks the end of the user password+1.  From there, it's simple string splitting, hashing and comparing.  This solves the problem of variable length tokens from the one-time-token generator.

Doing security correctly is not as easy as it looks or sounds.  We must employ the proper tools to insure our designs and architectures are sound.  As far as my online provider, I can only hope they're using strong hashing algorithms.  But given that they're requiring something I have, it's very, very unlikely that an attacker will randomly provide the correct password+token.

Requirements and Use Cases

Many times, requirements and use cases are not things that the average Joe (with apologies to my friend Joe) believes warrant security attention. But Architecture and Design is where it all begins, it is in that phase of development that requirements and use cases are being developed. If you miss the security boat there, then you've set the Rube Goldberg machine of hack, exploit, pay-the-lawyers, fix and patch, into motion.

The problem is that the Average Developer doesn't really care too much about Secure Design, Threat Modeling and Attacker Stories. That stuff just gets in the way of fun (writing code) and profits (selling code) - though we might like to assert that we don't see much of the profits being six or seven layers deep from the President & CEO. So lets explore the Attacker Story by first understanding exactly what a Use Case represents.

Requirements

The study of Software Requirements is a college-level course in-and-of itself. So I'm not going to spend too much time on the topic except to say this: building in security and constraints through your Software Requirements phase doesn't help a whole lot. If it did, we wouldn't have insecure software and buffer overruns. On top of Software Requirements we must add use cases and attacker stories (or abuse cases). Both of these things inform development and quality engineering. They help development consider the activities and actions of both the user and the attacker. On the QE side, the tools help the testers verify the implementation functions as designed and is resilient to attack.

Use Cases

A use case is a technique that helps us express functional requirements in a developer and tester friendly manner. But a use case is not a substitution for documenting specific requirements. Neither is it intended for all subject-object interactions. A use case should be specific enough to supplement design requirements so that correct design is implemented and sufficient tests are constructed to verify functionality. Use case modeling expresses the intended system behavior for specific actors.

Consider a simple banking application use case for making a transfer:
As a user of the Banking App, I want to transfer funds out of my account into another account in order to meet my personal financial goals.

This use case helps us think about what a specific actor wants to do with a given resource and for a specific purpose.

Abuse Cases (Attacker Stories)

An Attacker Story or Abuse Case exactly like a use case, except it is constructed from the perspective of an attacker. It may be based upon a specific use case, but it also can be based upon well known threat model attributes, such as those associated with STRIDE or DREAD. Using the example above, we can develop an abuse cases as follows:

As an attacker, I can access a user's account and transfer funds to other accounts for the purpose of stealing money.

As an attacker, I cannot steal money by accessing a user's account and transfer money to other accounts.

Just as in the use case, the abuse case causes an attentive developer and tester to ask questions:

• How does the user access the account?
• How do we prevent the attacker from gaining unauthorized access?
• How do we assert that user has permission to transfer funds?
• How do we prevent an attacker who has gained access to an account from stealing money?

Therefore, the Attacker Story helps us express the emergent security requirements from which we can design and implement controls and tests to prove the controls work. In the best situation, each use case should have one or more abuse cases.

We can (and many times should) create diagrams explaining both the use case and the abuse case.  While the example below is patently simple, it does express the idea that we don't want an un-authenticated user performing the same functions as an authenticated user.

Nevertheless, in both instances we consider different aspects of the same usage.  Perhaps one of the first questions we investigate is, "how does an attacker become an authenticated user without proper credentials?"  Perhaps session hijacking is exploited, or perhaps we use a form of multi-factor authentication and the attacker has performed this SIM attack or this one.

Use Case

Abuse Case

In summary,

Software Security is not an afterthought. If you're not considering how your information system can be attacked when you're in the architect and design phases, then you'll be playing catch-up for the entire lifecycle. Security is like a feature: it must be designed into the product and it must be testable. Security is an emergent property of software, just like any other feature or quality.

Secure Development Lifecycle - The Basics

A secure and stable system, whether you're designing a Point of Sale terminal, a Space Shuttle or a Mobile Device Management system, always begins with the development system: not the software. It is the software development system that results in either sound or harmful software. Quality and Security are not things that can be bolted at the end of development or when the vehicle is being deployed.

In the same vein, the absence of prior failure does not provide an indicator of future success. It was precisely this belief that helped doom the Challenger STS-51-L mission:

We have also found that certification criteria used in Flight Readiness Reviews often develop a gradually decreasing strictness. The argument that the same risk was flown before without failure is often accepted as an argument for the safety of accepting it again. Because of this, obvious weaknesses are accepted again and again, sometimes without a sufficiently serious attempt to remedy them, or to delay a flight because of their continued presence.(Rogers Commission, STS-51-L)

This is not to say we do not implement controls in the environment the system is deployed to provide safety and security. Instead, those controls cannot account for or reverse bad planning, design, or implementation.

It is the responsibility of those performing the implementation - of any system - to ensure that the system under design is developed using a Secure Development Lifecycle.

For Software Development, there are six touch-points, each with associated activities, that must be performed to address security requirements:

1. Requirements and Use Cases 
• Abuse Cases / Attacker Stories 
• Security Requirements 
2. Architecture and Design 
• Risk Analysis 
3. Test Plans 
• Risk Analysis 
• Risk-Based Security Tests 
4. Code 
• Code Reviews 
5. Tests and Results 
• Risk Analysis 
• Penetration Testing 
6. Feedback from Consumers (the field, customers) 
• Penetration Testing 
• Security Operations

In future blogs, I'll address each of these topics.

Perl Recursive Directory Search: How-To

Lets face it: recursion can be hard.

But sometimes you just need a quick answer for something that surely has already been cracked.  If that's you, here's your quick answer: find2perl.  Use it. Love it, and get your job done.

If you're looking for a more in depth treatment on recursive algorithms, then you should start with C.  Specifically, here: Lesson 16: Recursion in C

But for the problem at hand, I'll first refer you to our trusty tool called "find" (see WikiPedia).

Typical syntax for the find command could look like the following:

$ find . -name bin -type d -exec echo {} \;

That command will find all directories called 'bin' and print them, as follows:

./.cpan/build/Crypt-RC4-2.02-ptGTQ1/blib/bin
./.cpan/build/Digest-Perl-MD5-1.9-Uenq6s/blib/bin
./.cpan/build/ExtUtils-MakeMaker-7.04-yzvWOc/bin

The -exec switch is not necessary: it's provided here only as an example.

Once you've constructed a find command that fetches the files you're looking for, then you're ready to convert it into a PERL script and begin the process of hacking it into something useful.  Usage is straight forward:

$ find2perl . -name bin -type d -exec echo {} \; > myFindScript.pl

You'll be presented with output like the following.  The rest is up to you.

#! /usr/bin/perl -w
    eval 'exec /usr/bin/perl -S $0 ${1+"$@"}'
        if 0; #$running_under_some_shell

use strict;
use File::Find ();

# Set the variable $File::Find::dont_use_nlink if you're using AFS,
# since AFS cheats.

# for the convenience of &wanted calls, including -eval statements:
use vars qw/*name *dir *prune/;
*name   = *File::Find::name;
*dir    = *File::Find::dir;
*prune  = *File::Find::prune;

sub wanted;
sub doexec ($@);


use Cwd ();
my $cwd = Cwd::cwd();


# Traverse desired filesystems
File::Find::find({wanted => \&wanted}, '.');
exit;


sub wanted {
    my ($dev,$ino,$mode,$nlink,$uid,$gid);

    /^bin\z/s &&
    (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) &&
    -d _ &&
    doexec(0, 'echo','{}');
}


sub doexec ($@) {
    my $ok = shift;
    my @command = @_; # copy so we don't try to s/// aliases to constants
    for my $word (@command)
        { $word =~ s#{}#$name#g }
    if ($ok) {
        my $old = select(STDOUT);
        $| = 1;
        print "@command";
        select($old);
        return 0 unless <STDIN> =~ /^y/;
    }  
    chdir $cwd; #sigh
    system @command;
    chdir $File::Find::dir;
    return !$?;
}