Wanted: Friendly Hackers for the “Bug Bounty Program”

HackerOne started an internet Bug Bounty program with the goal of, “Rewarding friendly hackers who contribute to a more secure internet.”1 The Bounty is sponsored by two industry leaders Facebook and Microsoft that are constantly looking to improve user experience. It has also been rumored that Google is co-sponsoring the project.2

The program identifies different vulnerabilities that have a heightened potential to adversely affect a large number of internet users, after these deficiencies are identified they are brought to the respective program owner and addressed.

“Microsoft and Facebook also assembled a list of 11 open source projects, making specific information on cash rewards available for each,” 3 according to SC Magazine.

The list of 11 open source projects includes: Python, Ruby, PHP and Perl interpreters; the Django, Ruby on Rails and Phabricator development tools and frameworks; the Apache and Nginx Web servers, and the application sandbox mechanisms of Google Chrome, Internet Explorer 10, Adobe Reader and Flash Player.

“The highlighted open source projects were chosen according to how “critical” the projects were to users.” According to Alex Rice who is a product security lead at Facebook told SC Magazine. 3

HackerOne’s reasoning for starting the program; “Some of the most critical vulnerabilities in the internet’s history have been resolved thanks to efforts of researchers fueled entirely by curiosity and altruism.”4

The concept of the program is great and seeing that major companies are backing this project will only help improve the future of the Bug Bounty moving forward. Who knows, programs like this could even turn around some of the stereo types that currently surround hackers?


1.       https://hackerone.com/ibb

2.       http://www.infoworld.com/d/security/microsoft-google-and-facebook-team-new-bug-bounty-program-230396  

3.       http://www.scmagazine.com/facebook-bug-bounty-program-for-internet-will-likely-expand-open-source-focus/article/320236/1/

4.       https://hackerone.com/faq

Hashing vs. Encryption

The hashing and encrypting of sensitive data protects the data from unwanted access by people with ill intentions.  Even though the two algorithms serve the same purpose, they are very different and each are suited for specific forms of protecting your valuable resources.  Knowing these differences will make it easier to verify that you have the correct option in place for the right scenario.



What is Hashing?

Hashing has been used to organize strings of variant lengths into a value that is always the same length – usually smaller.  The important part about hashing is that it is a one way mapping. i.e.you cannot get the original value from the hashed value.  It is, however, possible for multiple input values to hash to the same output value, but the best hash algorithms will eliminate these collisions as much as possible.  This link explains minimizing collisions in more detail.


Proper hashing algorithms will also make it very hard (virtually impossible) to reverse the hash by processing the input multiple times.  MD5 does it 64 times for each 512 bit chunk of data.  The results from each of the 64 iterations are then combined together to create the hash.

If you were to decode the hash, the first item of business would be to separate the hash back into the 64 individual hashings.  Then of course reverse each of the 64 individual units.

“Now, to explain why this is VERY hard, imagine trying to deduce a and b from the following formula: 10 = a + b. There are 10 positive combinations of a and b that can work. Now loop over that a bunch of times: tmp = a + b; a = b; b = tmp. For 64 iterations, you’d have over 10^64 possibilities to try. And that’s just a simple addition where some state is preserved from iteration to iteration. Real hash functions do a lot more than 1 operation (MD5 does about 15 operations on 4 state variables). And since the next iteration depends on the state of the previous and the previous is destroyed in creating the current state, it’s all but impossible to determine the input state that led to a given output state (for each iteration no less). Combine that, with the large number of possibilities involved, and decoding even an MD5 will take a near infinite (but not infinite) amount of resources. So many resources that it’s actually significantly cheaper to brute-force the hash if you have an idea of the size of the input (for smaller inputs) than it is to even try to decode the hash.” 1

One of the ways hackers use to get around the effort required to compute all possible hashes is to use pre-computed rainbow tables (link).  This is where salting the hash comes in handy for the good guys.  There is already an article on our blog about salted hashes here


What is Encrypting?

Encrypting sensitive data hides the true value so it can’t be seen while being stored or transported, but allows for decryption later in time so the value can be viewed and used again by the proper person.  The important piece about an encryption algorithm is that there is always a one to one mapping between the input and the output values.  It is possible for more than one input to generate the same encrypted output, but a proper encryption algorithm won’t let this happen.  The input and output lengths can always vary as opposed to the fixed length hashing output.  There is always a specific way to reverse the encryption by using a well-defined method.  Properly encrypted data cannot be identified as different than noise while hashing is always a consistent format.




Storing the hash of a password works well because the plain text of the password cannot be retrieved from the storage area.  Any password entered by a user is put through the hash function and the resulting hash is compared against the stored one to authenticate the user.


You can also validate input data using a hash function; instead of doing a lengthy compare of two large files, hash both files and if the hashes match, the files are the same.


“The probability of a collision is astronomical for small input sizes (assuming a good hash function). That’s why it’s recommended for passwords. For passwords up to 32 characters, md5 has 4 times the output space. Sha1 has 6 times the output space (about). Sha512 has about 16 times the output space. You don’t really care what the password was, you care if it’s the same as the one that was stored. That’s why you should use hashes for passwords”.1



Encryption of a value is necessary when the plain text of the value will be needed when the item is looked up in storage – if you are storing your bank account numbers, you will need to see the plain text version of them to use them.  The same applies to data that is sent securely from one location to the other and needs to be viewed by the receiving party.



  1. http://stackoverflow.com/questions/4948322/fundamental-difference-between-hashing-and-encryption-algorithms
  2. http://en.wikipedia.org/wiki/Hash_function#Uniformity
  3. http://en.wikipedia.org/wiki/Rainbow_tables

Hacking Cars Wirelessly

You may have noticed the net creeping into more and more of your devices.  It’s certainly common knowledge that computers have been making their way into more and more of our everyday objects: Clothing, glasses, gift cards and cars, but those computers are really only a first step, the next naturally being plugged in to our ever growing network infrastructure.  With wireless connectivity then comes the ability for those objects to communicate with the outside world, and with this being a security blog, you must know where I’m headed.

Whereas computers have been deeply embedded into cars for 30 some-odd years now, it’s only recently that those computers are able to communicate externally.  Now, with Bluetooth and ‘telematics’ (OnStar services) wireless technologies making their way into more and more vehicles, more and more of those vehicles are now prone to remote hack attacks.  What’s truly unsettling is that by hijacking a vehicle via these attacks, the attacker is provided a wide array of integral, safety critical car components to manipulate; from steering, to acceleration, to braking, at the click of a button.

Those interested in seeing the attacks in motion can attend or tune into the Defcon hackers conference this coming weekend, where researchers from security firm IOActive will be demonstrating using a 2010 Toyota Prius and Ford Escape.  Budgeted with an $80,000 grant from DARPA, the researchers have documented everything required to perform the attacks and what may be necessary to make cars more resistant.

As stated in the researchers’ report, “By examining the CAN [controller area networks] on which the ECUs communicate, it is possible to send proprietary messages to the ECUs in order to cause them to take some action, or even completely reprogram the ECU… ECUs are essentially embedded devices, networked together on the CAN bus. Each is powered and has a number of sensors and actuators attached to them”, it’s revealed that the networks in these vehicles makes no attempt to authenticate the incoming messages, which may or may not contain directives that change the vehicles behavior.  This way, the vehicles computers essentially take orders from anyone, regardless of the origin of the signal.

Proper authentication is undoubtedly integral to maintaining safety of all kinds when dealing with network connectivity.


Read more

Shadow Passwords

Why would any self-respecting password want or even need to have a shadow?  The short answer is quite simple and is because a password is usually not secure enough on its own from being guessed by brute force.

Passwords are usually kept in a hashed state in a table available to anyone.  On the Unix platform this is the “/etc/passwd” file.

“To test a password, a program hashes the given password with the same “key” (salt) that was used to hash the password stored in the /etc/passwd file (the salt is always given as the first two characters of the password). Because the hashed passwords are not “decryptable”, authentication takes place by comparison. If the /etc/passwd/ file password matches the hashed login password, the user is granted access.” 1

This approach is reasonably secure but, there are ways to “crack” the passwords such as with a “dictionary attack”.  A dictionary attack takes all possible password variations, hashes each of them and compares the hashed value until one that matches the hashing in the /etc/passwd/ file is found.

“For a good password, these types of attacks can take a long time (since, on most systems, there are literally over 10,000 trillion possible passwords). However, many users choose common words, combinations of common words, or variants on personal data for their passwords. These are easily cracked, often within a few hours.” 1

This weakness can be reduced by using an additional file known as the shadow password file.

“The actual hashed passwords, along with expiration data, are kept in a file that can only be read or used by root (the Unix Administrator account). Processes which require access to the shadow password file must be owned by root or be granted root level permissions before access is obtained, which provides much greater security against password snooping.” 1

Simply put, the passwords from the /etc/passwd file are moved to another file which is only accessible by an administrator, usually /etc/shadow.  This protected file is the “shadow password” file.  If a would be attacker can no longer access the hashed passwords, the brute force “guessing” cannot happen.


  1. http://kb.iu.edu/data/aezz.html
  2. http://searchsecurity.techtarget.com/definition/shadow-password-file


Yahoo’s Risky Plans to Release Inactive Accounts (Update)

Two weeks ago we reported on Yahoo’s latest and frankly scary plans to release the plethora of inactive accounts that exist under their services so that others may acquire them.  Why would you want them? Well, now’s your chance to grab that elegant ‘albert@yahoo.com’ name you missed out on, and abandon that ugly, hard to remember alternative you ended up with, i.e. ‘albert2018471’.  Should you though?

This situation has Yahoo walking a fine line between convenience and insecurity, and although they’ve since described more about their strategy, and insist it will all be done safely, it’s a convoluted one, with possibly still some loose ends.

Starting last Monday, the rush for recycled Yahoo IDs had begun.  Users can now go to wishlist.yahoo.com and request up to five account names they would like to own, which will then be requited on a first come, first serve basis.  For now, only one recycled account is available per user.  As we’d previously reported, the lucky winners of available addresses will then receive them on August 14th if they still wish to claim them.

Undoubtedly fueled by the widespread criticism of their move to redistribute previously used accounts, Yahoo also released statements on Monday detailing their methods to prevent them from being used as an aid in identity theft.  In collaboration with Facebook, Yahoo announced, they have developed a special email header field called ‘Require-Recipient-Valid-Since’, which will serve as a way to validate whether the would-be receiver of that message is a previous, or current account holder.

Detailed in a blog post, Yahoo describes how the email header field works:

If a Facebook user with a Yahoo! email account submits a request to reset their password, Facebook would add the Require-Recipient-Valid-Since header to the reset email, and the new header would signal to Yahoo! to check the age of the account before delivering the mail. Facebook users typically confirm their email when they sign up for the service or add new emails to their account, and if the “last confirmed” date that Facebook specifies in the Require-Recipient-Valid-Since header is before the date of the new Yahoo! username ownership, then the email will not be delivered and will instead bounce back to Facebook, who will then contact the user by other means.

They go on to state that Facebook will be implementing this as well, and that the idea is a new standard to be published with the IETF (Internet Engineering Task Force).

Is their revamped approach one that makes this situation a safe one? It certainly does a good job of patching up some security holes, but I can’t imagine the solution is all-encompassing of the many ways to exploit this event.  For example, not every social media or financial website (though, they should,) maintains a record of the ‘last confirmed’ usage date of its registered accounts.

Email is, these days, largely considered a form of credentials and is used on countless sites as a mechanism to in some way authenticate with that site.  That said, is this a responsible move on Yahoo’s part, regardless of how they try and secure it? Time will tell.

Your Password is Obsolete

Your password is obsolete, or so says this infographic we’d like to share, with data compiled by Backroundcheck.org earlier year.  We’re certainly no strangers to this topic, and had even posted our own take on the subject even earlier this year in January, titled The Death of the String Password.  Though, we certainly can’t take credit for the idea either, as Bill Gates was quoted as predicting similar things as early as the RSA Security conference in 2004.  Gates had said that “There is no doubt that over time, people are going to rely less and less on passwords” when speaking about the oncoming popularity of two-factor authentication technologies.

Says the infographic: “Some say 2012 may have been the year the password broke.  With password leaks and dumps becoming common occurrences our lives are simply becoming too easy to crack.  The string of characters you use as a password can’t protect you anymore.”  And they’re right, especially with the onset of cloud computing and having dozens of online accounts – it’s a wonder the arrays of difficult to remember mixes of captials, symbols and numbers have lasted us this long in the first place.  It’s simply impractical, and increasingly unsafe.

Whereas a series of replacements for the password have been suggested over the years, from picture passwords, to ‘fastwords’ and biometrics, it would seem that two-factor with (hardware or software) tokens have for now grabbed the attention of most organizations hoping to remain secure and progressive with their authentication systems.  As we’ve also previously reported, Google, Twitter, and other major enterprises have already been in the process of introducing (and hoping to enforce as the default) two-factor authentication options that employ OTPs and TOTPs generating authenticators.

Have a look at the infographic and see for yourself just why your password isn’t protecting you anymore.

Possible First Password Breach

Have you ever wondered how long passwords have been around and when the first time it was discovered that they are not as secure as once first thought?

Some say the computer password was first invented at MIT in the mid-1960s.  Further back than that, Shakespeare started his famous Hamlet play off with Barnardo identifying himself to Francisco with the phrase “Long live the King”.

Fast forward 300+ years back to MIT and we understand that passwords were perhaps first used by the massive time-sharing computer called CTSS to control access.

According to Fernando Corbató (the man who led the CTSS project), even though the MIT computer hackers were breaking new ground with much of what they did, passwords were pretty much a no-brainer. “The key problem was that we were setting up multiple terminals which were to be used by multiple persons but with each person having his own private set of files.  Putting a password on for each individual user as a lock seemed like a very straightforward solution.”1

In 1962, it is believed that perhaps the first data breach occurred on this now ancient CTSS project.  Alan Scherr wanted a way to increase his allotted time on the CTSS.  This is how he remembers it:

“There was a way to request files to be printed offline by submitting a punched card,” he remembered in a pamphlet written last year to commemorate the invention of the CTSS. “Late one Friday night, I submitted a request to print the password files and very early Saturday morning went to the file cabinet where printouts were placed and took the listing.”1  Imagine that happening today.  Not with all the gyrations and fancy storage today’s passwords are subject to.  We have come a long way since 1960.

“To spread the guilt around, Scherr then handed the passwords over to other users.  One of them — J.C.R. Licklieder — promptly started logging into the account of the computer lab’s director Robert Fano, and leaving “taunting messages” behind.”1

Scherr left MIT in May 1965 to take a job at IBM, but 25 years later he confessed to Professor Fano in person. “He assured me that my Ph.D. would not be revoked.”1

It’s always interesting to pick your head up once in a while and take a look back at where we have come from.  If the trail isn’t too windy and hilly, we can see quite a ways behind us.  Or in this case how well history was documented and preserved.


  1. http://www.wired.com/wiredenterprise/2012/01/computer-password/

What are Picture Passwords?

Picture passwords are quite a break from the normal password consisting of alpha-numeric and symbols that are typed into an authentication dialogue.  There are no lengthy and complicated sequences of characters to memorize.   Instead, a user looks at a picture of their choice and touches the picture with patterns and gestures they setup themselves initially.  Logging in every morning by touching a picture of your favorite person, thing or action doesn’t sound nearly as daunting as memorizing and typing a traditional password.  Here are some thoughts on what others are saying about this relatively new security technology.

“By using one of your own photos from your computer on a touchscreen system, Picture Password prompts users to set up three gestures users can draw with their finger, combining a tap, a line drawn, or a circle drawn. After creating the specific combination of user-determined drawn patterns, a password is set requiring only a fingertip and no typed passwords which Microsoft says is exponentially more secure.”1       

“You can use a picture password in Windows 8 and Windows RT, so that even signing in to your PC is more personal. Because you choose the picture and the shapes you draw on it, the combinations are infinite—a picture password is actually more secure from hackers than a traditional password. You can draw a picture password directly on a touchscreen with your finger, or you can use a mouse to draw your shapes.”2

“Picture Password Lockscreen allows you to unlock your phone by drawing gestures such as points, lines, and circles on your chosen images. It frees users from the traditional and less secure unlock methods because there are close to an infinite number of combination of gestures. It provides an effective layer of protection against the two most common methods of illegal access gaining to a device- brute-force password hacking and shoulder-surfing. Forget PIN codes or patterns, you can now draw points, lines, and/or circles to unlock your phone.”3

Windows 8 on a touch screen device supports picture passwords as do the iPhone, Blackberry and other popular hand held devices.


How usable is it?

Time will tell for sure, but at first thought, touching a screen in a pattern that only you know does sound like it would be very usable.  Here is the introduction to a research paper that believes and tries to verify the same opinion:

“Users gain access to cash, confidential information and services at Automated Teller Machines (ATMs) via an authentication process involving a Personal Identification Number (PIN). These users frequently have many different PINs, and fail to remember them without recourse to insecure behaviours. This is not a failing of users. It is a usability failing in the ATM authentication mechanism. This paper describes research executed to evaluate whether users find multiple graphical passwords more memorable than multiple PINs. The research also investigates the success of two memory augmentation strategies in increasing memorability of graphical passwords. The results demonstrate that multiple graphical passwords are substantially more effective than multiple PIN numbers. Memorability is further improved by the use of mnemonics to aid their recall. This study will be of interest to HCI practitioners and information security researchers exploring approaches to usable security. Author Keywords Usable security, user authentication, graphical passwords.”6


How secure is it?

As with all security implementations, the technology is only as secure as the way they are used.  Picking a random picture that shows nothing about your life or personality might make it harder for an attacker to guess your password.  Definitely coming up with patterns and gestures that are not intuitive, but easy for yourself to remember will also make using picture passwords secure.

People have plenty of pros and cons to wave at this topic.  Here are just a few:


“Potential weakness: predictable passwords. I expect the primary weakness is likely to be that users choose a “picture password” that is guessable or predictable. If the user chooses a predictable set of locations/gestures, someone may be able to guess the “picture password”.”4

“Because human beings live and interact in an environment where the sense of sight is predominant for most activities, our brains are capable of processing and storing large amounts of graphical information with ease. While we may find it very hard to remember a string of fifty characters, we are able easily to remember faces of people, places we visited, and things we have seen. These graphical data represent millions of bytes of information and thus provide large password spaces. Thus, graphical password schemes provide a way of making more human-friendly passwords while increasing the level of security.”5



  1. http://agbeat.com/social-media/evolution-of-the-password-algorithm-uses-pictures-not-typed-words/
  2. http://windows.microsoft.com/en-us/windows-8/picture-passwords#1TC=t1
  3. https://play.google.com/store/apps/details?id=com.TwinBlade.PicturePassword&hl=en
  4. http://security.stackexchange.com/questions/20228/how-secure-is-windows-8s-picture-password-login
  5. http://rutgersscholar.rutgers.edu/volume04/sobrbirg/sobrbirg.htm
  6. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=


State College Tightens Security

Among the plethora of other organizations we blog about strengthening their cybersecurity, Colleges are too under attack, and are so taking action to ensure their networks are properly protected.  Last month, USA Today reported that Greg Eller, the chief information officer at Northwest Florida State College is doing just that.  Following a data breach in which a hacker took advantage of mistakes made during a server upgrade last year, Eller’s now interested in upgrading their environment in order to protect the personal information stored on their systems.  Among the personal information compromised in the attack were phone numbers, addresses, and even social security numbers of a large number of students.

Following the incident, NWF State College had hired the expertise of Digital Defense Inc, which now performs regular safety checks on the school’s systems, as well as provides education on network vulnerabilities.  Speaking from experience, Eller now suggests other school administrators educate themselves on network defense.  “There are bad guys out there trying to get in,” he says, “The best thing we can do is train ourselves and educate ourselves about them.”

Other schools are already well aware of the importance of this type of education.  The Polytechnic University of New York has offered a masters degree in cybersecurity for around 10 years, intended to cover these exact sorts of situations.  In addition, they also hold a “Cyber Security Awareness Week Capture the Flag: Application Security Challenge” competition in which entrants manage to uncover vulnerabilities in a network system.  Along with Polytech, Penn State, and University of Maryland also offer programs of this kind.

The theme continues to ring true with these organizations: Awareness is key when it comes to protecting our virtual data.

Read More

 Education Link Banner

Cross-Site Request Forgery

What is Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery is defined as an application on a web server being left vulnerable to background requests from otherwise unauthorized users.  Simply put, a well-meaning user unknowingly executes a malicious request from one web site, while logged into the other web site.  The site they are logged into is the location of the cyber-crime and the other web site is the malicious site that presents the harmful request.

To further understand how CSRF can affect you, we will take a look at a common online bank account example.

Let’s say you have an online account at your favorite bank and you have logged into the bank’s web site because you want to check your account balances before you leave for your Winter vacation.  Before you get a chance to check your balances and logout of the bank’s web site, you notice an email from your travel agent and you leave your browser (still logged into the bank web site).  After you read the travel agent email, you decide to check other emails.  One email rather catches your eye and you want to learn more about the content, so you click on the link in the email that takes you to the site.  Well, as good as the site looks, in the background it has been hard coded to send a fund transfer request that moves money from your account to the account of a Cyber Bad Person within the bank that you just happened to be logged into.  Because you are logged in, the fund transfer request is not challenged and the swindler has managed to transfer your money to their account without you knowing that you did it.

How to Exploit a CSRF Vulnerability

A bank web-site is configured to accept requests that are sent to a specific URL with parameters to supply the data for the requested transaction.  For example, a request sent to the onlinetransfer URL with parameter values for Account, Routing and Amount will perform a fund transfer from the Account to the Routing account for the specified Amount.  In addition to the request, a session identifier stored in a cookie is also sent with the request to identify the request as coming from an authenticated bank user.  A would be “Bad Person” learns about this request syntax and wonders if there is a way to get a bank customer to execute this transfer fund request to move money from the unsuspecting victim’s account to their own account.  They would create their own web page that executes the transfer request when their page is loaded.  Of course the event would only take place if the user was also authenticated to the bank’s web site.  The attacker sends out intriguing emails to 100s of thousands of people in the hopes that some of them would be curious enough to accept the invitation to visit the site.  When already logged in user does access the “bad” site and cause the malicious request to be sent, the session cookie verifying the authenticity of the user is also sent so the bank doesn’t challenge the request and makes the transfer.  To summarize, there are three items that need to be in place for a CSRF attack to take place:

  1. Victim must be logged into the target site to be attacked
  2. The target site does not perform re-authentication before each sensitive transaction
  3. User opens the malicious web-site to allow the link to be sent to the bank

How to protect against CSRF

Begin by searching the web application for functionality that could lead to an unwanted malicious action.  Next determine all of the parameters needed for the action to succeed and decide if an attacker can easily determine or guess that proper values.  If so, this is a CSRF vulnerability.

The easiest solution that will take care of most attack attempts is to require and sensitive transactions to be initiated through a POST request as opposed to a GET request.  The POST method is much more difficult (but not impossible) to breach with a CSRF attack.  Also make it as difficult as possible for an attacker to learn what the request is supposed to look like.

In addition:

  • Require re-authentication before any sensitive transaction is completed
  • Require out-of-band confirmation – user has to respond to a cell phone text message to authorize the transaction
  • User transaction specific nonces

How nonces help – when a user wants to make a money transfer they click on a link, prior to rendering this page, the web app generates a cryptographically random number (nonce) and stores it in the server side session as well as in the form being used to transfer money as a hidden field.  The user then fills out the routing number, account and transfer amount and when the transfer request is submitted to the server, the nonce from the hidden field is also submitted.  Prior to completing the money transfer, the server application will compare the delivered nonce to the one stored in the user’s server side session.  If they match, the transaction is allowed.  Before the use of the nonce, the attacker was easily able to populate the parameters of the transfer request being sent.  Considering that the nonce is only created after the login and before the transfer request, it would be extremely difficult for an attacker to acquire the nonce.  Particularly if the attack scripting has been setup to automatically run when the user clicks the link and the attacker is not involved.