Monday, 21 March 2016

GOOGLE BUG : Anyone can be added into google hall of fame

Hi

I recently discovered one interesting bug at google ,anyone can be added to google hall of fame..

Dont you believe it,yes its real


Bug reproducing steps :

1)sigin into gmail
2)Goto https://bughunter.withgoogle.com/
3)Create profile

4) Note : As per google's link only valid bugs will qualify and you would be listed at hall of fame based upon the bugs which u created

5)Now after creating profile click on hall of fame


within minutes of time you would be listed at "Google Hall of Fame"



BuG Timeline :

FEb 29,2016 : Bug sent to google

Mar 1,2016 : Forwarded to internal team

Mar 10,2016 : Google Team denied its not a bug

Mar 10,2016: Requested public Disclosure

Mar 10,2016 : disclosed publicly

Monday, 29 February 2016

Information disclosure & Source code disclosure by Google

Yep,You read it right

Friday google bug bounty page got collapsed and it revealed the source code location of google

While i was trying to create a google vulnerability researcher profile i thought to check for validations,while i was checked for some basic level validations,the page got crashed and revealed its source code








The above image was the proof for which the information was disclosed.Google immediately patched this issue


Vulnerablity TImeline :

Bug found on google : Friday Feb 26,2016
Bug Patched by google : Friday Feb 27,2016
Requested for disclosure

Closure of bug and the bug filed as duplicate : Feb 29,2016

Although i found the bug ,its sad that someone filed before me,The real credits goes to the reporters who reported the bug first.

Saturday, 28 November 2015

Troll Pentest Lab walkthrough

Code name: tr0ll
Webpage: http://overflowsecurity.com/?p=70
VM download: http://download.vulnhub.com/tr0ll/Tr0ll.rar
Challange: hack your way into the system and get root
First of all and just after booting our victim’s box, we start by searching tr0ll on the network.
# netdiscover
1
As our victim VM is running under VirtualBox, we can find its ip easily, we just have to look at the MAC Vendor, it will be CADMUS COMPUTER SYSTEMS.
Now we got our victim’s IP we will use nmap to scan for open ports and interesting information
# nmap -Pn -A -p- 192.168.11.8
2
Nice, ports 21, 22 and 80 open. And according to the output of nmap, there’s an ftp server running on port 21 with anonymous login enabled!
# ftp 192.168.11.8
3
We successfully logged into the ftp server, and after checking our permissions, the only thing we can do here is downloading the lol.pcap file
# get lol.pcap
lol.pcap looks like a wireshark capture file. Let’s use wireshark see what’s inside
5
The capture file seems to be a “conversation” between an ftp client and an ftp server. But if we look it closely we can see an interesting file out there, secret_stuff.txt. As we just saw that file doesn’t seem to be inside the ftp server right now. We can use wireshark to read it’s content
6
“we almost found the sup3rs3cr3tdirlol”
Well, let’s keep that and go scan our next service. Next step will be looking inside the web server. We start by just browsing it
7
Nothing more than the expected, no sensitive information found. We will use nikto to look for hidden directories
# nikto -h http://192.168.11.8
8
After running the scan we found the “/secret/” dir. And if we browse it..
9
Nothing new… just more trolling. N0w’s when the thinkin’ begins. After few minutes I reminded the sup3rs3cr3tdirlol… and when I looked at that dir in the browser
10
Nice, that’s actually a directory on the web server. That directory contains a file, we will download it.
11
After a few tries, we realized that the file is an executable. If we run that executable we can get a memory address. Following the same logic we used with the sup3rs3cr3tdirlol, let’s put it in the browser one more time.
12
Nice, now let’s look inside that directories
13
The first seems to contain a list of users and the second a password. We can try to perform a dictionary based attack against ftp and ssh services on our target marchine.
After few minutes banging my head against the wall, I realized  that the ssh username was “overflow” and its password was “Pass.txt”(trolled again). So we can log into the system with these credentials.
14
Nice, we are in. Now we can look for suid files or weaknesses in kernel
16
But after about 2 minutes inside…
15
Uh.. something or someone killed our connection. What could it be? After a quick analysis we can see that it happens every 2 minutes. Every 2 minutes? Can it be a cron task?? Let’s see
17
We can’t actually see or edit crontab but we can read /var/log/cronlog and that will give some interesting info
18
Nice, cron is running a python script called cleaner every 2 minutes. We can use the find command to search for that file
# find / -name ‘cleaner.py’ 2>/dev/null
19
Now let’s read the file
20
What that file does is delete all the content in /tmp everytime it’s called.
21
But that’s executed by the user root! Thinking the same? That could be a great way of doing our privilege escalation!
For the next trick we will need to start our netcat listener on port 9988
22
Then and after editing our “perl-reverse-shell.pl” we will download it in the /tmp dir on the target machine
23
And finally, we will edit cleaner.py like this:
24
Now every 2 minutes, our victim will send a root shell to 9988 on our box B-). We can go to the fridge, grab a beer and wait for a shell
25

Wednesday, 7 October 2015

Don’t throw away your old Boarding Pass, it may contain personal information

 Did you have habit of throwing your boarding pass?read it

After finishing your trip, the boarding pass becomes useless, but does that mean that you should throw it in the garbage? Certainly not.
Have you ever thought about what information is contained inside a barcode? No ?
The popular investigator Brian Krebs has published an interesting post on the topic explaining that a Boarding Pass Barcode contains a lot of data.
Airlines use the boarding pass barcode for every single boarding pass, but what happen if someone tries to read the information it contains?
Krebs reported the attempt made by one of its readers, named Cory, who saw a friend posting his boarding pass on Facebook so decided to analyze it.
boarding pass barcode 2
“I found a website that could decode the data and instantly had lots of info about his trip,” said Cory,  “Besides his name, frequent flyer number and other [personally identifiable information], I was able to get his record locator (a.k.a. “record key” for the Lufthansa flight he was taking that day,” “I then proceeded to Lufthansa’s website and using his last name (which was encoded in the barcode) and the record locator was able to get access to his entire account. Not only could I see this one flight, but I could see ANY future flights that were booked to his frequent flyer number from the Star Alliance.”
It’s frightening what someone could do with this information, I used the barcode reader website myself to read an old boarding pass barcode, and the information I could get.
The boarding pass barcodes are widely available for years, the International Air Transport Association (IATA) published a details document  on how the barcode standards have been implemented by the organizations on the industry.
Coming back to Cory’s story, he was able to use the info available in the barcode to enter in Lufthansa website site and access his friend’s phone number, the name of the person who did the booking, and see future flights connected to the frequent flyer account.
What do you think about the possibility to conduct a targeted attack with this data? For example an attacker can send a spear phishing email to the victim reporting information on his flights.
The situation goes worse if we consider that accessing the list of future flights he is able to cancel them or change seats.
An attacker could also reset the PIN number associated with Star Alliance frequent flyer account, in the case of Cory, he tried to use the “Forgot Pin” reset and his friend question was, “What is your Mother’s maiden name?” An information like this, it’s not that difficult to extract and probably can be found in social media.
This is just an example of what can be done with a barcode, and the amount of information it can be extracted. Often people consider that the information revealed is harmless, but its because they don’t think like an criminal.
“Interested in learning what’s in your boarding pass barcode? Take a picture of the barcode with your phone, and upload it to this siteThis blog on the same topic from several years back includes some helpful hints on how to decode the various information fields that get dumped by the barcode reader.” States Brian Krebs.
My advice to our dear reader are:
  • Do not leave your old boarding pass in the airplane
  • Avoid putting the boarding pass in the garbage in one piece
  • Don’t publish the boarding pass in social media

What’s contained in a boarding pass barcode?

Anyone who has flown within the past few years would have seen the now ubiquitous barcode on the boarding pass that’s scanned upon boarding the aircraft.
Over the years I have seen many people post images of these boarding passes online, often while reviewing new technologies such as mobile or web check-in. In most cases any personally identifiable plain-text information has been obfuscated yet the barcode has been left intact.
Eventually curiosity got the better of me and I decided to find out more information on the barcode standard, and the information contained within them.

History of the barcode

In 2005 the IATA (International Air Transport Association) commenced a five year project to deploy Bar Coded Boarding Passes (BCBP) across its member airlines to eliminate magnetic boarding passes. This change would allow airlines to use cheaper boarding pass stock, and even enable technologies such as web and mobile check-in – an advancement estimated to save the industry US$1.5bn annually.

What information do they contain?

When writing this article I sat out collecting various boarding pass barcodes both from my own archived web check-in and other boarding passes found on the Internet.
Using freely available software utilities, I decoded the barcodes and had a look to see what’s there. Here’s an example from a Qantas flight of mine taken last month (decoded from the barcode on the web check-in document):
That information translates to:
  • M1: Format code ‘M’ and 1 leg on the boarding pass.
  • EWING/SHAUN MR: My name.
  • 1A11A1: My booking reference.
  • BNESYDQF: Flying from BNE (Brisbane) to SYD (Sydney) on QF (Qantas).
  • 551: Flight number 551.
  • 107: The Julian date. In this case 107 is April 17.
  • Y: Cabin – Economy in this case. Others including F (First) and J (Business).
  • 26J: My seat.
  • 37: My sequence number. In this case I was the 37th person to check-in.
  • 00: Field size of airline specific data message. 00 as there isn’t any.
In this instance, Qantas are using the minimum data fields as required by the IATA BCBP standard, but what about other boarding pass types?
The next step was to try a real boarding pass issued at the airport.
There’s more information in this boarding pass barcode, which is as follows:
  • M1: Format code ‘M’ and 1 leg on the boarding pass.
  • EWING/SHAUN: My name.
  • E1AAAAA: Electronic ticket indicator and my booking reference.
  • SYDBNEQF: Flying from SYD (Sydney) to BNE (Brisbane) on QF (Qantas).
  • 0524: Flight number 524.
  • 106: The Julian date. In this case 106 is April 16.
  • Y: Cabin – Economy in this case. Others including F (First) and J (Business).
  • 23A: My seat.
  • 0073: My sequence number. In this case I was the 73rd person to check-in.
  • 3: My “passenger status”.
  • 59: There is a various size field. This is the size
  • >: Beginning of the version number
  • 2: The version number.
  • 18: Field size of another variable field.
  • 0: My check-in source.
  • B: Airline designator of boarding pass issuer.
  • 2: Another variable size field.
  • 9: Airline code.
  • 0: International document verification. ’0′ as I presume is not applicable.
  • QF: The airline my frequent flyer account is with.
  • 1245678: My frequent flyer number.
  • 128: Airline specific data.
After this I checked an iPhone boarding pass. This contains the same information as on an airport issued boarding pass.

What could you do?

Most of the information contained within the boarding pass is fairly mundane, and the main point to this exercise is – if you’re going to post an image of your boarding pass online and obfuscate your name – also obfuscate the barcode.
The booking reference is however contained within the barcode and someone could use that to manipulate your booking (if you have more flights to go).

Who is Eddy Chiu?

Qantas have an example web boarding pass on their web site for “FYSH/WILLIAM MR” – a name frequently seen on the sample Qantas cards and other literature.
Intriguingly the barcode on this boarding pass doesn’t match up with the details, and instead shows:
While Mr Chiu is on the same flight as on the boarding pass, he is not sitting in the same seat as Mr Fysh yet shares the same sequence number.
I suspect an easter egg or “calling card” from a developer.

Source : securityaffairs,shaun.net

 

Tuesday, 6 October 2015

Headphone checklist : Tech 101

Source : Tech101 ndtv gadgets

Buying headphones can be daunting. Here are some of the commonly used terms you should know.
Whether it's the cheap plastic pair that comes bundled with your smartphone or the big expensive cans with a giant 'b' on the side, we've all used headphones at some point of time. Getting the sound right can make all the difference between a boring bus ride and an emotional journey. But there's more to headphones than what you see.There's a lot of science and engineering that goes into making a pair of headphones sound a particular way. The sound can be tuned in an infinite number of ways, and enjoying the audio experience is more about matching a pair of headphones to the music you're used to listening to, rather than simply picking by brand or looks.
Our guide will help you get a better understanding of what to look for in headphones, and how to make an informed choice when you're actually shopping for a pair. In case you're confused by any of the terms used, jump down to check out our jargon buster. And in the following weeks, we will even help you pick a pair depending upon how much you are looking to spend.
headphones101_main_cc0.jpgTypes of headphones
In-Ears
Also known as IEMs (In-Ear Monitors), in-ear headphones are the smallest and most portable of all the different kinds. Each earbud fits into your ear canal and is powered by small drivers (see below), usually 8-10mm in size. It can be quickly and easily wrapped and stored, which makes it ideal for use when commuting and traveling.
rock_jaw_kommand_filters_headphones101_ndtv.jpg
Pros: Thanks to the small size and light weight, these in-ears are usually comfortable to wear for hours on end.
Cons: Many users do not like the invasive nature of the fit and prefer to use larger on-ear or over-ear headphones.
On-Ears
Also known as supra-aural headphones, on-ears literally sit on your ears, and are therefore much bigger than in-ears. This style of headphones uses larger driver casings, along with a headband that keeps the ear cups in place securely on your ears. Typically, on-ears headsets use 30-40mm drivers.
vmoda_xs_folded_headphones101_ndtv.jpgPros: Typically more comfortable than in-ears for short periods use, can usually be folded up to pack away when not in use.
Cons: Not as portable as in-ears. Since the ear cups sit atop your ears, may not be too comfortable over long hours of use.
Over-Ears
Also known as around-ears and circum-aural headphones, over-ears are the largest and often the most comfortable kind of headphones. Like on-ears, over-ears have large driver casings and a headband, but the ear cups wrap completely around your ears, rather than resting on them. Because of the large size of the casing, the drivers can be much larger at 45mm and above, which allows for a louder and more detailed sound signature.
audio-technica_ath-m50x_headphones101_ndtv.jpgPros: Usually louder and having a more detailed sound signature. It's also the most comfortable kind of headphones, and even offers passive sound-isolation by completely enveloping your ears.
Cons: Usually the least portable, over-ears are more suited for home or office use.
Specialised Headphones
Noise Cancelling
These headphones work on active noise cancelling technology, where certain sounds are drowned out to offer peace and quiet to the listener. Active noise cancelling headphones use small microphones that pick up on outside noise, and produce noise in the opposite frequency, to cancel out the outside sound. The technology does not work with sounds that vary too much, as the microphone cannot quickly pick up and adjust to different frequencies. Instead, noise cancelling headphones are useful in drowning out regular droning sounds, such as airplane engines, factory machinery, air-conditioner hum and other such uniform frequency sounds.
bose_qc25_headphones101.jpgPros: Good for some peace and quiet in factories, airplanes and noisy environments.
Cons: Noise cancelling requires additional power, so charging/batteries will be needed. Additionally, noise-cancelling technology only works with certain kinds of sounds and cannot block out all sound entirely.
Gaming
Gaming headphones are designed to be used when playing video games computers, consoles or portable devices, to enhance the in-game audio experience. Some, such as the Steelseries Siberia Elite Prism, are designed to provide a virtual surround sound experience, while others like the Razer Tiamat provide a true 7.1 channel surround experience. This helps gamers identify the direction of the audio. For example, in first person shooters, a good headset will let you identify which direction the enemy is firing at you from. These headphones are usually tuned to enhance dialogue and sound effects, and also have powerful microphones for multiplayer voice chat.
steelseries_siberia_elite_prism_headphones101_ndtv.jpgPros: Gaming headphones provide for an excellent surround sound effect, and are tuned for picking up direction and detail in the sound.
Cons: Usually not good enough to listen to music, gaming headphones are too specific with regards to their usability.
Wireless
These headphones are free of cords and cables, and can be used comfortably without worrying about cable length and tangling. Wireless headphones usually work on one of three major transmission technologies: radio frequency, infrared and Bluetooth. The first two require a dedicated base unit which connects to the source device and transmits the frequency to the headphones, while the third uses the popular Bluetooth technology and can be paired wirelessly with a wide range of smartphones, tablets and computers. RF headphones usually work over larger distances, while infrared headphones rely on line-of-sight, and Bluetooth has a 30m range limit in most cases.
jabra_sport_pulse_headphones101_ndtv.jpgPros: Better portability and more suitable for outdoor use. Also useful for home use when the source device is placed at a large distance, such as when watching TV or listening to music in the living room.
Cons: Sound quality is usually not as good as wired headphones. Range issues and battery life can also create problems in the sound and listening experience.
These are the main types of headphones you'll be looking at in the market, but if you're confused by some of the jargon you come across in the shops, don't worry. There are a few basic terms you should know about, and you can probably ignore the rest. You'll find most of these mentioned on e-commerce websites, or on the box of the set you're buying.
Headphone Jargon
Drivers
The core components of any headphones, the drivers are used to convert the electrical signal fed to the headphones into an audible sound signal that can be perceived by the human ear. There are various types of drivers used in headphones, including the most commonly used moving coil (dynamic) drivers, balanced armature drivers, planar magnetic drivers and electrostatic drivers, among others. They use different technologies to power the sound, with some technologies offering better, more powerful sound than others. Dynamic drivers are used in all kinds of headphones, balanced armature drivers are general used in in-ear headphones due to the small size, while planar magnetic and electrostatic drivers are the largest and are usually used in built-for-home over-ear headphones.
audeze_lcd_lcd3plugs_headphones101_ndtv.jpgSome headphones, known as hybrids, use a combination of two drivers (most commonly a combination of dynamic and balanced armature drivers). Generally speaking, bigger drivers don't necessarily mean better as there are other factors as well, but they are a contributing factor, particularly for bass. However, it's best to audition headphones before buying, or read reviews to make sure the product is suited to you. Typically, earphones like the ones bundled with your phone will be around 15mm, while over-ear sets will be around 30-50mm.
Closed- and open-back
Headphones can be either closed or open at the back of the driver enclosure. Since a driver fires both into and away from your ear, an open-back headset will allow the sound to escape outside, while a closed-back headset will block the exit of the outward sound. There are pros and cons to both.
Closed-back headphones prevent others from listening to what you're listening to and are therefore more suited for public places as opposed to open-back headphones which leak sound and are perceived as inconsiderate to use in public. However, open-back headphones (like the ones pictured below) have a much more open sound, giving a more comfortable and realistic listening experience, while closed-back headphones sound more 'in-your-head'. Suitability depends on the purpose for which you need the headphones, and auditioning or reading reviews is recommended.
audeze_lcd_both_headphones101_ndtv.jpgFrequency response
The frequency response range of headphones denotes the full range of sonic frequencies that a pair of headphones can achieve. The human ear can only hear frequencies ranging from 20-20,000Hz, so most headphones try to stick to this range. However, some headphones extend the range at both ends in order provide deeper responses. Although these can't be heard, they can be felt to a small extent along with the audible range, and a wider range often allows for better tone, responses and handling in the midrange, lows and highs. Check the frequency range on the box for an indication of how those particular cans will handle frequencies.
Soundstaging and imaging
These terms represent the ability of headphones to create an accurate sonic stage and image within your mind. Good soundstaging and imaging will create the impression of a live performance, where individual elements of the sound are distinct and feel like they are originating from specific locations on the virtual stage. Separation of sonic elements is also a function of imaging, where better separation represents a more realistic, true-to-life sound. This is best judged by listening and keeping your ears open for separation and clarity, so you won't find it on the specifications of the headphones, but you'll often see it mentioned in reviews.
headphones101_main3_cc0.jpgImpedance
In simple terms, headphone impedance represents the amount of power needed to drive a pair of headphones. Low-impedance headphones require less power to drive, and can therefore easily be used with source devices with weaker amplification, such as smartphones, media players, and other portable devices. They are also more susceptible to blowouts, if too much amplification is delivered to them.
High-impedance headphones require dedicated amplifiers or increased amplification to drive, and deliver a more powerful, driven performance as a result. They are less susceptible to blow-outs, as they are designed to handle more amplification. When choosing headphones, it's important to note the impedance and buy according to the source device you intend to use. Look out for the impedance figure on the box, and choose as per your source devices. Impedance of 15Ohms and under is low and easy to drive, while impedance 50Ohms and above may require some amplification for best results. However, most smartphones and media players are designed to be able to drive headphones with impedance as high as 80Ohms, so higher-side impedance may not be a serious issue.
headphones101_main4_cc0.jpgThese are the main "specifications" that manufacturers tout, and all of them have a different impact on the audio you're listening to, as we explain above. When you're buying a headset, apart from the design types, these specifications are some of the important things you should know about.
What are the features that you normally look for in your headsets? Is there any jargon you've come across that doesn't make sense? Let us know via the comments.

Friday, 17 July 2015

Javascript Cryptography Beginners guide

Hi All ,

The following would resolve the list of clarification with respective to javascript cryptography :

WHAT DO YOU MEAN, "JAVASCRIPT CRYPTOGRAPHY"?

We mean attempts to implement security features in browsers using cryptographic algoritms implemented in whole or in part in Javascript.
You may now be asking yourself, "What about Node.js? What about non-browser Javascript?". Non-browser Javascript cryptography is perilous, but not doomed. For the rest of this document, we're referring to browser Javascript when we discuss Javascript cryptography.

WHY DOES BROWSER CRYPTOGRAPHY MATTER?

The web hosts most of the world's new crypto functionality. A significant portion of that crypto has been implemented in Javascript, and is thus doomed. This is an issue worth discussing.

WHAT ARE SOME EXAMPLES OF "DOOMED" BROWSER CRYPTOGRAPHY?

You have a web application. People log in to it with usernames and passwords. You'd rather they didn't send their passwords in the clear, where attackers can capture them. You could use SSL/TLS to solve this problem, but that's expensive and complicated. So instead, you create a challenge-response protocol, where the application sends Javascript to user browsers that gets them to sendHMAC-SHA1(password, nonce) to prove they know a password without ever transmitting the password.
Or, you have a different application, where users edit private notes stored on a server. You'd like to offer your users the feature of knowing that their notes can't be read by the server. So you generate an AES key for each note, send it to the user's browser to store locally, forget the key, and let the user wrap and unwrap their data.

WHAT'S WRONG WITH THESE EXAMPLES?

They will both fail to secure users.

REALLY? WHY?

For several reasons, including the following:
  • Secure delivery of Javascript to browsers is a chicken-egg problem.
  • Browser Javascript is hostile to cryptography.
  • The "view-source" transparency of Javascript is illusory.
  • Until those problems are fixed, Javascript isn't a serious crypto research environment, and suffers for it.

WHAT'S THE "CHICKEN-EGG PROBLEM" WITH DELIVERING JAVASCRIPT CRYPTOGRAPHY?

If you don't trust the network to deliver a password, or, worse, don't trust the server not to keep user secrets, you can't trust them to deliver security code. The same attacker who was sniffing passwords or reading diaries before you introduce crypto is simply hijacking crypto code after you do.

THAT ATTACK SOUNDS COMPLICATED! SURELY, YOU'RE BETTER OFF WITH CRYPTO THAN WITHOUT IT?

There are three misconceptions embedded in that common objection, all of them grave.
First, although the "hijack the crypto code to steal secrets" attack sounds complicated, it is in fact simple. Any attacker who could swipe an unencrypted secret can, with almost total certainty, intercept and alter a web request. Intercepting requests does not require advanced computer science. Once an attacker controls the web requests, the work needed to fatally wound crypto code is trivial: the attacker need only inject another <SCRIPT> tag to steal secrets before they're encrypted.
Second, the difficulty of an attack is irrelevant. What's relevant is how tractable the attack is. Cryptography deals in problems that intractable even stipulating an attacker with as many advanced computers as there are atoms composing the planet we live on. On that scale, the difficulty of defeating a cryptosystem delivered over an insecure channel is indistinguishable from "so trivial as to be automatic". Further perspective: we live and work in an uncertain world in which any piece of software we rely on could be found vulnerable to new flaws at any time. But all those flaws require new R&D effort to discover. Relative to the difficulty of those attacks, against which the industry deploys hundreds of millions of dollars every year, the difficulties of breaking Javascript crypto remain imperceptibly different than "trivial".
Finally, the security value of a crypto measure that fails can easily fall below zero. The most obvious way that can happen is for impressive-sounding crypto terminology to convey a false sense of security. But there are worse ways; for instance, flaws in login crypto can allow attackers to log in without ever knowing a user's password, or can disclose one user's documents to another user.

WHY CAN'T I USE TLS/SSL TO DELIVER THE JAVASCRIPT CRYPTO CODE?

You can. It's harder than it sounds, but you safely transmit Javascript crypto to a browser using SSL. The problem is, having established a secure channel with SSL, you no longer need Javascript cryptography; you have "real" cryptography. Meanwhile, the Javascript crypto code is still imperiled by other browser problems.

WHAT'S HARD ABOUT DEPLOYING JAVASCRIPT OVER SSL/TLS?

You can't simply send a single Javascript file over SSL/TLS. You have to send all the page contentover SSL/TLS. Otherwise, attackers will hijack the crypto code using the least-secure connection that builds the page.

HOW ARE BROWSERS HOSTILE TO CRYPTOGRAPHY?

In a dispriting variety of ways, among them:
  • The prevalence of content-controlled code.
  • The malleability of the Javascript runtime.
  • The lack of systems programming primitives needed to implement crypto.
  • The crushing weight of the installed base of users.
Each of these issues creates security gaps that are fatal to secure crypto. Attackers will exploit them to defeat systems that should otherwise be secure. There may be no way to address them without fixing browsers.

WHAT DO YOU MEAN BY "CONTENT-CONTROLLED CODE"? WHY IS IT A PROBLEM?

We mean that pages are built from multiple requests, some of them conveying Javascript directly, and some of them influencing Javascript using DOM tag attributes (such as "onmouseover").

OK, THEN I'LL JUST SERVE A CRYPTOGRAPHIC DIGEST OF MY CODE FROM THE SAME SERVER SO THE CODE CAN VERIFY ITSELF.

This won't work.
Content-controlled code means you can't reason about the security of a piece of Javascript without considering every other piece of content that built the page that hosted it. A crypto routine that is completely sound by itself can be utterly insecure hosted on a page with a single, invisible DOM attribute that backdoors routines that the crypto depends on.
This isn't an abstract problem. It's an instance of "Javascript injection", better known to web developers as "cross-site scripting". Virtually every popular web application ever deployed has fallen victim to this problem, and few researchers would take the other side of a bet that most will again in the future.
Worse still, browsers cache both content and Javascript aggressively; caching is vital to web performance. Javascript crypto can't control the caching behavior of the whole browser with specificity, and for most applications it's infeasible to entirely disable caching. This means that unless you can create a "clean-room" environment for your crypto code to run in, pulling in no resource tainted by any other site resource (from layout to UX) , you can't even know what version of the content you're looking at.

WHAT'S A "MALLEABLE RUNTIME"? WHY ARE THEY BAD?

We mean you can change the way the environment works at runtime. And it's not bad; it's a fantastic property of a programming environment, particularly one used "in the small" like Javascript often is. But it's a real problem for crypto.
The problem with running crypto code in Javascript is that practically any function that the crypto depends on could be overridden silently by any piece of content used to build the hosting page. Crypto security could be undone early in the process (by generating bogus random numbers, or by tampering with constants and parameters used by algorithms), or later (by spiriting key material back to an attacker), or --- in the most likely scenario --- by bypassing the crypto entirely.
There is no reliable way for any piece of Javascript code to verify its execution environment. Javascript crypto code can't ask, "am I really dealing with a random number generator, or with some facsimile of one provided by an attacker?" And it certainly can't assert "nobody is allowed to do anything with this crypto secret except in ways that I, the author, approve of". These are two properties that often are provided in other environments that use crypto, and they're impossible in Javascript.

WELL THEN, COULDN'T I WRITE A SIMPLE BROWSER EXTENSION THAT WOULD ALLOW JAVASCRIPT TO VERIFY ITSELF?

You could. It's harder than it sounds, because you'd have to verify the entire runtime, including anything the DOM could contribute to it, but it is theoretically possible. But why would you ever do that? If you can write a runtime verifier extension, you can also do your crypto in the extension, and it'll be far safer and better.
"But", you're about to say, "I want my crypto to be flexible! I only want the bare minimum functionality in the extension!" This is a bad thing to want, because ninety-nine and five-more-nines percent of the crypto needed by web applications would be entirely served by a simple, well-specified cryptosystem: PGP.
The PGP cryptosystem is approaching two decades of continuous study. Just as all programs evolve towards a point where they can read email, and all languages contain a poorly-specified and buggy implementation of Lisp, most crypto code is at heart an inferior version of PGP. PGP sounds complicated, but there is no reason a browser-engine implementation would need to be (for instance, the web doesn't need all the keyring management, the "web of trust", or the key servers). At the same time, much of what makes PGP seem unwieldy is actually defending against specific, dangerous attacks.

YOU WANT MY BROWSER TO HAVE MY PGP KEY?

Definitely not. It'd be nice if your browser could generate, store, and use its own PGP keys though.

WHAT SYSTEMS PROGRAMMING FUNCTIONALITY DOES JAVASCRIPT LACK?

Here's a starting point: a secure random number generator.

HOW BIG A DEAL IS THE RANDOM NUMBER GENERATOR?

Virtually all cryptography depends on secure random number generators (crypto people call them CSPRNGs). In most schemes, the crypto keys themselves come from a CSPRNG. If your PRNG isn't CS, your scheme is no longer cryptographically secure; it is only as secure as the random number generator.

BUT HOW EASY IS IT TO ATTACK AN INSECURE RANDOM GENERATOR, REALLY?

It's actually hard to say, because in real cryptosystems, bad RNGs are a "hair on fire" problem solved by providing a real RNG. Some RNG schemes are pencil-and-paper solveable; others are "crackable", like an old DES crypt(3) password. It depends on the degree of badness you're willing to accept. But: no SSL system would accept any degree of RNG badness.

BUT I CAN GET RANDOM NUMBERS OVER THE INTERNET AND USE THEM FOR MY CRYPTO!

How can you do that without SSL? And if you have SSL, why do you need Javascript crypto? Just use the SSL.

I'LL USE RANDOM.ORG. THEY SUPPORT SSL.

“Javascript Cryptography. It's so bad, you’ll consider making async HTTPS requests to RANDOM.ORG simply to fetch random numbers."
Imagine a system that involved your browser encrypting something, but filing away a copy of the plaintext and the key material with an unrelated third party on the Internet just for safekeeping. That's what this solution amounts to. You can't outsource random number generation in a cryptosystem; doing so outsources the security of the system.

WHAT ELSE IS THE JAVASCRIPT RUNTIME LACKING FOR CRYPTO IMPLEMENTORS?

Two big ones are secure erase (Javascript is usually garbage collected, so secrets are lurking in memory potentially long after they're needed) and functions with known timing characteristics. Real crypto libraries are carefully studied and vetted to eliminate data-dependant code paths --- ensuring that one similarly-sized bucket of bits takes as long to process as any other --- because without that vetting, attackers can extract crypto keys from timing.

BUT OTHER LANGUAGES HAVE THE SAME PROBLEM!

That's true. But what's your point? We're not saying Javascript is a bad language. We're saying it doesn't work for crypto inside a browser.

BUT PEOPLE RELY ON CRYPTO IN LANGUAGES LIKE RUBY AND JAVA TODAY. ARE THEY DOOMED, TOO?

Some of them are; crypto is perilous.
But many of them aren't, because they can deploy countermeasures that Javascript can't. For instance, a web app developer can hook up a real CSPRNG from the operating system with an extension library, or call out to constant-time compare functions.
If Python was the standard browser content programming language, browser Python crypto would also be doomed.

WHAT ELSE IS JAVASCRIPT MISSING?

A secure keystore.

WHAT'S THAT?

A way to generate and store private keys that doesn't depend on an external trust anchor.

EXTERNAL WHAT NOW?

It means, there's no way to store a key securely in Javascript that couldn't be expressed with the same fundamental degree of security by storing the key on someone else's server.

WAIT, CAN'T I GENERATE A KEY AND USE IT TO SECURE THINGS IN HTML5 LOCAL STORAGE? WHAT'S WRONG WITH THAT?

That scheme is, at best, only as secure as the server that fed you the code you used to secure the key. You might as well just store the key on that server and ask for it later. For that matter, store your documents there, and keep the moving parts out of the browser.

THESE DON'T SEEM LIKE EARTH-SHATTERING PROBLEMS. WE'RE SO CLOSE TO HAVING WHAT WE NEED IN BROWSERS, WHY NOT GET TO WORK ON IT?

Check back in 10 years when the majority of people aren't running browsers from 2008.

THAT'S THE SAME THING PEOPLE SAY ABOUT WEB STANDARDS.

Compare downsides: using Arial as your typeface when you really wanted FF Meta, or coughing up a private key for a crypto operation.
We're not being entirely glib. Web standards advocates care about graceful degradation, the idea that a page should at least be legible even if the browser doesn't understand some advanced tag or CSS declaration.
"Graceful degradation" in cryptography would imply that the server could reliably identify which clients it could safely communicate with, and fall back to some acceptable substitute in cases where it couldn't. The former problem is unsolved even in the academic literature. The latter recalls the chicken-egg problem of web crypto: if you have an acceptable lowest-common-denominator solution, use that instead.

THIS IS WHAT YOU MEANT WHEN YOU REFERRED TO THE "CRUSHING BURDEN OF THE INSTALLED BASE"?

Yes.

AND WHEN YOU SAID "VIEW-SOURCE TRANSPARENCY WAS ILLUSORY"?

We meant that you can't just look at a Javascript file and know that it's secure, even in the vanishingly unlikely event that you were a skilled cryptographer, because of all the reasons we just cited.

NOBODY VERIFIES THE SOFTWARE THEY DOWNLOAD BEFORE THEY RUN IT. HOW COULD THIS BE WORSE?

Nobody installs hundreds of applications every day. Nobody re-installs each application every time they run it. But that's what people are doing, without even realizing it, with web apps.
This is a big deal: it means attackers have many hundreds of opportunities to break web app crypto, where they might only have one or two opportunities to break a native application.

BUT PEOPLE GIVE THEIR CREDIT CARDS TO HUNDREDS OF RANDOM PEOPLE INSECURELY.

An attacker can exploit a flaw in a web app across tens or hundreds of thousands of users at one stroke. They can't get a hundred thousand credit card numbers on the street.

YOU'RE JUST NOT GOING TO GIVE AN INCH ON THIS, ARE YOU?

Nobody would accept any of the problems we're dredging up here in a real cryptosystem. If SSL/TLS or PGP had just a few of these problems, it would be front-page news in the trade press.

YOU SAID JAVASCRIPT CRYPTO ISN'T A SERIOUS RESEARCH AREA.

It isn't.

HOW MUCH RESEARCH DO WE REALLY NEED? WE'LL JUST USE AES AND SHA256. NOBODY'S TALKING ABOUT INVENTING NEW CRYPTOSYSTEMS.

AES is to "secure cryptosystems" what uranium oxide pellets are to "a working nuclear reactor". Ever read the story of the radioactive boy scout? He bought an old clock with painted with radium and found a vial of radium paint inside. Using that and a strip of beryllium swiped from his high school chemistry lab, he built a radium gun that irradiated pitchblende. He was on his way to building a "working breeder reactor" before moon-suited EPA officials shut him down and turned his neighborhood into a Superfund site.
The risks in building cryptography directly out of AES and SHA routines are comparable. It is capital-H Hard to construct safe cryptosystems out of raw algorithms, which is why you generally want to use high-level constructs like PGP instead of low-level ones.

WHAT ABOUT THINGS LIKE SJCL, THE STANFORD CRYPTO LIBRARY?

SJCL is great work, but you can't use it securely in a browser for all the reasons we've given in this document.
SJCL is also practically the only example of a trustworthy crypto library written in Javascript, and it's extremely young.
The authors of SJCL themselves say, "Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks." That last example is a killer: what they're really saying is, "we don't know enough about Javascript runtimes to know whether we can securely host cryptography on them". Again, that's painful-but-tolerable in a server-side application, where you can always call out to native code as a workaround. It's death to a browser.

AREN'T YOU CREATING A SELF-FULFILLING PROPHECY ABOUT JAVASCRIPT CRYPTO RESEARCH?

People don't take Javascript crypto seriously because they can't get past things like "there's no secure way to key a cryptosystem" and "there's no reliably safe way to deliver the crypto code itself" and "there's practically no value to doing crypto in Javascript once you add SSL to the mix, which you have to do to deliver the code".

THESE MAY BE REAL PROBLEMS, BUT WE'RE TALKING ABOUT MAKING CRYPTO AVAILABLE TO EVERYONE ON THE INTERNET. THE REWARDS OUTWEIGH THE RISKS!

DETROIT --- A man who became the subject of a book called "The Radioactive Boy Scout" after trying to build a nuclear reactor in a shed as a teenager has been charged with stealing 16 smoke detectors. Police say it was a possible effort to experiment with radioactive materials.
The world works the way it works, not the way we want it to work. It's one thing to point at the flaws that make it hard to do cryptography in Javascript and propose ways to solve them; it's quite a different thing to simply wish them away, which is exactly what you do when you deploy cryptography to end-users using their browser's Javascript runtime.