Know what’s cool? Being at Macworld/iWorld 2013 and getting to meet our wonderful customers!
Know what else is cool? Our cofounder Roustem Karimov getting interviewed by iMore’s Rene Ritchie on the show floor! There were even lights and cameras—the whole shebang. Thanks iMore!
Ever since we introduced URL scheme support in 1Password 4.1, app support has been coming fast and furious. First there was Launch Center Pro and Riposte, then came Felix, and today Tweetbot for iPhone and iPad, one of the most popular Twitter clients, has taken a seat on the 1Password Browser Express.
As of Tweetbot 2.7 for iPhone and iPad, you can now set 1Password (and even Google Chrome) as your default browser. Just go to Tweetbot’s settings to find this new option by tapping the account icon in the upper left, then “Accounts & Settings”, then Settings to see the new “Browser” section.
This means you can now tap a link in your tweet stream and automatically switch to 1Password to view it in the spectacular new Web Mode. If it’s a site you frequently comment on, you can use AutoFill in Web Mode to quickly log in and say your 2¢. Or, if it’s something you want to buy, you can use our new AutoFill support for Identities and Credit Cards to fill in your shipping and Credit Card information right from the palm of your hand.
If you don’t want to open every single link in 1Password, you can also leave Tweetbot’s “Open in Tweetbot” feature enabled. This will preserve what’s been the default behavior—opening links in the in-app browser—but it replaces the “Open in Safari” option from the action arrow with “open in 1Password.” Then you get the best of both worlds: the convenience of quickly browsing links within Tweetbot, but the option to open some sites in 1Password where you can use AutoFill for Logins, Identities, and Credit Cards. Everybody wins!
We’d like to thank Paul Haddad and Mark Jardine at Tapbots for making this happen.
Hooray, a TMO Editor’s Choice award!
We’re having a great time at Macworld/iWorld 2013 in San Francisco right now meeting customers and fellow developers face-to-face.
While we thought we had our booth all set up for the duration of the expo, I guess The Mac Observer disagreed. Yesterday, the fine folks over there made a significant contribution to our booth’s overall vibe by honoring us with a Editor’s Choice Award for 1Password for iOS!
We’re thrilled to earn this award this year and, as you can see in our photo gallery, we’re displaying it with pride. If you haven’t stopped by yet, I’m having a hard time understanding why. Besides today (Saturday, February 2) being the last day of the expo, you have the greater facts to contend with that you’re awesome, we’re told we’re awesome, and awesome people are simply bound for each other, so come say hi!
We won an award! We’d like to thank our customers, the academy, and rum!
Are you at Macworld/iWorld 2013? We sure are, in fact we’re at Appalooza booth 718-27 so come say hi! We’ll probably even shake your hand, look you in the eye, and strike up a conversation with you!
What’s that, you want some proof we’re at Macworld/iWorld? Alright, skepticism can be healthy. You’re on.
Here’s a few of guys who look like they work here, and they’re doing something to our booth pre-show.
Kyle, Jeff, and Khad finishing our Macworld/iWorld 2013 booth
Khad, our Social Choreographer, was on the ground early in the morning, of course. Here he is in his natural state, which means he’s probably helping customers on Twitter and Facebook or responding to email, but not watching where he’s going.
Khad probably tweeting to customers, also probably not watching where he’s going
Good news everyone! We have a few more photos in the gallery below, including a shot we are extremely excited and humbled to share—a real, live, non-photoshopped Editor’s Choice Award for 1Password for iOS from the fine folks at The Mac Observer!
Today is the day, ladies and gentlemen. While I won’t go so hyperbolic as to say it’s a day you’ll never forget, today is the day the expo hall doors of Macworld/iWorld 2013 open, and we’re at booth 718-27 so come say hi!
But whether you can swing by Moscone West in San Francisco or not, we wanted to help everyone celebrate Macworld/iWorld so everything we make is on sale during the expo! Are we crazy? No. But we have come down with a Macworld/iWorld 2013 fever, and our only cure is a 50% off sale on everything!
Whether it’s the all-new 1Password for iOS, 1Password in the Mac App Store, or 1Password for Windows or Knox from our AgileBits web store, everything is 50% off!
Yes, that means 1Password for iOS is just $8.99!
Yes, 1Password for Mac and PC are really just $24.99, and a single-user bundle license for both from our web store is just $34.99! Family licenses for each are $34.99 and family bundles for Mac and PC are $49.99!
Yes, Knox for Mac is just $17.99, and a family license is $29.99!
This sale lasts as long as Macworld/iWorld 2013 expo does. When the clock turns to 12 midnight Sunday evening, our sale prices turn back into a pumpkin. Wait, that’s not quite right, but you get the idea. If you’ve been waiting for those diamond 1Password and Knox slippers, now is the perfect time.
Whereby “shakes hands” I mean “gets cozy,” and whereby “cozy” I mean “builds in some really, really cool stuff you can do with 1Password.” Ok, enough of that.
We recently added support for URL schemes for developers and enterprising users to 1Password for iOS, and developers are all over it. Launch Center Pro and Riposte are two of the first apps to build in 1Password support, and today, Felix for App.net joins their ranks with a first of its own.
For those playing at home, App.net is an ad-free platform for doing stuff online. The first thing of that stuff is a messaging service that’s a bit like Twitter, and Felix for iPhone is a client that lets you get your messages on. It also happens to have a built-in web browser for perusing links your friends share, so as of the big Felix 1.4 update, you can now open some or all of those links in 1Password for iOS.
For starters, you can long-press on any link to get the option of opening it in 1Password; this is great for a per-link basis. But if you really want to go all the way, you can tap Felix’s dashboard button in the toolbar, scroll all the way down to Settings, scroll down to the bottom of said Settings, and flip on the “Open links in 1Password” option to make that the default for every link you tap in Felix.
In other words, yes: for all you customers who dreamed of the day when you can set 1Password as a default browser for all links, Felix is the first app to make it happen.
For bonus points, Felix still has your back if you opt to open links with the built-in browser but still want a quick way to log into a site when needed. Just tap Felix’s in-browser action button, then tap “Find in 1Password” to switch apps and automatically search Logins for the site you’re viewing in Felix.
We’d like to thank Bill Kunz at Tigerbears for adding such a great 1Password experience to Felix. You can get the excellent Felix 1.4 update now in the App Store.
Use 1Password to login to Riposte for App.net
Hey developers, know what your apps and 1Password for iOS have in common? They’re two great tastes that taste even better together, thanks to some of the URL schemes we added to 1Password 4.1 for iOS. Here’s how to get a little slice of 1Password into your apps to make the login and web browsing experiences even better for both our customers.
Without saying more than I’m allowed, we’re seeing fantastic interest from developers who want to build some 1Password support into their apps, so here is what we support so far:
There are a couple things we don’t support yet, but we’re looking at: the ability to search more than just the item titles, and a way to roundtrip the user back to your app once they do something in 1Password, such as copy data to the clipboard. For now, users need to use iOS’s default app switch method—double-tap the Home button, then tap your app to switch back.
Riposte for App.net provides a great example of how useful it is to integrate 1Password into your app. As a personal user and fan of App.net, I’m a pretty happy camper.
If Riposte finds that 1Password for iOS is installed (more on that in a minute), it presents a 1Password button right on the login screen! Tap it and you’ll switch to 1Password, where you can enter your Master Password (if necessary to unlock) and see that “app.net” has been auto-inserted in the search box to quickly filter results for you.
When using Riposte’s in-app browser, you can also tap the action arrow, then tap the 1Password option (again, the button only appears if Riposte sees it’s installed) to auto-search 1Password for the user’s Login for that site. This makes it easier for users to quickly use their 1Password Login for that site from within your app, instead of having to switch to another browser.
Of course, there is also Launch Center Pro, a fantastic iPhone productivity utility that has long had support for doing a few things faster with 1Password. It was the first to adopt our new URL schemes, so you can create quick actions to search 1Password for, say, the contents of your clipboard or a custom term, or open HTTP and HTTPS URLs in 1Password’s new Web Mode.
You’ll probably want our icon to place a button like you see in Riposte. Here is a pack of icons you can use, but get in touch if these don’t fit the bill. Update 4-19-2013: we updated this pack to include a couple monochrome icons at various sizes for things like the iOS sharing sheet.
The first thing you probably want to do is find out whether 1Password is installed. This should help:
if ([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"onepassword://search"]]) {
NSLog(@"1Password is installed!");
}
If your app uses a service that your users log into—whether it’s Twitter, App.net, or something homegrown—you can display a 1Password button and pass a search term with a simple URL like this:
onepassword://search/twitter
Or you can do it with code:
[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"onepassword://search/twitter.com"]];
This is also a useful way to let users switch from your in-app browser to quickly search 1Password for a Login for the page they’re on.
You can open URLs in 1Password (essentially like the ‘Open in Safari’ option) simply by inserting “op” in front of them:
ophttp:// or ophttps://
You can also use this code, then have UIApplication open that URL:
NSString *browser = [[NSUserDefaults standardUserDefaults] stringForKey:kPreferredBrowser];
NSURL *url;
if ([browser isEqualToString:"1Password") {
url = [NSURL urlWithString:["op" stringByAppendingString:urlString]];
}
Again, this is just the beginning. We rolled out this support in our recent 4.1 update and we’re already seeing quite a bit of interest and requests, all which we’re pouring over as you read this. If you have a good idea we’d love to hear it, though, so definitely get in touch so we can chat.
The fine folks behind Riposte open sourced their implementation of 1Password support. You can grab it on GitHub and fork it if you like. You could even spoon it if that’s your thing. We won’t judge.
Are you going to Macworld/iWorld next week? We sure are! There are going to be tech talks, a huge expo hall, surely a drink or three, and all the other great stuff that makes Macworld/iWorld a total blast.
In fact, the best part is that we have a booth this year! We’ll be in the Appalooza, booth 718-27, in the company of some fantastic fellow app shops. Whether you have questions, want to practice your handshake, or just want to come say hi, please stop by! From our agile roster, we’ll have:
Bonus points: Kelly Guimont, our Support Jedi and TUAW writer extraordinaire, is giving a Tech Talk Friday evening (TT853) called “Prepared vs Paranoid: Online Security And You.” Three guesses as to what at least one of the apps in her talk will be.
Of course, we can’t blame you if you make time away from our booth for the rest of the expo and some talks; it will all be well worth it. But be sure to stop by our booth and see us at Macworld/iWorld 2013!
Yes, featurecast. Not a podcast, kind of a screencast, but really, a featurecast: I want to use a little more than screenshots and smoke signals to show off some of the great stuff in 1Password, but still keep each video short ‘n sweet ‘n easy to digest. That means low-calorie, high 1Password nutrition, gluten-free.
Think 1:10 is short ‘n sweet enough for a featurecast of the all-new Web Mode in 1Password for iOS? Let us know on Twitter, Facebook, or in this forum thread.
I introduced HMAC (Hash-based Message Authentication Code) through the back door when talking about the Time-based One Time Password (TOTP) of Dropbox’s two-step verification. But TOTP is actually a peculiar way to use HMAC. Let’s explore what what Message Authentication Codes (MACs) are normally used for and why they play such an important role in the future of 1Password. If you guessed that MACs are for authenticating messages, you’re on the right track.
In a sense (but this is a lie), you can think of MACs as kind of like encrypting things that aren’t secret. The recipient doesn’t decrypt the data, instead the recipient verifies that it really was the data sent by the sender and that the data hasn’t been tampered with. MACs work with the sender and the recipient both sharing a secret key. (This is the key difference between MACs and digital signatures. With MACs, the sender and the recipient share the same secret key.)
Only someone with knowledge of the secret MAC key could have created the MAC for some data, and (unlike the case of digital signatures) only someone with knowledge of the secret MAC key can verify that the MAC is valid for the data.
Suppose my dog Patty (the clever one) leaves a warning for Molly (a simple dog) that says, “There’s a coyote in the back yard”. The message isn’t secret. Neither Patty nor Molly care who reads it. But now suppose that the neighbor’s cat, Mr Talk, in his attempt to get rid of Molly, changes the message to “There’s a squirrel in the back yard”. 
This would not be good news for Molly, who would blindly run behind the house, chase a squirrel up a tree and then bark at it for the next thirty minutes. Coyotes, however, do not climb trees; and so Molly would have an entirely different experience if she tried the same action against a coyote.
To avoid tampering with the message, and to prevent Mr Talk from sending a counterfeit message in Patty’s name, Patty and Molly can share a secret key which is used to create a MAC of the message. Suppose that Patty and Molly, ignoring earlier advice on creating passwords, have secretly agreed on the key (well, a password from which a key is derived)—”Kitty Smells”—for their MACs. When Patty constructs the message, she will calculate the MAC (and if she is using HMAC with SHA1 as the hashing algorithm) with ‘Kitty Smells’ as the password, the HMAC should come out as:
a3b3a8b79c135ff5b9a0aa6f5c304b411f07f90c.
Patty will leave the message, “There’s a coyote behind the house”. along with the MAC. When Molly sees a message, she should verify the MAC before even looking at the contents of the message.
If Mr Talk has changed the message to say “squirrel” instead of “coyote,” the MACs won’t match up. Mr Talk cannot create a valid MAC because he doesn’t know the shared secret password used to create the secret key that Molly and Patty have.
Sadly, Mr Talk’s trick will still work.
That is because as soon as Molly encounters the word “squirrel” she will react. All thoughts of verifying the MAC will be pushed out of her brain, which will now be entirely occupied by the single thought, “squirrel”. Indeed, if I were reading this aloud, Molly would have run out the back in blind excitement. This is why it is very important to not even look at the contents of a message before verifying its authenticity.
In this example, the original message isn’t secret and so didn’t need to be encrypted. But with authenticated encryption, we first encrypt the message with an encryption key and then compute a MAC of the encrypted text using an authentication key. Just as it was important for Molly to not do anything with the message until she verified the MAC, it is vital that we don’t try to decrypt an encrypted message before verifying the MAC. This system is called “Encrypt-then-MAC”, but the emphasis should be put on the other end of the process. I like calling it “Verify-then-decrypt”.
A scheme like Encrypt-then-MAC that both encrypts a message and provides authentication (proof of who it came from) is called “authenticated encryption”. Encrypt-then-MAC isn’t the only secure authenticated encryption scheme out there, but it is the one that we use in the 1Password 4 Cloud Keychain format.
You might think that there is no reason to authenticate encrypted data. After all, the data was encrypted with a secret key, so if you can decrypt the message with that secret key, then you know it only could have been encrypted by someone with knowledge of the secret key. Many people have thought that, but they were wrong.
Suppose that Molly sends an encrypted message to Patty, but doesn’t use authenticated encryption. Now when Patty gets a message from Molly she decrypts it. If the decrypted message is garbled in a specific way, Patty tells Molly that it didn’t decrypt properly and that Molly should send it again. If it isn’t garbled in a particular way, Patty will just let Molly know she got the message.
Mr Talk can listen to this exchange between Patty and Molly. Without the secret encryption key, Mr Talk won’t be able to figure out what is in the message that Molly sent to Patty. But now suppose that Mr Talk is able to send encrypted messages (seemingly from Molly) to Patty. Mr Talk can send Patty modified forms of the message that Molly sent and find out whether Patty got a garbled message when she decrypted it. Mr Talk makes small changes to the original encrypted message to create a bunch of new slightly different encrypted messages. By finding out which ones are garbled and which ones aren’t, Mr Talk can actually decrypt the original message. This is a type of “Chosen Ciphertext Attack (CCA)”. It is called this because the attacker is able to choose ciphertext for the recipient to attempt to decrypt.
Now, the particular attack that Mr Talk used depends on the precise details of how Patty determines whether a message was garbled. That means changing those details can defend against this particular attack. Those who are familiar with all of this will know that I’m talking about the “padding oracle attack”, and will know that it can be defended against by using different padding or using a different encryption mode. But such a defense only addresses this particular attack. Is there a way to defend against all CCAs, even those that haven’t been invented yet?
The good news is that it is possible to defend against all Chosen Ciphertext Attacks. The way to do that is to properly use authenticated encryption. Padding or other “oracles” are not a particular threat to 1Password, as there is no back-and-forth exchange in normal operation. These sorts of attacks are practical when there is an automated oracle on the network or in a specific device that will attempt to decrypt ciphertext on demand. In 1Password, there is no opportunity for an attacker to set up the kind of dialogue needed for this kind of attack. But we also know that theoretical weaknesses have a habit of turning into exploitable weakness over time. So we look ahead, and build authenticated encryption into 1Password now.
I am pleased to say that no harm came to Molly or the coyote. She was on her leash, and you can see in this staged and contrived photo that I was – just barely – able to restrain her from running to her doom after a coyote. However, our attempts to teach her that she must verify messages before she does any other processing of said messages have not gone well.
