Bookshout's importer is a very bad idea

I blame myself for not noticing earlier. Bookshout’s announcement and demo video was a part of the last even of the day at TOCFrankfurt and at that time I was in the back, with my laptop plugged in, finally checking my emails.

So, I missed the video which would have given me a clearer idea of how Bookshout’s importer is supposed to work.

Instead, I, along with many following on twitter, ended up confused as to how they were doing it, wondering what was being pulled in and how. In the end I just figured they were using some sort of bookmarklet-type solution and left it at that.

It wasn’t until the next day that it came up in conversation that Bookshout’s importer asks for the reader’s Amazon account and password.

Still reeling in disbelief I wandered out into the walkways (the only places in Frankfurt’s Buchmesse where the wifi seemed to be working) and checked out the video.

Sure enough, there it was, right in the video. Later I confirmed it in the client itself.

The mind boggles.

Why?

Because this is a phenomenally bad idea.

This isn’t like handing over your Gmail address and password to let a service scan your contacts (although that was and remains also a very bad idea).

Amazon is a payment processor. Every single Amazon account is backed by one or more credit cards. Handing over to any third party service your Amazon account and password is like handing your credit card over to a stranger and letting them take it into a back room where you can’t see what they’re doing with it.

Which is to say that it is a Very Bad Idea.

Even if you trust Bookshout implicitly you have no idea how secure their solution is. They may not be storing your details but they use them somehow. We don’t know if they post them to a server where the work is done, whether they cache them to increase the reliability of the process, how secure the password is throughout the process. We don’t know nearly enough for us to decide whether we can trust Bookshout. If they use their own servers as a proxy for the process, then those machines become a prime target for hackers. Compromising them would give them instant access to a host of Amazon accounts and their associated credit cards.

The servers and processes of payment processors like Amazon are audited and vetted. Nobody is auditing Bookshout’s importer. Certainly nobody with experience in securing components that deal with financially sensitive information. Bookshout is a new company with an unproven security track record. Anybody who implicitly trusts that they haven’t made mistakes is being a fool.

Treating Bookshout’s password phishing as a legitimate tactic also trains users into thinking that it is an acceptable tactic in general. The more services that ask for your Amazon login details and get away with it, the easier you make it for criminals to set up fake services (or even real services built specifically to harvest Amazon accounts) to steal those details and misuse them.

We need to make it clear to the public and to the industry that this tactic is both risky and irresponsible. I’d even go so far as to say that the sooner it is stopped the less likely it is to inspire others to make the same mistake.

***

Updated 13 October 2012.

Jason Illian of Bookhout has replied to some of these points over in the comments on the Tools Of Change blog. I tried to post some of the following in the comments but it hasn’t appeared yet.

He only replied to some of the points, mind you. Not all of them. He doesn’t address the precedence issue (if Bookshout is allowed to do it, others will follow). And, like others, he claims that because you can’t access full credit card numbers through your Amazon account, it must be safe to give them access to it.

Never mind that even revealing the last four digits of your credit card is not really secure.

As far as I know, Amazon has since closed part of that loop by not giving out the last 4 digits of a card over the phone unless they have had some sort of confirmation of identity, but this opens it right up again.

It highlights the real problem: you can’t predict how, exactly, account access will be abused. You can’t tell the difference between innocuous information and sensitive information. Very few can because we never have a full picture of how all of the various services in our lives interact with the information in our lives. It’s the reason why security on the web is such a mess.

(Well, that and the fundamentally insecure design of all web technologies and the complete disregard for security shown by most developers. And a surprising number of people responsible for developing standards and specifications don’t seem to give a hoot either.)

It’s the nature of a payment processor to store sensitive information, not just the credit card number, but also addresses, order histories, and more. That is to say, when security-minded grumps like me talk about credit card info, we aren’t just talking about the credit card number.

That’s without getting into the damage that can be done just using the ecommerce system as other commenters have pointed out.

An Amazon account can be used for anything ranging from ecommerce, to payment on third-party sites, to maintaining and controlling anything on Amazon Web Services.

It simply is not safe under any circumstance to give your Amazon account and password to a third party service. This is an unarguable fact.

Give it to your wife and kids, sure, but not a third party service.

Even if we do trust Bookshout completely and implicitly, letting them ask for Amazon account details normalises the practice. Which means they won’t be the only ones doing it. And users have no way of telling the good actors (like Bookshout) from the bad actors (criminals) from the incompetent actors (which would be most of them). If we condone the practice, users are going to trust them all.

We can’t make exceptions just because we like the people responsible. Bookshout can’t go the Mint route and rely on a host of outside auditing. And, as I understand it, the account aggregation done by Mint is based on that of Quicken’s (they used to use Yodlee, but switched after Intuit bought them) and many banks have historically bent over backwards to support Quicken due to its market share. Both Mint.com’s and Intuit’s track record and focus on security places them in a completely different category and position to Bookshout.

Comments

Not ignoring anything...

Hi Baldur. I get the 4-digit issue. I read about it awhile back too. I encourage you to go back and read it again, particularly the part where Mat talks about how tech support from both Apple and Amazon compromised his accounts. IOW, the breach wasn't due to the fact that Amazon shows the last 4 digits of your credit card; it was due to the fact that their tech support people intervened. Further, Mat made the unfortunate mistake of using the same credit card for both his Amazon and iTunes accounts. Since each party offers/uses partial elements of the number it's quite possible to pull the two together and create a breach, which is exactly what happened with Mat.

So you have the human element...same as you do every time you had your card over to a waiter at a restaurant. And you have the multi-account element. FWIW, I use different cards for each of those two accounts so this shouldn't be an issue for me.

As I've said before, I imported my Kindle library to BookShout and have had no security issues since. Could one pop up in the future? Absolutely. But it could happen because of any one of a number of things, even from using my credit card at a restaurant last night. That's not going to keep me in and hide out though. :-)

Yes you are ignoring my points

Baldur Bjarnason's picture

Like, for example, the following:

1. The precedence issue. Bookshout may be an honest actor but as soon as this tactic is normalised it will be adopted by others and users have no way of telling the honest from the dishonest (or the incompetent). A practice that may well be acceptable if done by a trusted actor can also be unacceptable as an industry practice. And if Amazon import is as useful a feature as you make it out to be, then it will be adopted by others..

2. Information leak. We have no idea about how various kinds of senstive data interact across services. The Amazon-iTunes vulnerability in the case I mentioned is an example of a type of vulnerability, not a specific vulnerability. An amazon account contains a multitude of info, a lot of which could be considered sensitive (addresses, for example). Like I said earlier:

"You can’t tell the difference between innocuous information and sensitive information. Very few can because we never have a full picture of how all of the various services in our lives interact with the information in our lives."

3. Damage. An Amazon account is used for a host of things, many of them can cause damage. It's not just a question of ecommerce but also payment services across a variety of platforms, server management, services on demand, and more. Somebody with access to your amazon account, even for a short time, can do a lot of damage.

I made all three points in the post above. You haven't addressed any of them.

Asking for a user's account details and password for another service is rarely acceptable and always insecure. You can get away with it in special cases but it's also one of the foundations that the online criminal economy is built on. Anything that trains users into thinking that handing over their passwords to somebody that isn't the original service opens the field up to criminal abuse.

Bookshout's use of this anti-pattern isn't really in question. I'm sure they are doing a good job of it. The practice is unacceptable in principle because, even though the risk of an individual actor (Bookshout) can be mitigated, the risk that results from this practice once it sees more widespread use cannot be mitigated.

That is, there is nothing Bookshout can say or do that will make this acceptable because this is fundamentally an ecosystem risk.

You're ignoring everything in the update

 

You are ignoring everything in the update (see the part that comes after "Updated 13 October 2012"). That update was written as a reply to Jason Illian's follow-up comment and I tried to post it to the ToC blog but for some reason it won't appear. It addresses all of the reasons why this isn't a bad idea that you and Jason keep ignoring.

The update specifically addresses the 4 character issue (not as safe as you think), and why it isn't secure or right to do even if we assume that Bookshout is doing everything properly.

He ignores the precedent it is setting. It ignores all of the damage an ecommerce system can do without revealing the full credit card number. It ignores everything you can do with an Amazon account.

My assumption is not wrong. You're just ignoring it.

 

Your assumption about credentials is wrong

jwikert's picture

Hi Baldur. I did a bit of digging into this and wanted to point out that your assumptions on the security of the BookShout system are wrong. If you've got an Amazon account you should log in and see for yourself. Amazon only displays the last 4 digits of your credit card. You cannot retrieve your (or anyone's) full credit card number by logging into Amazon.

BookShout CEO/Founder Jason Illian lays out the details here in this follow-up comment to a similar post on our TOC website: http://oreil.ly/Qi2F2Z

In short, the BookShout model really doesn't have a security hole. Ironically enough, the security of this import feature is strong primarily because Amazon does such a good job protecting everyone's credit card number. :-)

P.S. -- It was great chatting with you in Frankfurt the other day!

Post new comment

You will need to register to comment on Futurebook.net. Register here This will take less than a minute.
By posting on this website you agree to the Bookseller Comments Policy. comments go live immediately, please be relevant, brief and definitely not abusive.
Enter your FutureBook username.
Enter the password that accompanies your username.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <b> <i> <strong> <br>
  • Lines and paragraphs break automatically.

More information about formatting options

Type the characters you see in this picture. (verify using audio)
Type the characters you see in the picture above; if you can't read them, submit the form and a new image will be generated. Not case sensitive.