Posts (page 34 of 43)

LinkedIn, HashedOut Jun 7, 2012
Linked – “Be great at what you do” – In, bringing you modern social networking with less than modern password protection – like, about 1970s UNIX modern. The passwords in this dump not only rejected a robust, well-known password hashing scheme like PBKDF2, they didn’t even salt the passwords. As a historical reference, salts are something FreeBSD introduced around 1994.

It also appears some users are confused as to what constitutes a good password. Length? Characters? Punctuation? Phrases? An unfortunate number of users went for length, but neglected the shift key, space bar, or one of those numbers above qwerty.

I sat down for 20 minutes with shasum and grep – plus my bookshelf for inspiration – to guess some possible passwords without resorting to a brute-force dictionary crack.
```
grep `echo -n myownpassword | shasum | cut -c6-40` SHA1.txt
```
The grep/shasum trick works on Unix-like command lines. John the Ripper is the usual tool for password cracking without entering the super assembly of GPU customization.

I love sci-fi and fantasy. I still run an RPG session on a weekly basis; there’s no dust on my polyhedrals. Speaking of RPGs. I started the guesswork with 1st Edition AD&D terms only to strike out after a dozen tries, but the 2nd edition references fared better:

waterdeep – Under Mountain was awesome, unlike your password.

menzoberranzan – Yeah, mister dual-scimitars shows up in the list, too. This single-handedly killed the Ranger class for me. (Er, not before I had about three rangers with dual longswords. ‘Cause that was totally different…)

No one seems to have taken “1stEditionAD&D”. Maybe that’ll be my new password – 14 characters, a number, a symbol, what’s not to love? Aside from this retroactive revelation?

tardis – Come on, that’s not even eight characters. Would tombaker or jonpertwee approve? I don’t think so. But no Wiliam Hartnell? Have you no sense of history? Even for a timelord?

doctorwho – Longer, but…um…we just covered this.

badwolf – Cool, some Jack Harkness fans out there, but still not eight characters.

torchwood – Love the show, but your anagram improves nothing.

kar120c – I’m glad there’s a fan of The Prisoner out there. It was a cool series with a mind-blowingly bizarre, pontificating, intriguing ending that demands discussion. However, not only is that password short, it even shows up in my book. I should find out who it was and send them a signed copy.

itsatrap – Seriously? You chose a cliched, meme-laden movie quote that short? And you couldn’t be bothered with an exclamation point at the end? At least you chose a line from the best of the three movies.

myprecious – Not anymore.

onering – Onering? While you were out onering your oner a password cracker was cracking your comprehension of LotR. By the way, hackers have also read earthsea, theshining and darktower. Hey, they’ve got good taste.

I adore the Dune books. Dune is near the top of my favorites. Seems I’m not the only fan:

benegesserit – Don’t they have some other quotes? Something about fear?

fearisthemindkiller – Heh, even the hackers hadn’t cracked that one yet. Referencing The Litany Against Fear would have been a nice move except that if “fear is the mind killer” then “obvious is the password.”

entersandman, blackened, dyerseve – What are you going to do when you run out of Metallica tracks? Use megadeath? It’s almost sadbuttrue. And jethrotull beat them at the Grammy’s. So, there.

loveiskind – Love is patient, love is kind, hackers aren’t stupid, passwords they find.

h4xx0r – No, probably not.

notmypassword – Actually, it is. At least you didn’t choose a 14-character secretpassword. That would just be dumb.

stevejobs – Now how is he going to change his password?
Design vs. Implementation Jun 5, 2012
An exposition on the first of the Twelve Web (In)Security Truths

#1 – Software execution is less secure than software design, but running code has more users.

A running site is infinitely more useable than one that only exists in design. Talk all you want, but eventually someone wants you to deliver that design.

Sure, you could describe Twitter as a glorified event loop around an echo server. You might even replicate it in a weekend with a few dozen lines of Python and an EC2 instance. Now scale that napkin design to a few hundred million users preserving security and privacy controls. That’s a testament to implementing a complex design – or scaling a simple design if you boil it down to sending and viewing tweets.

It’s possible to have impressive security through careful design. A prominent example in cryptography is the “perfect secrecy”¹ of the One-Time Pad (OTP). The first OTP appeared in 1882, designed in an era without the codified information theory or cryptanalysis of Claude Shannon and Alan Turing.² Never the less, its design understood the threats to confidential communications when telegraphs and Morse code carried secrets instead of fiber optics and TCP/IP. Sadly, good designs are sometimes forgotten or their importance unrecognized. The OTP didn’t gain popular usage until its re-invention in 1917, along with a more rigorous proof of its security.

But security also suffers when designs have poor implementations or have complex requirements. The OTP fails miserably should a pad be reused or is insufficiently random. The pad must be as long as the input to be ciphered. So, if you’re able to securely distribute a pad (remember, the pad must be unknown to the attacker), then why not just distribute the original message? Once someone introduces a shortcut in the name of efficiency or cleverness the security breaks. (Remember the Debian OpenSSL debacle?) This is why it’s important to understand the reasons for a design rather than treat it as a logic table to be condensed like the singularity of a black hole. Otherwise, you might as well use two rounds of ROT13.

Web security has its design successes. Prepared statements are a prime example of a programming pattern that should have relegated SQL injection to ancient CVEs. Only devotees of Advanced Persistent Ignorance continue to glue SQL statements together with string concatenation. SQL injection is so well-known (at least in appsec) and studied that a venerable tool like sqlmap has been refining exploitation for over six(teen) years.

Yet the Internet loves to re-invent vulns. Whether or not SQL injection is in its death throes, NoSQL injection promises to reanimate its bloated corpse. Herbet West would be proud.

Sometimes software repeats the mistakes, intentionally or not, of other projects without understanding the underlying reasons for those mistakes. The Ruby on Rails Mass Assignment feature is reminiscent of PHP’s register_globals issues. Both are open source projects with large communities. It’s unfair to label the entire group as ignorant of security. But the question of priorities has to be considered. Do you have a default stance of high or low security? Do you have language features whose behavior changes based on configuration settings outside the developer’s control, or that always have predictable behavior?

Secure design is never easy. Apache’s reverse proxy/mod_rewrite bug went through a few iterations and several months of discussion before Apache developers arrived at an effective solution. You might argue that the problem lies with users who created poor rewrite rules that omitted a path component. But I prefer to see it as a design flaw because users had difficulty understanding its nuances and mistakes lead to security issues. Either way, the vuln proved how difficult it is to choose between trade-offs in security decisions.

HTML injection is another bugbear of web security. (Which makes SQL injection the owlbear?) For the longest time there was no equivalent to prepared statements for building HTML on the fly. Developers had to create bespoke solutions for their programming language and web architecture. Then came frameworks like React. It did away with the string concatenation that lead to HTML injection and cross-site scripting. The framework knew how to correctly place arbitrary content so that it remained a text node rather than become a JavaScript execution context.

React even preserved the ability to write insecure HTML, but it did so in a way that was obvious in its design as dangerouslySetInnerHTML. This also made it easier to run linters for identifying areas of risk in the code. Alas, React didn’t even appear until a year after the original version of this article.

The Content Security Policy has been trying to bring a secure design against HTML injection with mechanisms that restrict how a page may load resources. CSP doesn’t prevent HTML injection – it mitigates its exploitability. So, developers must still invest in frameworks like React or other ways of preventing these XSS in the first place. CSP feels like a well-intentioned design, but it suffers from being placed at the point of exploitation (the browser) as opposed to the point where flaws are introduced (the app). Despite more than ten years of design and an iteration to CSP Level 3, this is the type of security design that places a lot of burden on developers to implement without a lot of compelling benefits to justify that burden.

Secure design should be how we send whole groups of vulns to the graveyard. Good security models understand the threats a design counters as well as those it does not. Spend too much time on design and the site will never be implemented. Spend too much time on piecemeal security and you risk blocking obscure exploits rather than fundamental threats.

As the ancient Fremen saying goes, “Truth suffers from too much analysis.”³ Design also suffers when its scrutiny is based on nonspecific or unreasonable threats. It’s important to question the reasons behind a design and the security claims it makes. Yes, HSTS relies on the frail security of DNS – it’s a trust on first use (TOFU) model where the browser assumes the header comes from an authentic source.

However, HSTS improved the reliability of maintaing HTTPS connections and minimizing the impact of malicious CAs, but it also introduced risk. A misconfigured HSTS header could create a self-induced DoS by preventing browsers from connecting. And that misconfiguration might come from a developer mistake or an attacker with the ability to set headers from a compromised server.

Design your way to a secure concept, code your way to a secure site. When vulns appear determine if they’re due to flaws in the design or mistakes in programming. A design that anticipates vulns, like parameterized queries, should be easy to implement and serve the developer’s needs. Vulns that surprise developers should lead to design changes that provide more flexibility for resolving the problem.

Inflexibility, whether in design or implementation, is dangerous to security. As the Bene Gesserit say, “Any road followed precisely to its end leads precisely nowhere.”⁴
1. In the sense of Claude Shannon’s “Communication Theory of Secrecy Systems”. ↩
2. As Steven Bellovin notes in his paper, an 1882 codebook contains an amusingly familiar phrase regarding identity questions, “Identity can be established if the party will answer that his or her mother’s maiden name is…“ It seems identity proofs haven’t changed in 140 years! ↩
3. Frank Herbert. Dune Messiah. p. 81. ↩
4. Frank Herbert. Dune. p. 69. ↩
HTML5 Unbound, part 4 of 4 May 31, 2012

(The series concludes today with guesses about the future of web security. The first, second, and third parts have been published as well as the accompanying slides.)

Design, Doom & Destiny

Mobile devices and apps change they way we consume the web. Even native mobile apps connect to URLs or access web-based APIs.

Who cares about the URL anymore? From QR codes to small screens, there’s minimal real estate to show off a complete link. And all of the padlocks, green text for EVSSL certs, and similar hints are barely useful for desktop browsers.

Mobile app security is currently a nightmare of assorted markets, outright malicious apps, and poorly crafted apps. Mobile apps that interface to web sites don’t always do so securely. And it’s impossible to distinguish bad apps at a glance. Apps that interact with web APIs often employ browser-like features, not a browser. There’s a subtle, but important distinction there.

For example, Twitter’s API is accessible via HTTP or HTTPS. If you use the Twitter web site you can set your account to always use HTTPS. Sadly, that doesn’t affect how apps might use the API. The official Twitter app uses HTTPS. It also refuses to connect if it receives a certificate error. On the other hand, other apps may connect over HTTP, or use HTTPS but not bother to apply certificate validation. A year ago, in 2011, Twitter listed some third-party software projects that used OAuth and Twitter APIs. They ranged in languages from Java to C++ to PHP. Three out of four didn’t even use https:// links. The one that did use https:// didn’t bother to verify the server’s cert.

Update January 15, 2014: Twitter now requires HTTPS access to its API.

Personal data is valuable. In Silicon Valley, the dollar is made of people. We could debate the pros and cons of compliance standards like PCI for credit cards. In an age where companies have billion-dollar valuations based on their user bases, it should be evident that credit cards aren’t the only kind of data coveted by hackers and companies alike. In the last few years several companies have been forced to apologize for privacy breaches or abuse. Set aside the concern about compromise, that was behavior deemed “normal” by the companies in question. Normal until exposed to the scrutiny of the masses.

Privacy is area where HTML5 has tried to balance reasonable design with features users and devs expect from native mobile apps. Before geolocation started showing up in phones or browsers, people could still be tracked by geolocation data marked by cameras in digital photos’ EXIF information. Browser plugins have been abused to create supercookies. It was up to Flash to enforce a privacy policy for its equivalent to the cookie, the Local Shared Object. And, of course, HTML5 has the Web Storage API.

Privacy has to be an area where browsers take the lead on implementing features like providing clear controls for objects stored in a browser and privacy-related headers like Do-Not-Track. The DNT header is another example of browser developers pushing for a new technology, but meeting resistance due to technical as well as business concerns. For example, if 98% of your company’s revenue depends on tracking technologies, then you’ll be sensitive to features like this. Perhaps even reluctant to implement it.

From a design perspective, HTML5 offers many new features that make it easier for web developers to create powerful, useful apps without sacrificing security. The various specs around HTML5 even carry warnings and recommendations about security and privacy for these new technologies.

The implementation of HTML5 will occasionally run into flaws, but that’s to be expected of any large software engineering effort. The use of iframes and sharing resources across documents will likely be a source of problems. At the very least, think in terms of balancing information leakage around framed content. On one hand, it might be desirable to prevent a framed advertising banner from knowing the origin that has framed it. But for sites that aggregate functions (we use to call them mashups), this kind of parent – or child – node information might be useful. And there’s the challenge of making sure a node’s Origin attribute remains stable and correct as complex JavaScript moves it around the DOM, removes it from the DOM, or tries to keep it orphaned and running in the background.

And finally, the password problem has yet to be solved. Regardless of a site’s backend security and use of HTTPS, look how prevalent it is to send the plaintext password from browser to server. That’s begging for some kind of challenge-response that provides better confidentiality for the password. But doing so likely requires browser support and careful design so that there’s clarity around what threats a challenge-response would mitigate and those it wouldn’t. It’s unlikely phishing will disappear any time soon.

There are other positive steps towards password management in the form of OAuth and OpenID. These solutions shift the burden of authentication management from the site to a trusted third-party site. But again we could come up with new threats that this may introduce. For example, strong password security behavior reinforces the idea that you should verify that you’re typing credentials for a site into a form that is served from that site. With OAuth, we’re adjusting the behavior by showing users it’s acceptable to enter important credentials (Google, Facebook, Twitter, etc.) for an unrelated site. There are always going to be engineering problems that don’t have complete technical solutions. Even as users need to remain vigilant about protecting their passwords, developers still need to treat OAuth tokens and the site’s session tokens securely, just as they would passwords.

There are also always going to be ways that secure technologies are used insecurely. HTML5 has done a good job of providing security restrictions or security recommendations. Developers shouldn’t ignore them. Nor should developers forget key principles of secure design, from things like understanding that HTTPS everywhere is good for users’ privacy, but has no bearing on SQL injection or XSS. To maintaining authentication and authorization checks on server-side resources even if the client has similar checks.

Adopt HTML5 now. Start with leading your pages with <!doctype html>. Push your visitors to use a modern web browser. If you don’t have to support IE6, then why bother going through the pain of creating markup for an obsolete browser? Apply trivial headers that only require server-side changes. X-Frame-Options blocks clickjacking (for those using browser that support it). HSTS minimizes sniffing and intermediation threats; we’ll still need secure DNS to make it complete. We can’t just rely on browsers to become better. Sites need to keep up with security improvements. Try enabling only TLS 1.1 and 1.2. See how many sites fail for you.

HTML5 is the promethean technology of the web’s future. Preserving the security and privacy of data from a mobile app or an HTML5 web site should be the driving force behind the app’s design. The implementation of your site and how it applies HTML5’s feature to user data will determine security. Don’t rely on a standards body or browser security to do it for you.