Passwords Suck

25. January, 2013

On Wednesday, GitHub improved their code search. A few hours later, a couple of people had tried “begin rsa private key” and got more results than any sane person would anticipate. Just in case, this isn’t a problem of GitHub, the same problem can be found on pastebin or with Google.

There are several reasons for people to publish sensitive data:

  • They don’t know what they’re doing (ignorance)
  • They are sure “no one will ever find out” (security by obscurity)
  • Distributing sensitive data anonymously (crackers)
  • It’s easier that way (laziness)

It’s not a corner case, either. The SQL*Plus tool from Oracle has no easy way to set the password from a script except by passing it on the command line which effectively publishes the password to any user on the same computer. You can install a “client-side Oracle wallet” to fix this.

But the common issue behind all that is that it’s either too easy to do it wrong or too hard to do it right. Just to see how bad the situation is, I asked for a secure web login/example on stackoverflow.com. The answer was basically “it’s too complex to do.”

This sucks.


Targeted Spamming via Facebook

26. September, 2012

 

In the past few weeks, I started getting mails from friends which just contain a link:

hey, Aaron

    http://some-dubious-link/a/b/c/

9/25/2012 12:34:56 PM

Turns out that someone is analyzing my Facebook account and sends me mails using names from my friends list.

If you get such a mail, don’t click on the link. It probably points to a page which infects your computer with a virus.

Right now, these mails are pretty easy to identify as fake because the email address is wrong. But you should know that the sender address in emails is just a text; neither the sending nor the receiving computer will check what is in there. A spammer can write anything into that field. If the scheme starts to fail too often, I expect to see “better” email addresses.

This means as a receiver, you should never click on links in emails. As a sender, you should never share links by email.

 


Embarrassing Security Failure at PayPal

26. March, 2012

PayPal is one of the places who really care about security.

But even they were vulnerable to XSS type of attacks using the search feature (see this article for details).

At the moment, I’m not sure if that’s more embarrassing or frightening. Sure, it’s shameful but when even those guys don’t get it right … who can?


Stand up for your freedom to install free software!

19. October, 2011

Read the truth behind so-called “Secure Boot” and sign the statement.


Who is Responsible For Data Theft?

22. July, 2011

Would you like to see your name, address, birth date and email on a public bill board? On the main street? What if the bill board is behind a big sign “don’t read this”?

If that worries you, why do you give your data to web sites of big companies? Many of them, even the big ones, show very little interest in keeping your contact detains secure. Many sites are still vulnerable to cross site scripting or SQL injections.

If anyone puts your life or privacy at risk, they are liable – except when web sites are involved. Even if they violate common sense and even the most basic rules of security, the worst that can happen is that they have to apologize. Pollute some fish? To Jail! Lose 300 million customer records? Oops, sorry about that.

Paul Venezia asked an interesting question: Should companies be accountable for the security risks they take? He says:

In the United States, at least, very specific laws govern patient information and how it is stored, accessed, and disseminated. HIPAA regulations were put into place to ensure that sensitive patient information isn’t distributed to just anyone — that is, only to the people who need that information. They also prevent health care providers from discussing any type of patient information with anyone else. They were explicitly designed to protect patients, and each patient must sign a waiver to authorize the release of that information to another person or party. Yet we have no regulations on the storage, access, and dissemination of sensitive user information on public websites — none. Thus, there’s almost no business case for providing any form of high-level security for customer accounts.

Interesting thought. I have two comments:

1. Not individual developers should be liable but the company which runs the site. It should be in their best interest to keep their data secure.

2. Today, it’s too complex to create secure web sites. Yesterday, I used renderSnake to create some HTML. If you supply a string value for output, the default is not to escape HTML special characters like <, > and &.

Creating a login component for a web site is pretty complex business and there is a no reasonable tutorial or template component which you could use that gets most security issues right like:

  1. Transmitting the password via HTTPS (encrypted) instead of using plain text (which anyone in the same LAN can read)
  2. Encrypting the password before it’s stored in the database
  3. Storing the password with a salt to make it harder to attack it with rainbow tables
  4. Escaping special characters in user names and password to prevent cross site scripting or SQL injection.
  5. Avoiding security questions like “Name of your cat?” More than 50 people know the name of my cat! The name might even be on the web somewhere (possibly next to a photo on Flickr) How secure is that?
These are the basic rules to make your web site safe against identity theft. It would be simple to create a law saying “if you violate the rules named once per year by a committee of experts, you’re liable for a hefty fine”. If that would happen, I’d support it.

TNBT – Avoiding Common Errors

7. July, 2011

Writing secure code is ever more important. There are lots of examples: HBGary, Sony, Google.

Even if you’re not one of the biggest companies out there, security starts to become important as soon as your code can be accessed from the Internet. And frankly, which code today can’t?

What’s worse, the problems are always the same: SQL injections, not validating input, using code from somewhere else which is vulnerable. These problems are neither hard to find nor hard to fix. It’s only too much effort to add the necessary checking and warning code to the existing compilers.

So here is my assumption for my “The Next Best Thing” series of articles: The programming language will allow to define patterns like FindBugs and PMD that the compiler will check at compile time and which the VM checks at runtime to fix or at least warn about such security problems.

With tools like MoDisco and Moose, it’s possible to go one step further: It could analyze and display the code in ways that you haven’t seen before (think Code City) to find patterns in the code automatically and warn you about something that you might not have realized, yet.

For example, if you use a certain call sequence everywhere in your code but one place, it’s probably worth a look.

Of course, this begs for a way to add lots of additional information to source code. As I said before, we probably want better editors than the plain text editors we have today. It should be possible to include images and formulas in code. Wiki documentation. And things like “yeah, I know, this is different from the 365 other places!”

Sounds a bit like annotations but frankly, Java source code can just get you so far. DSLs come to mind but they don’t allow to extend them with arbitrary extra bits of information. It should be possible to overlay a DSL with another DSL so you can mix various information in one place.

Related Articles:

  • The Next Best Thing – Series in my blog where I dream about the future of software development

Java Finalizer Exploit

6. July, 2011

Did you know that your Java code may be vulnerable to an exploit based on finalization? I didn’t.

This article from IBM’s developerWorks explains how it works.

Basically, you can safe a reference to an object in the finalize() method. At this time, the object may even be in an inconsistent state (the finalizer will be called when the constructor threw an exception).

As for the solution: I don’t like it very much. It adds even more clutter to the existing code and doesn’t relay its purpose very well. Someone refactoring the code might feel tempted to remove the “useless additional constructor.” Worse, you need to do this in all your classes which check their parameters.

I would prefer a solution where the compiler or some other tool fixes these issues by generating the necessary code. Especially if you look at more complex cases: What happens if an exception is thrown at a later stage of object creation? Your code is still vulnerable but it seems to be safe. How would you know?

Maybe a better solution would be to check the heap for references to any finalized objects and throw an error “finalization failed”. But that’s probably impossible without breaking backwards compatibility.

Or Oracle could invent a better solution for the finalization problem (which is basically garbage collection for non-memory-resources) so we would not need finalizers anymore.


Jazoon 2011, Day 1 – Java Security Trends: How to Leverage Growing Security Trends in Building Trust into Your Java Applications – James Gould and Srikanth Veeramachaneni

26. June, 2011

Java Security Trends: How to Leverage Growing Security Trends in Building Trust into Your Java Applications – James Gould and Srikanth Veeramachaneni

Nothing spectacular here for me. There was a nice diagram of an SSL handshake, some tips to debug SSL problems, code how to create keystores with the Java tools and how to convert a PEM key into something that Java’s keytool can use.

After that James gave an overview of DNSSEC and how to use it from Java (including code examples).

What I liked about the code examples is that they covered more than the trivial cases. For example, it showed how to specify per-key passwords (in addition to the usual per-keystore password).


Allied Telesis Security Blunder

27. May, 2011

Another reason why security by obscurity is bad: Allied Telesis builds network components. While this page was loaded in your browser, there is a chance that equipment of them was involved somewhere.

Those components have access protection with the common user/password scheme. If you lost your password, the support could tell you the name and password for a backdoor, that is a login that would always work but one that isn’t visible when you, say, request a list of all known users.

Sounds good? It is. Saves a lot of hassle.

The problem? Someone posted the details for all backdoors in the public support section. Which means that crackers all over the globe now have free reign over them.


Publishing Your Passwords on The Internet

17. May, 2011

Would you tell your GMail password to a friend? Your colleagues in the office? Publish it on the Internet?

If the answer to any of these is “NO“, you should turn off automatic synchronization on your Android smartphone and never use it in open Wifi networks.

The reason is that Google uses something called a “token” to allow apps your smartphone to connect to Google services like your mail box, your calendar, etc. The token is like a key on your keychain: Anyone who has the key can open the door it fits. Unlike keys on your key chain, anyone who can pick a token out of the air knows where that door is!

Related article: Catching AuthTokens in the Wild