Vincent Gable’s Blog

July 21, 2010

Sneaking Malware Into the App Store

Filed under: Announcement,iPhone,Programming,Security | , , , ,
― Vincent Gable on July 21, 2010

It’s happened. An app that grossly violated Apple’s terms of service (by enabling free tethering) made it through Apple’s review process, onto the App Store, and into the #2 most-popular spot before being taken down. Although this app wasn’t malicious to users, it’s absolutely malicious to Apple’s agreements with AT&T and other phone-companies. It is a real demonstration that Apple can’t keep malware off the App Store.

A Few Sneaky Ideas

It’s not hard to come up with ways to fool App-Store reviewers.

You might just get lucky. With over 230,000 Apps in the store, reviewers are swamped. They’re only human and they might not notice some subtle evil — especially if it’s not on their naughty-behavior list.

Time-Bombs, apps that hide their bad-behavior for a few days, are undetectable without periodic audits, since they act normally during the pre-release review period.

Phoning home to a server that let’s an app know it’s passed review and can begin it’s life of crime, would let an app be even more precise.

With just a few minutes thought, I’m sure you can think of even more clever tricks, or combination of tricks.

Not a Fully Open Vulnerability

That’s not to say your iPhone is in as much danger as your PC. iOS apps don’t have the same free-reign that traditional computer programs have. That limits their usefulness, but it also limits the damage they can cause. An iOS App can’t stop you from killing it, and it can’t mess with other apps, so it can’t “take over” your phone. But it can do anything it likes with your Contacts, and secretly abuse the phone’s always-on network connection, and get up to other sorts of minor mischief.

I don’t have room here to fully analyze the risks of a rogue iPhone’s program. But generally, the danger isn’t too great: a little more than a what website can do, a lot less than what a PC program with administrator access can do.

Ultimately, Apple’s best defense against malware isn’t control of the App Store review process or iTunes payments (although they help), but control over iOS. A well-designed operating system limits what kinds of malware are possible. The review process can screen for egregious mistakes. But it can’t catch everything, and it’s least-able to catch the most clever malware, which ultimately, are the programs we should be most worried about. Apple’s review process doesn’t provide real security against modern malware.

May 24, 2010

Experts are Easier to Fool

Filed under: Quotes,Research,Security | , ,
― Vincent Gable on May 24, 2010

Another counter-intuitive finding is that scam victims often have better than average background knowledge in the area of the scam content. For example, it seems that people with experience of playing legitimate prize draws and lotteries are more likely to fall for a scam in this area than people with less knowledge and experience in this field. This also applies to those with some knowledge of investments. Such knowledge can increase rather than decrease the risk of becoming a victim.

(via Bruce Schneier)

November 9, 2009


What’s a spurious relationship?

Here’s one: People who eat ice cream are more likely to drown. Both incidence of ice cream eating and rates of drowning are related to summertime. The relationship between ice cream and drowning is spurious. That is, there is no relationship. Yet they appear related because they are both related to a third variable.

Lisa Wade


(Image via the amazing Superdickery)

October 24, 2009

Ignorance is Moral Strength

Filed under: Design,Quotes,Security | , , , , ,
― Vincent Gable on October 24, 2009

I have long been impressed with the casino industry’s ability to, in the case of blackjack, convince the gambling public that using strategy equals cheating.

Bruce Schneier

October 14, 2009

Misunderestimating the Cloud

Filed under: Programming,Quotes,Security | , , , ,
― Vincent Gable on October 14, 2009

Recently, a Microsoft datacenter lost thousands of mobilephone user’s personal data.

A common response to this story is that this kind of danger is inherent in “cloud” computing services, where you rely on some service provider to take care of your data. But this misses the point, I think. Preserving data is difficult, and individual users tend to do a mediocre job of it. Admit it: You have lost your own data at some point. I know I have lost some of mine. A big, professionally run data center is much less likely to lose your data than you are.

Ed Felton

It’s easy to convince yourself of this anecdotally. Look around you, how many people people that you loosely know on Facebook have you seen complain about losing all their contacts when they lost their phone? I’ve seen at least a dozen such announcements. But nobody I actually know has been affected by this recent fiasco, or complained about losing contacts in any other “cloud” failure.

But people have a bias to overestimate risks they can’t control, and underestimate risks they can control. So we reinvent the wheel, and lose our own data ourselves.

Hey, I do it too. Actuarially, I really should be paying to manage this blog.

September 18, 2009

Strange AOL Instant Message Filtering

Filed under: Announcement,Bug Bite,Security | , , , ,
― Vincent Gable on September 18, 2009

You can’t send a message over AIM that has a JavaScript event handler name, followed by = in it. The message seems to be blocked on the server, not in the client, as this behavior was observed in different AIM clients (iChat, Adium, and meebo.)


The following messages can’t be sent over AIM:


onclick =

Yo dawg, I heard you liked onclick= in your JavaScript…

Interestingly, using a newline, instead of space, between the handler name and = allows the message to be sent, even though it is still valid HTML/JavaScript. For example, you can send,

/*this is fine*/

I suspect there is an interesting security story behind all of this. If you know how and why this filtering came to pass, I please leave a comment.

Thanks to Dustin Silverman for helping me investigate this. In case you were wondering how I stumbled onto this behavior — I was sending snippets of HTML from over AIM.

August 28, 2009

Fair Coin Tosses

Filed under: Security,Tips | , , ,
― Vincent Gable on August 28, 2009

Flipping a coin is, ever so slightly, unfair. As this article (via) points out, there is a bias for a coin to land on the same side it started on.

Fortunately, all the biases coins have are systemic biases — they effect all similar coins the same way.

So, with a fair thrower, it’s possible to flip twice, and have the bias of the two throws cancel each other out.


  1. Put a coin heads-up, and flip it, as you normally would.
  2. Note the result, if certified this will be the decision.
  3. Flip the coin again, exactly as you did in step 1.
  4. If the coin lands on the opposite side as it did in step 2, the result from step 2 is certified. Otherwise, restart from step 1.

For maximum fairness and reproducibility, it’s best to let the coin land on the floor.

Why This Works

To simplify discussion, let’s call the sides of the coin unlikely (U) and likely (L) instead of heads & tails.

There are only 4 possible results to a pair of coin tosses: UU, UL, LU, LL. Obviously LL is most likely, and UU is least likely, so we rethrow if we get either (steps 3-4). That means the only “certified” results are UL or LU, and the odds of getting UL are the same as getting LU.

Dexterous Cheating

Unfortunately, this is not a self-enforcing protocol, so if the thrower is skillful enough, they can make the second throw go however they like, and keep re-throwing until they get the result they want.

Fortunately, most people aren’t able to manipulate a coin-toss. If you are worried that someone else is, then only let them flip once, and call the result in the air — that way they won’t know which side to pick.

If you can throw the result, and can’t find someone else to call the result — it serves you right for driving away all your friends by cheating at coin tosses, you tosser. But I’m still impressed.

August 19, 2009

iPhone Password Correction

Filed under: Accessibility,iPhone,Security,Usability | , , , ,
― Vincent Gable on August 19, 2009

Idea: your iPhone knows your passwords, so when you make a small typo, it corrects it for you.

There are obviously major security concerns here. But I believe they can be acceptably mitigated by the phone itself. Someone would have to physically use the iPhone to get password correction, and correctly could only happen on the first or second password attempt. Also, correction could be limited to the kinds of typos a person would make.

Passwords are broken by machines, not people. I believe password correction can help people, without substantially helping machines, and compromising security.

It’s hard to type precisely on an iPhone’s virtual keyboard. That prevents people from using secure passwords, and that hurts security. Because password correction helps people actually use strong passwords, it should be to be a net security benefit.

June 1, 2009

Pass Phrases, Not Passwords

Filed under: Accessibility,Research,Security,Usability | , , , ,
― Vincent Gable on June 1, 2009

Thomas Baekdal makes a convincing argument for using pass-phrases not passwords (via). It’s excellent advice, and I know I’m not alone in having advocated it for years.

My keyboard has 26 letters, 10 numbers, and 12 symbol keys, like ~. All but spacebar make a different symbol when I hold down shift, giving me 93 characters to use in my passwords. But the number of words that can make-up a pass-phrase is easily in the 100,000s. Estimating exactly how big is a bit tricky, but I will stick with 250,000 here (I think it’s an undercount, more on this later).

We Know How To Talk

The human brain has an amazing aptitude for language. But “passwords” aren’t really words, so they don’t tap into this ability. In fact, we often use words to try and remember the nonsense-characters of a password.

Wouldn’t it make more sense to just use the words directly, if we can remember them more easily?

Hard For Computers, Not Hard For Us

People feel that if security system A is harder for them to use then system B, then A must be harder for an attacker to bypass. But the facts don’t always match this intuition.

What authentication code do you think is harder for a bad guy to hack, the 7 character strong password “1Ea.$]/”, or the mnemonic for the first 3 characters, “One Elvis Amazon”? Certainly “1Ea.$]/” is harder for a person to remember. It feels like it should be harder to break. But a computer, not a person, is going to be doing the guessing, and all it cares about is how big the search space is. There are 937 possible 7 character passwords. Let’s say there are 250,000 possible English words (more on that figure later). Then there are 250,0003 3 word combinations — meaning an attacker would have to do 260 times more work to guess “One Elvis Amazon” than to guess “1Ea.$]/”.

With pass phrases, easier for the good guys is also harder for the bad guys.

Exactly How Much Harder

The “250,000 word” figure is a bunch of hand-waiving, but I believe it’s an undercount. I picked it, because I wanted a round number to crunch; it’s what Thomas Baekdal picked; and it’s about the size of the Mac OS X words file,

$ wc -l /usr/share/dict/words 

But liberally descriptive linguists say that the 1,000,000th word will be added to the English Language on June 10th, 2009. The more conservative Webster’s Third New International Dictionary, Unabridged list 475,000 English words. Obviously neologisms, slang, and archaic terms are fine for pass phrases. People like discovering quirky words. I see far more more people embracing the login, “kilderkin of locats”, then rejecting it.

Different conjugations (can) count as different words in pass-phrases. There’s only one entry in a dictionary for swim, but swim, swimming, swam, etc. make for distinct pass-phrases (eg. “Elvis swims fast”, “Elvis swam fast”, etc. Both phrases don’t show up in a google search by the way.) So the real number of words should be a few fold larger than a dictionary indicates.

But not all words are equally likely to be chosen — just as some characters are more popular in passwords. My earlier figure of “2500003 3 word combinations” was based on the naive assumption that each of the 3 words is independent. But people do not pick things at random. And a phrase is by definition not completely random — it must have some structure. I’m unaware of research into exactly how predictable people are when making-up pass-phrases.

But given how terrible we are at picking good passwords, and how good we are at remembering non-nonsense-words, I am optimistic that we can remember pass-phrases that are orders of magnitude harder to guess than the “good” passwords we can’t remember today.

Fewer Ways To Fail

We’ve all locked ourselves out of an account because of typos or caps lock. But pass-phrases can be more forgiving.

Pass-phrases are caseinsensitive. There’s no need to lock someone out over “ELvis…”.

Common typos can be auto-corrected, much as google automatically suggests words. Consider the authentication attempt “Elvis Swimmms fast”. The system could recognize that “Swimms” isn’t a word, and try the most likely correction, “Elvis Swimms fast” — if it matches, then there’s no reason to ask the user if it’s what they really meant. (Note that only one pass-phrase is checked per login attempt.) I don’t have hard data here, but given how successful google is at interpreting typos, I’d expect such a system to work very well.

Pass-phrases might be more difficult on Phones, and similarly awkward to write with devices. Writing more letters means more work. Predictive text can only do so much. Repeatedly typing 3 letters and accepting a suggestion is clearly more work then just tapping out 6 characters. Additionally, there are security concerns with a predictive text system remembering your pass-phrase, or even a small part of it.

But for computers, pass phrases look like a clear usability win.

Easily Secure Conclusion

(In case you were wondering that was a unique phrase when I wrote this.) Using pass-phrases over passwords (which are really pass-strings-of-nonsense-sybols-that-nobody-can-remember) makes a system significantly harder to crack. Pass-phrases are easier for humans to remember, and a system that uses them can be very forgiving. But as always, the devil is in the details. It’s terrifying to be an early adopter of a new security practice, even if it seems sound.

May 26, 2009

Secret Questions Are a Bad Idea

Filed under: Design,Quotes,Security,Usability | , , ,
― Vincent Gable on May 26, 2009

Secret questions are an easier way for someone to hack your account. I don’t see that they offer much over asking people to pick an insecurely convenient password.

Here’s some data on how insecure secret questions are,

Acquaintance with whom participants reported being unwilling to share their webmail passwords were able to guess 17% of their answers (to “secret” questions). Participants forgot 20% of their own answers within six months. What’s more, 13% of answers could be guessed within five attempts by guessing the most popular answers of other participants, though this weakness is partially attributable to the geographic homogeneity of our participant pool.

It’s no secret: Measuring the security and reliability of authentication via ‘secret’ questions
, Stuart Schechter, A. J. Bernheim Brush, Serge Egelman, 17 May 2009

(Via Bruce Schneier)

It’s important to note that people often forget answers to their own secret questions. Anecdotally, I’ve had to call my bank twice because I forgot exactly how I typed in my answers.

Forgetting the answer to a secret question can be embarrassing, unlike forgetting a password. I once got my mother’s maiden name wrong repeatedly. It was pretty awkward. (A credit card was also in my mother’s name, so when they asked “for my mother’s maiden name” they really meant her mother’s maiden name.)

I don’t know of any statistics on how often accounts are compromised by secret questions. But there have been high-profile cases, like Sarah Palin’s email,

…the Palin hack didn’t require any real skill. Instead, the hacker simply reset Palin’s password using her birthdate, ZIP code and information about where she met her spouse — the security question on her Yahoo account, which was answered (Wasilla High) by a simple Google search.

Bruce Schneier says, “Passwords have reached the end of their useful life. Today, they only work for low-security applications. The secret question is just one manifestation of that fact.” If you must use password authentication, then don’t weaken it further with a questionable back door.

Older Posts »

Powered by WordPress