Posts Tagged: iphone

KEYBOX 3.0 Is OUT — And FREE for 3 Days!

I’m pleased to announce the immediate availability of version 3.0 of KEYBOX, the best app for keeping all your secrets safe!

It has been nearly a year since the last update (v2.4.1) and this update is BIG.  No pixel was left untouched and much of the app was rewritten and optimized!

New KEYBOX 3.0 Icon

Here’s what’s New in Version 3.0:

  • Brand new UI supporting iOS 7 and 4″ Retina Display iPhones!
  • Can now directly and effortlessly sync secrets between KEYBOX equipped iOS devices.
  • Can now import/export via email (for users with Wi-Fi networking issues).
  • Can now resume where you left off when returning to KEYBOX.
  • New, easier-to-read export file format!
  • Can now rename and delete all entries in a secret, not just the custom fields anymore!
  • 25% more common passwords included in dictionary to help users avoid them.
  • Many bug fixes.
New KEYBOX UI

And to celebrate reaching version 3.0, KEYBOX will be FREE for the first 3 days of release (Nov 19th ~ Nov 21st 2013).  Afterwards it will return to its very affordable price of $2.99 USD (or equivalent amount in other currencies).

So if you still don’t own KEYBOX, don’t wait, grab it now and enjoy unprecedented privacy on your iPhone!

Fingerprints, Biometrics and Passwords – Looking Back To See The Future

iPhone5 biometric flaw

On September the 10th, Apple unveiled the new iPhone 5S in its music oriented September keynote presentation.

Just before the 1 hour mark Senior VP of Hardware Engineering Dan Riccio appeared in a promotion video and stated:  “Your fingerprint is one of the best passwords in the world. It’s always with you and no two are exactly alike.”

Privacy is one of my chief concerns and passwords are my specialty.  As much as I am a fan of Apple I have to call this statement erroneous at best. I’d like to explain why…

The most crucial hallmark of a solid authentication system is that it relies on a secret to verify your identity.  This has always been true, even before the advent of computers.  Fingerprints are not secrets.  It’s literally that simple.

In case you weren’t already aware, you’re leaving your fingerprints everywhere you go. Pick up your iPhone right now. How many prints do you see on the screen?  I can see four on mine, two of which are rather fresh.

 

Hating on Passwords

Yes, passwords are a pain.

Nobody will contest this. Not a week goes by without some enterprising startup promising to kill the password off once and for all. To much applause I might add.  From single sign-on systems and biometrics to simple dongles that use physical possession to prove your identity, ALL have failed and the password has lived to see another day.

Obviously as the developer of KEYBOX, a password and secret management app, you’d naturally think I was biased on the subject.

Quite the contrary however. If somebody does come out with a non-password authentication system that is truly secure, works everywhere and with everything, doesn’t lock me into a single vendor, and cannot be lost or stolen I will gladly stop development of KEYBOX and present a fist full of dollars at him/her.

It just hasn’t happened yet.  Passwords, for all their faults, do make for excellent secrets.


So is Apple’s iPhone 5S the chosen one?

I’m afraid not.

It’s only been about one week since the iPhone 5S’s release and hackers have already bypassed its TouchID technology simply by lifting fingerprints. What was once the sole domain of James Bond and Maxwell Smart is no longer.

Granted, you have to be dedicated to lift prints off a glass surface.  But if somebody steals your iPhone he has all the time in the world to try.

 

Unintended Consequences

What concerns me most are all unintended consequences of this technology.  We’ve already seen images like the one above where a family member takes advantage of your sleeping to break into your iPhone. Yes, it’s meant to be comical but such cases are nonetheless real.

Consider the less comical scenario where a stop-and-frisk police officer grabs your hand and forces your thumb against the iPhone 5S’ home button against your will to gain access to it.

Sound paranoid? In nations where forced confessions of innocent people occur why wouldn’t this happen too? Perhaps gaining access to your camera roll could expose embarrassing photos the police could then use to coerce and bribe you.

The possibilities are a bit frightening.  In all my years in this industry I’ve learned one absolute truth:  If technology makes something possible it will happen.  We’re only one week into this technology so expect to see more developments as people gravitate towards it.

In Closing

I’ll give Apple some credit here. It certainly managed to not repeat the Windows fingerprint reader debacle of last year and by storing the fingerprint within a cordoned off section of the CPU it is demonstrating that it does want to protect our security/privacy.  Apple also made the wise decision not to expose this functionality to 3rd party app developers, some of which cannot be trusted with it.

Now, let’s say Apple eventually augments/fixes its TouchID sensor technology to discern between real and fake thumbprints, and most iPhone 5S users adopt it.  It still will not kill off the venerable password.  It doesn’t change the fact that a fingerprint is not a secret.

At best, fingerprints will be a novelty used by people who just can’t be bothered to learn about real security.  Of course, fingerprints combined with passwords offer more security but most people will quickly realize that fingerprint scans just slow us down if we’re still relying on passwords.

I’ve seen it all and I believe the past tells us the future of security.  More than ever I’m confidently putting my money on passwords going on to see yet another day.

Momiji 1.1 Released

Momiji icon

Momiji 1.1 for iPhone and iPad was released today.

This version corrects a bug impacting the importing of bookmarks from Firefox (HTML file exported by Firefox) due to memory over-consumption.  Other aspects of the app were improved as well.

Momiji 1.1 for Mac has been submitted to Apple and currently awaits review.  I’ll post here again when it’s ready.

In the meantime, users of the iPhone and iPad editions of Momiji are recommended to upgrade at their earliest convenience.

UPDATE: (2013-09-20) Momiji 1.1 for Mac is now released and ready for download.

 

Momiji picked up by MacUpdate!

This is just a quick “Thank You!” to the fine team at MacUpdate for promoting Momiji to its readership.

I’ve always wanted to have one of my apps mentioned on MacUpdate and, well, now I do!

Readers can see the page here.

Landmarked Discontinued

Just a quick note that I’ve decided to discontinue development of Landmarked, my location/map app for iPhone.

With the advent of iOS 6 and numerous competing apps, Landmarked was not seeing very many downloads of late.

I want to thank users who did download Landmarked for their support and inform them that technical support for the app will of course be available and that the linking/sharing service will remain active for one more year (Until the 4th of July, 2014).

Going forward, I’ll be devoting all of my time to KEYBOX, Accent and my latest app which is currently undergoing review and will be released shortly.

KEYBOX 2.4.1 Released

KEYBOX 2.4.1 was released today.

This version corrects a bug where the password strength checker did not indicate the strength using colors (red = weak, blue = safe) in iOS 6.0 and also addresses overly repetitive memory warnings on some screens.

It is recommended that users upgrade at their earliest convenience.

KEYBOX 2.4 Released

KEYBOX 2.4 was released today.

It adds support for selecting preferred language, a much improved image viewer, import/export functionality enhancements and UI improvements.

I hope users will enjoy this new update and all are recommended to upgrade at their earliest convenience.

KEYBOX 2.3 Released

KEYBOX 2.3 was released today.

It adds support for the new iOS Chrome browser (when launching a page externally) and features numerous improvements and a small bug fix.

Users are recommended to upgrade at their earliest convenience.

Why There Won’t Be a 7″ iPad Mini

Today Daring Fireball’s John Gruber linked to a bunch of iPad mini related news/rumor articles. He doesn’t 100% commit to believing an iPad mini is in the works but rather entertains the possibility from the business/manufacturing perspective.

I wanted to provide a developer’s perspective on the matter and state that I don’t believe Apple will produce a 7″ iPad mini.

Firstly, I agree with John in that if Apple wanted to it could create an iPad mini.  It’s certainly not a question of technical ability.  If Apple were to produce an iPad mini there are two obvious ways to do so:

  1. Squeeze the existing resolution into a smaller physical screen.
  2. Reduce the resolution but maintain either the iPad 2′s or the new iPad’s PPI.

Number 2 is the most feasible from a manufacturing standpoint.  Unfortunately however, both ways screw the average iOS developer over.  If Apple is adamant about creating an iPad mini it will have to confront the issue of fragmentation.

Tim Cook has already stated the obvious in that it doesn’t make sense to introduce a new resolution at this time. He’s right. To do so would fragment the iOS platform.

When the original iPad was released it introduced an element of fragmentation in iOS (née iPhone OS). But it did so in a subtle and clever way.  The original iPad got around the issue of deviating from the iPhone’s resolution by allowing a 2x mode for apps originally designed for the iPhone. This meant that, from day one, there were plenty of apps ready for use, even if not optimized for the iPad. Moreover, being the first compelling tablet platform, iOS developers also had an incentive to adopt the iPad platform because it represented a sweet spot between traditional desktop computing and mobile computing.

Introducing a 7″ iPad, assuming it would reduce the resolution, would introduce an app vacuum. That is, current iPad apps would not be able to fully display themselves on a reduced resolution screen. Apple will not introduce a device without a healthy selection of apps. To do so would invite ridicule from the Android camp which already has 7″ tablets with tons of apps ready, and which would love nothing better than to prove Steve Jobs wrong when he stated that the 7″ form factor is not optimal.

In my opinion, this leaves us with the possibility of a squeezed PPI.

One factor I never see journalists/bloggers mention is the fact that Apple recommends to developers that interactive components such as buttons/icons be at least 44×44 points. This is no magic number, on the original non-Retina display iPhone it represents the size of the average finger when pressed to screen.

At the various iOS device PPIs, a 44×44 button occupies between roughly 1/6th of an inch to 1/3rd of an inch (or 34mm to 85mm).  If an iPad mini does not employ a Retina display as does the New iPad with its 264 PPI it might work.  The iPad 1 and 2 both share a 132 PPI screen, the lowest of any iOS device.  Bumping the PPI up to accommodate a 7″ device may require a new PPI (depending on its final size) but would still allow for accurate tapping.

So what’s keeping this from becoming reality then?  Simple, anybody who has used a Retina display iPhone, iPad or MacBook Pro knows all to well that it ruins your ability to go back to non-Retina displays.  It’s too late for a new non-Retina display iPad form factor.

 

In Closing

In my opinion, the multitudes of form factors we see for the Android meta-platform are born out of a need for device makers to differentiate themselves from their competitors and to cut costs more than they are to appease actual customer demand. Unlike Android device makers, Apple doesn’t need to throw 100 ideas at the wall to see what sticks. Anybody who has been following Apple knows that’s not their way.

From a marketing perspective I’d even go as far as to argue that having an iPad that fits in your pocket is the exact opposite of what Apple wants. Here in Tokyo, people walk around with their understated Apple logo displaying iPads in hand the way they would hardcover books or magazines. You can’t pay for that kind of advertisement.

Of course I could be wrong but ultimately I don’t see a unique and compelling case for anybody to adopt a 7″ iPad and that is why I believe Apple won’t either.

KEYBOX Sale Coming To An End

KEYBOX, the first prosumer-quality digital privacy app for the iPhone, will be celebrating its first year of being in the App Store on July 27th!

The experimental sale that began in February will also be coming to an end on July 26th. As of July 27th the new price will be $2.99 US.

To everybody who purchased KEYBOX, thank you for your kind support!  Even more great features are in the works and I believe you’ll be quite pleased with them!

To those of you still on the fence about purchasing KEYBOX now is your chance to get it at its current reduced price of $1.99 US.

Protect your privacy, Get KEYBOX today!

 

Collecting Install Base Statistics

A notice to users of my apps, starting with KEYBOX 2.2.1, Accent 1.0 for iPad and Accent 1.1 for Mac I am collecting install base statistics.

The Story

Recently I had difficulty reconciling the rankings of my Accent app in the Mac App Store and the sales results in iTunes Connect portal.
On its opening day Accent was ranked #1 in the Mac App Store’s Reference category in Japan, even beating out renown apps like Delicious Library 2 among a whole host of others.

Number 1 app in reference category
However, when I saw the sales numbers I was shocked. I expected to see hundreds of sales but I only got 2 in Japan. Yes, two. I let it slide for a day thinking the results would be reflected by the next day. No such deal.

I approached Apple support to ask which wasn’t working, their ranking algorithm or their sales tallying. I’ve had apps rank #1 in a different content aggregator before and know what to expect.  Surely an app with only 2 sales could not have reached #1 placement I thought.

Following this thought, an app at #1, even if accidentally placed there, should see a flood of sales the next day because of its high placement.  This flood never happened.

Apple gave me the below response that ensured their ranking algorithm was in working order but neglected to answer whether the sales count was correct.

App ranking support mail
Since this time I’ve come to understand a bit about how Apple ranks apps and have arrived at the unescapable conclusion that either their system is broken or the Reference category under which Accent was categorized is a near ghost town.  It’s not in Apple’s best interest to tell me which is the case of course.

This isn’t the first time I’ve had issues with the slightly buggy iTunes Connect portal but every time I approach Apple about errors/discrepancies I go in not knowing anything. The whole portal is a black box to me and to every other developer.

I’ve decided to arm myself with information from now on! Introducing the statistics collector!

How Statistics Are Being Collected

This is how it works: My server is notified each time one of my apps is executed for the first time or when it is upgraded. Just to be absolutely clear, this notification contains ZERO private information. I don’t see anything that would identify you.
So what does get sent?

  • app name
  • app version
  • device type (iphone, ipad, mac)
  • os type (ios, osx)
  • os version
  • locale
  • first execution time
  • is upgrade? (Y or N)

That’s it! No UDID. No snooping around in your address book. No thumbing through your photos.

Here’s the web request showing me running KEYBOX 2.2.1 for the first time on my iPhone (fresh install):

GET xxxxxxxxxxxxxxxxxxx?app-name=keybox&app-ver=2.2.1&first-exe=20120514072247&dev=iphone&os=ios&os-ver=5.1.1&loc=ja_JP&upgrade=n HTTP/1.1

As you can see, there is nothing private or sensitive here.

What I Learn From These Statistics

This system isn’t perfect. It doesn’t accomplish my goal of knowing how many sales I made. It only tells me when my software is installed on a user’s Mac or iOS device. For instance, users who purchase KEYBOX on their iPhones are also entitled to install it free of additional charge on their iPads and iPod touches. In this case I’ll see 3 installs for one purchase. In fact I won’t even be able to tell if the same person is installing KEYBOX in all 3 devices.

However, if I see 1000 installs but only 5 sales then I know something is not right and can approach Apple with this information. After all, nobody has 200 iOS devices at home. This system is about seeing such wide discrepancies.

In Closing

I have updated the KEYBOX privacy guarantee to reflect the new behavior mentioned above.

I appreciate everybody’s understanding in this matter and I hope I’ve addressed any concerns you might have by this change.
If you have any questions please do no hesitate to contact me at jay [AT] this here domain.

Thank you in advance,
Jason Fuerstenberg

KEYBOX 2.2 OUT

KEYBOX 2.2 is now out at last!

This update improves importing speed and robustness and introduces a new face for KEYBOX, a more high-tech one that embodies the advanced techniques KEYBOX uses to keep secrets securely encrypted.

New KEYBOX Icon

I’ll be commenting more on the icon design later.  For now I encourage all KEYBOX users to upgrade to the latest and greatest version!

My Modest Rig

Inspired by Chris Eidhof’s “I USE THIS” post, I decided to post about where the magic behind my apps happens.

My Environment:

  • Mac Mini (2011 model - 2.5GHz, 4GB of RAM, Radeon HD 6630 video card)
  • White MacBook (2007 model – I forget the specs but they’re not so impressive)
  • Wi-Fi  (AirMac Extreme, not in picture)
  • USB SuperDrive
  • 2 23″ monitors (1 DELL, 1 SAMSUNG)
  • iPhone 3GS 32GB, iPod touch 8GB, iPhone 4S 64GB (taking this photo)

My office My Flow:

Dual monitors is a god send for me.  I spend most of my day in Xcode and its usually on the left monitor and whatever I’m making is on the right. Safari on the right when I’m looking something up.  Also when using inkscape I can edit the XML in one monitor and see the visual changes in the other.

The only downside from having a dual monitor setup is my system’s video performance is a bit slower but I don’t use my Mac for gaming and video playback is sufficiently good.  The productivity gains more than make up for it.

I used to have a Power Mac (Dual G5s) that performed great for 8 years but was a bit noisy in summer when all the fans would turn on (burning G5s!).  This Mac mini is ninja-silent and fits directly under/between my monitors.

My Software:

  • XCode I spend most of my day in it.  Aside from the app distribution song and dance I’m quitecomfortable in it.  It doesn’t hurt that I’ve been using it since 2007.
  • GitBox * Great Git client by Oleg Andreev.
  • Safari + Chrome My preferred browsers.
  • Coda * I’m hardly an HTML expert but Coda is where I pretend to be one.
  • MarsEdit * Where all my WordPress posts, including this one, are written.
  • Acorn * + Inkscape Where most of my graphics are made.  Acorn is a great raster image editor and Inkscape is forthe vector stuff.  Inkscape is a capable SVG editor but very Linux-y and it shows.
  • TextWrangler My text editor of choice.
  • DropBox For moving files between machines.

* I try to support indie developers as much as possible.  They go above and beyond and I want to reward them for it.  The developers in question here are all stand up guys.

LandMarked – 5th Place In Israel’s App Store Navigation Category

My latest iPhone app, LandMarked, has been steadily climbing the charts of many nations’  App Stores and today a first has happened for me.  LandMarked made it to 5th place in Israel’s Navigation apps category (225th place worldwide)!  This places it in the first 25 apps list and just on the fold of the App Store’s listing.

Not bad considering that I only release formal PRs to Apple related news sites and don’t engage in banner image advertising of any sort.

I want to thank all the iPhone and iPod touch owners in Israel for helping LandMarked climb so far this fast!

 

KEYBOX Experimental Sale

Just a small post to say that I have decided to conduct an experimental sale to test volume pricing with KEYBOX.

Starting today, KEYBOX will be sold at $1.99 USD, down from $4.99!  (A 60% mark down)

I’m not sure how long this sale will last or if it will be a permanent move.  If the new volume pricing resonates with more customers then I’ll consider keeping it low.  Naturally, if there is little change I’ll go back to experimenting with a higher price point.

KEYBOX has been a labor of love for me and I want to see it benefit as many people as it can.  For those who have been on the fence about whether to buy KEYBOX or not… NOW IS YOUR CHANCE!  KEYBOX will never be more affordable than this!

 

Keybox search

Introducing LandMarked

Today my newest iPhone app, LandMarked was released worldwide on the App Store!

What is LandMarked?

Have you ever had trouble getting back to a place you were introduced to by a friend or you accidentally stumbled upon?  I have, and I created LandMarked to solve this problem.

LandMarked lets you instantly and easily drop a point on any location, take a photo of it, write some notes, rate and categorize it.  Even if you forget where it was, LandMarked won’t.

The rule for using LandMarked is simple:  If it’s worth coming back to, it’s worth marking down.  And if it’s a really great place you can even share it with friends too.  LandMarked is not a social network, but it lets you tweet or mail any place you know people will love.

It’s that simple!  So what are you waiting for?  Get LandMarked today for your iPhone (it’s FREE!) and start making your mark!

Learn more about LandMarked…

ListEdit

 

Wither KEYBOX lite?

Now that KEYBOX 2 is slated for release later this month, I am announcing that KEYBOX lite, the 30-day free trial edition, will be dropped.

The purpose of the lite edition was to demonstrate the full edition’s power, quality and professionalism to those who were on the fence about buying it.  However looking back at the download-to-purchase ratio, I’m not sure the lite edition was ever really necessary, and if anything, may even be hurting sales.

Although the lite edition can only be used for 30 days, it doesn’t auto-destruct and will remain installed until the user removes it.  I suspect the mere presence of the KEYBOX lite icon on people’s iPhone dashboards endows a false sense of security regardless of whether the app is used or not.  By removing the choice between lite and full editions I’m asking would-be-downloaders to decide upfront how serious about security they want to be.

People who really understand the importance of digital privacy and security tend to already be victims and don’t need a demonstration.  They are glad to pay just about any price if it means avoiding the hassle and stress of remembering and resetting all their site accounts and PIN codes before it’s too late.

People who have yet to personally feel these pains fall into two categories: those who know they never want to, and those who don’t give it much thought.  Chances are that those who don’t give their own security much thought will not have arrived at my website in the first place so I’m not overly concerned about them.  I want to reach those who are looking into being more secure and are now comparison shopping between KEYBOX and the alternatives.

 

In the end, security is up to each user and even if you purchase KEYBOX, you may leave it on your iPhone without using it but I would urge you to get value out of it on a daily basis.  It’s an investment in your own security.

Removing KEYBOX lite is something I couldn’t foresee myself doing back when I released it but in retrospect makes perfect sense from a security standpoint as well as for sales.  I hope users will understand.

 

If you have any questions or concerns regarding this decision please feel free to let me know at support@jayfuerstenberg.com.

KEYBOX 2 Submitted To Apple

After weeks of testing KEYBOX 2 against iOS 5.0 and the new iPhone 4S as well as fixing some bugs introduced by both I’ve finished testing and finally submitted KEYBOX 2 to Apple.

Barring any approval process snafus I expect to release it Saturday Dec 17th 2011, just in time for the year end holidays!

Release 2 is of course a free upgrade from the first release and users purchasing it now will not have to pay twice.

 

I want to thank all the people who’ve expressed their enthusiasm for the next release for their continued patience.  I hope to make more incremental releases in the future.

Stay tuned for the release 2 and the new revamped website that will accompany it!

AU To Carry The iPhone 5 In Japan!

According to this Yahoo Headlines Japan article, KDDI has revealed on September 22nd that it has officially signed on to carry the next-generation iPhone under its AU carrier brand.  AU will sell the iPhone 5 (tentative name) in October.

The old one-carrier-per-country model previously favored by Apple is being abandoned in its bid to better compete with Android which is supported by all 3 major Japanese carriers.

It is expected that this move will have a deep impact on current smartphone shares for iOS and Android.

Also, it is curious that NTT DoCoMo was not the next carrier to offer the iPhone as its network is much better prepared for it.  Prior to the arrival of smartphones, AU was better known for its less-is-more strategy and its limited 3G network rollout as a reflection of this.  It’s clear that KDDI has cemented its reversal of this strategy with this announcement.

Interesting times ahead!

Portable Media Security

David Harley has written a thoughtful post at ESET ThreatBlog on the insecurity of portable media like CDs and USB thumb drives.

Portable media, by virtue of its portability, is obviously more prone to loss and theft than say, stationary desktop computers.  For this reason it is crucial that encryption be used to protect any data stored by these devices.

With the advent of the iPhone equipped with encryption apps, we would hopefully see less incidents of private data leakage.  Ultimately it is up to people to be aware of the options and risks, and to make the proper choices.

Choosing a Safe Password

A lot of opinions about what makes a password strong have been thrown about lately.  Unfortunately, a lot of them are wrong.

If you only take away one thing from this article let it be this…  Don’t believe everything you read about password best practices.  Today I’m going to dispel some of these myths and I want to tackle 2 approaches in particular that concern me.

 

Correct Horse Battery Staple – http://xkcd.com/936/

This comic has been linked to a lot since its release and at least gets points for trying.  The only problem with it however is that it relies on common dictionary words.  According to Oxford Dictionary there are 171,476 words in current use in the English language.  If we were to assign a unique number to each of these 171,476 words and use a 4-word combination of them we’d end up with a truly staggering amount of combinations to exhaust!  Problem solved right?

No.  The average English speaking person can’t even spell “hippopotamus” correctly and is limited to a vocabulary of 25,000~50,000 words (this number varies depending on demographics, education level etc… and is still disputed).  And of these, most people limit themselves further to words dealing with their daily lives: “coffee”, “office”, “stapler”, “fire” and other equally common words.  That is if they are not completely lazy and go with “password123″.

What we end up with is maybe 500 highly common words that would form the pool from which to construct such pass phrases.  500 words in 4-word combinations is just under 62.5 trillion combinations.  Sounds great right?  “My little brother will have to pass the work onto his grandson before my password will be discovered!” I hear you say.  Except with a technique called brute force searching, 62.5 trillion combinations can be computed in significantly less time.  In fact, the more patterns a hacker can discern from your word choice the smaller the search space and the process will speed up accordingly.

Furthermore this approach does not scale.  There are only so many nonsensical word combinations a person can remember.  After a while they begin to diverge and soon you can’t tell if it was “house ball sky dog”, “ball cucumber torch pin”, or “house pin sky torch”.

 

Memorable Passwords – http://lifehacker.com/184773/geek-to-live–choose-and-remember-great-passwords

First let me say that I have a tremendous amount of respect for Gina Trapani.  But this time I’m afraid she is wrong.  Why?  Again, patterns.

What makes the password memorization technique she advocates easy for you to use makes it equally insecure for hackers who anticipate that you’ll follow her advice.  Using public knowledge like a spouse’s name or your anniversary date is questionable at best.  If I know you, chances are I know your spouse.  Even if I don’t know you I can dig through your trash and find out.

The only way this excels compared to the XKCD approach is that it’s easier to associate a password to a web site because there is an underlying pattern uniting them, not that this is a good thing remember.  It’s just harder to get confused.

 

What Makes A Password Safe?

The short answer: randomness.

The long answer:

  • Don’t use patterns.
  • Use nonsensical words or sensical ones, whatever you like.  Don’t follow a rule.
  • When possible, don’t limit yourself to how you choose your passwords.
  • Use numbers, punctuation, spaces and even Kanji characters if you feel like, or don’t.
  • Go short or go long.  The choice is up to you.

Remember, from whom are you trying to keep your password safe?  Your nosy siblings and coworkers?  Or somebody more nefarious like a hacker?  Your password is only as safe as it is unknown to people who would attempt to discover it.  Understanding the discussed tools and knowledge they possess should demonstrate why just about all the advice flying out there is flat out wrong.

 

 

But It’s Still Too Hard To Remember “e$-UqPs3″

That IS hard to remember, there’s no contesting that.  But again, what makes it hard for you to remember makes it more secure.  A hacker is still going to pull out the brute force search here and will perhaps arrive at your password.  However this password is stronger if for no other reason than it has no discernible patterns.

Moreover, if you occasionally change your password it becomes a moving target.  By the time the hacker finds your password, you’ve already moved on to a new one!

How should you remember this password?  Don’t.  There’s an iPhone app for that! All you need to do with this app is create one memorable login password behind which all your hard-to-remember passwords are protected.  This memorable login password is encrypted with an algorithm called BCrypt which is extremely resilient against brute force attacks because it takes an inordinate amount of time to encrypt each password.  So even if you lose your iPhone the likelihood of your login password being discovered is near zero.

 

There is no magical solution that will result in memorable and safe passwords.  But we can up the ante against hackers by equipping ourselves with the tools and discipline to combat theirs.

KEYBOX 2 – Code Complete!

Just an update for everybody eagerly awaiting the newest release of KEYBOX…

I’ve officially finished work on Release 2 and will be heavily testing it while waiting for Apple’s supposed iPhone hardware refresh to be announced on October 4th.  Barring any issues I’ll release KEYBOX 1 week after I get my hands on an iPhone 5, and well after the iPhone commotion dies down.

 

I want to thank everybody for your continued patience!

Jason Fuerstenberg

Scarlett, I Heard about your Nude Pics and I Want to Help

Dear Scarlett Johansson,

 

I’m sorry to hear about your private pics getting leaked out onto the internet.  As it turns out I created an app called KEYBOX that could’ve prevented this unfortunate happening.  These screenshots show what I mean…

Unfortunately, most people seek my app out only after becoming victims like yourself.

 

In a previous blog article entitled “How to Keep Photos Private on iPhone – A Step by Step Guide” I demonstrate how KEYBOX can be used to encrypt images so that even if your iPhone is stolen your private photos won’t be easily recovered and subsequently won’t be leaked out on the internet.

 

If your new phone ends up being an iPhone, contact me and I’ll gladly help you get KEYBOX up and running.

 

Best of Luck!

Jason Fuerstenberg

KEYBOX Release 2

I’ve been hard at work on the development of KEYBOX Release 2 and I’m happy to report that it is nearing completion.

My plan is to make it available after I’ve confirmed compatibility on the next version(s) of the iPhone with iOS 5.0.

Aside from many improvements, Release 2 includes an important fix for a compatibility issue regarding importing secrets via Safari 5.1 in Mac OSX Lion. Safari 5.1 caught me off-guard because I released KEYBOX just prior to obtaining lion.

As much as I want to get this fix into everybody’s hands as soon as I possible I am not willing to do so at the expense of getting caught off-guard again by such OS changes. I could risk breaking the working order of KEYBOX for everybody.

Having said all this, I appreciate everybody’s patience and Release 2, like all upgrades, will be free of charge, and a worthwhile one you’ll all love.

MAC Address as UDID Replacement

I have been testing the solution proposed by StackExchange user ‘shipmaster’ for obtaining a MAC address as a device ID.

I’m a private person, as everybody knows, so I won’t be posting the MAC addresses of my various iOS devices but I will say that I was able to confirm the the MAC address’ suitability as a UDID replacement.

 

How I conducted my testing

Across two iPhone 3GS units and one iPod touch 4th gen unit with two apps (KEYBOX and KEYBOX lite) I was able to reliably retrieve the per-device MAC addresses across distinct apps regardless of whether using Wi-Fi, 3G (only tested on iPhone 3GS as iPod touch doesn’t do 3G) and in Airplane Mode.

I do not own an iPad or iPad 2 with which to test but I suspect MAC addresses will make for reliable UDID substitutes there also.

It would be great to hear from iPad owners who have tried this technique.  Please contact me at jay@jayfuerstenberg.com.

Early Earthquake Warning in iOS 5

Nobody in Eastern Honshu (Japan’s main island), myself included, will ever forget the March 11th M9.2 Mega Quake.

An earthquake of this scale produces aftershocks the likes of M6~7 and during the first month we witnessed aftershocks at least M5 every hour.  It tested everyone’s nerves to say the least.

Shortly after the megaquake many iPhone owners proceeded to download a free app ゆれくるコール (Roughly translated: It’s about to shake call).  For a few months this app worked extremely well.  The sound it emitted was similar to the early warning we hear on TV.

But in recent months this app’s reliability has degraded.  So it’s welcome news (as reported by 9to5mac.com) that Apple will be embedding early earthquake detection service directly into iOS itself!

This is a facility DoCoMo subscribers have had forever, even in feature phones and it’s a joke among Japanese and expats here that we hope to be near a DoCoMo user whenever the big one hits!  Now we’ll have to extend that to iPhone users on SoftBank as well!

UDID is Deprecated in iOS 5

TechCrunch’s Erick Schonfeld is reporting today that iOS 5 comes with a big surprise in that developer access to the UDID, the device’s unique ID number, is being deprecated.

 

What does this mean?

As early as i0S 6 perhaps, we developers will no longer be able to uniquely identify devices.  These are good and bad outcomes of this.  Developing user profiles based on the apps downloaded and ads clicked begins to get a bit creepy and this will now be thwarted.  But some of us developers use the UDID in ways that are not evil per se.

 

What about KEYBOX?  Is it impacted by this change?

Somewhat, yes.

KEYBOX lite uses the device’s UDID to detect when a user is importing an export secret file onto the same device that generated it when the secret file is obviously older than the install date.  In other words, cheaters who thought they could back up their secrets, uninstall KEYBOX lite and reinstall it and get another free 30 days of use.

KEYBOX lite then issues a stronger recommendation to purchase the full edition.  After all, anybody who loves KEYBOX enough to go through the hassle of reinstalling it over and over ought to just purchase it and support further development.

At no time was this UDID ever transmitted in any form to my site or any other by KEYBOX or KEYBOX lite.  In any case I will phase out this check in KEYBOX release 2.  I don’t like relying upon deprecated functionality in my apps.

Back to School Sale for Articles by Sophiestication!

I love to support indie developers and Sophia Teutschler is the talent behind Articles, the refined Wikipedia client for iPhone.

She has just announced a Back to School Sale making Articles for the iPhone now only $0.99!  The iPad edition is similarly marked down to $1.99!

It’s a great deal for a great app so run to the AppStore and grab your copy today!

KEYBOX In-Depth Feature at AppAdvice!

The fine folks at AppAdvice have an in-depth feature of KEYBOX and have posted lots of screenshots for all to see!

Clinton Ferreira, the reviewer, does a great job describing how to use KEYBOX and how flexible it is.  Although he attests to not knowing just how secure KEYBOX’s algorithms are (a certain level of paranoia is very healthy!), he and all of KEYBOX’s users can rest assured that under the hood the best of the best of encryption algorithms is at work.

I’d like to take this chance to remind everybody that KEYBOX’s greatest strength is its lack of vendor lock-in.  You can put as many secrets in KEYBOX as you’d like and if you decide to move to another security product you can always export your secrets as a text file.  This text file is completely readable to humans like you and me and you don’t even need another application to view it.

THEY’RE YOUR SECRETS and you have every right to manage them any way you decide to.

 

Thanks again Clinton and the AppAdvice team for spreading the word about KEYBOX!

KEYBOX on Your Favorite Device

As a result of prMac’s promotion of KEYBOX, the August 6-7 weekend was the best sales weekend to date since it was released a few weeks ago.

Thanks to all of you who purchased KEYBOX! And a special thank you to those who took a moment to rate KEYBOX in the AppStore for your fellow users!

This weekend showed an equal increase in e-mails from customers and prospective customers. The road to releasing KEYBOX to the public has been a long one and it’s great to be able to talk with you and hear all your feedback. One of the recurring themes from these e-mails has been when KEYBOX will be on the iPad/Mac/Android/Windows Phone? Although I like to keep things under wrap (so as not to disappoint anybody) I think it’s time to discuss KEYBOX’s future on different platforms.

Let’s start with the easy ones:

Windows Phone

Unless the market share for this platform grows I won’t be able to recoup my investment. As of today, it’s rapidly losing market share, not gaining it.

Android phones and tablets

Never say never but yeah, probably never. Among its many problems Android is too fragmented a platform (different display resolutions, memory and CPU specs, etc…). The original KEYBOX appeared on Vodafone Japan’s (now SoftBank’s) J2ME platform and was a victim of fragmentation issues. I am not keen on going back to that.

iPad

The iPad could be perhaps in some respects an even better device for using KEYBOX than the iPhone. I’m seriously considering supporting it. Currently KEYBOX works on an iPad in iPhone compatibility mode and if/when an optimized for iPad version is made it’ll be a universal app so that current iPad KEYBOX users won’t need to pay twice. If/When iPad is supported I intend to raise the price to reflect the benefits afforded by the platform.

Mac OS X

KEYBOX on the Mac would perfect the trifecta (phone, tablet, desktop/laptop) in that it could make backups/syncing all the easier. This would obviously be a separate download from the iOS version and the price would be inline with the features/benefit afforded by the Mac platform.

For now…

For the time being taking KEYBOX on iPhone further is the highest priority. Release 1 was about locking down the security and giving it in a simple and clean UI. There are so many great features that didn’t make the first cut and it was difficult to to draw the line but I had to ship KEYBOX at some point. There is a lot in store and I’m thrilled so many of you have joined along for the ride! I value your contributions, and continued feedback and your praise has been a source of inspiration for me!

So thank you! ありがとうございました! Merci! Gracias!

Where is THIS Cow From?

For readers in Eastern Japan, I introduce a MUST HAVE iPhone app!

This app helps you find out where your beef came from and hopefully avoid beef tainted by the Fukushima leak. Just search in the AppStore for “この牛どこ産”.

BCrypt in Objective C

To support BCrypt encrypted login passwords in KEYBOX I ported the very excellent Java implementation by Damien Miller to Objective C.  iOS 4.0 unfortunately does not offer this algorithm out of the box the same way it does SHA-256 and AES-256 and many iOS developers are rolling their own or giving up and settling on SHA-256.

 

Why use BCrypt instead of SHA-256 to one-way hash passwords?

Recently there have been advances in using high performance graphics cards equipped with GPUs to speed up the brute force process of discovering passwords encrypted with SHA-256.  BCrypt is resilient against this strategy by virtue of the fact that it employs a very slow work factor in its hashing.  This is why KEYBOX takes a little while to log you in.  It’s one-way hashing the login password using BCrypt at a work factor of 10.

 

How to use BCrypt in your iOS app.

My ported implementation is called JFBCrypt and relies on 2 other resources, JFGC and JFRandom, which are located with it in my Github repository.  As such, it is fairly self contained and does not require any external dependencies.  Just drop these files anywhere in your iOS project and include logic similar to that shown below.

Example usage:

NSString *salt = [JFBCrypt generateSaltWithNumberOfRounds: 10];
NSString *hashedPassword = [JFBCrypt hashPassword: password withSalt: salt];

JFBCrypt is covered under the very liberal Apache license and can be included in both open source and closed source apps.  Damien Miller’s original license is also included in accordance with his wishes.

 

If you have any questions or feedback feel free to contact me at jay@jayfuerstenberg.com.

KEYBOX picked up by AppFresh Daily!

My sincere thanks to AppFresh Daily for featuring KEYBOX in their TOP 3 apps listing and for their compliments regarding its user interface and powerful encryption.

See their feature page for July 27 here.

Introducing KEYBOX for iPhone and iPod touch!

Before starting, I want to thank my wife and son for their frequent weekend sacrifices over the past year. They literally made KEYBOX possible. I’d also want to thank the reviewers at Apple if for no other reason than their job is a thankless one.

 

What is KEYBOX?

Privacy is a topic near and dear to me. I wrote the original version of KEYBOX to scratch a personal itch back in 2005.

My apartment was broken into and many of my and my wife’s belonging were stolen, even using our bags to haul it all away. Worse of all the thief left us a note showing off how proud he was. This was not our home anymore and everything we thought was private was no longer. Only after becoming victims did we start to invest in dimple keys and other preventative measures.

For myself, it didn’t stop there. I was compelled to take my privacy very seriously from that moment onward. The original version of KEYBOX was the culmination of careful design and development to address this.

2009 and 2010 were years that presented challenges to protecting people’s privacy. I wrote KEYBOX for the iPhone in response to this changing lanscape.

I don’t believe privacy is a dying concept as Mark Zuckerberg would have us believe. Privacy has never been more important. As we move more of our lives onto the cloud we open ourselves to more security risks. Who we are and what we do is no longer tucked away safely in a drawer in our homes. It’s now sitting on a 24h accessible server on the Internet and we are no longer in full control of our privacy.

How KEYBOX works and what distinguishes it from alternatives is a bit too much for this post. I’ll be discussing the design, development, marketing decisions behind KEYBOX and where the app is going in the future in future posts.

If you are serious about security and your own privacy you can learn more here… http://www.jayfuerstenberg.com/keybox/

Preserving memory on the iPhone: The case for lazy-initialization and aggressive releasing

In a previous post I discussed garbage collection and how to abstract away the logic to make it easier to manage memory. I now want to take the opportunity to talk about a complimenting, higher level strategy for managing memory: Lazy-initialization and aggressive releasing.

Memory is at a premium on the iPhone and, in the case of data/information applications, the user is only interacting with a small part of the application at any given time. It therefore makes sense to only allocate enough memory for the part being used. Planning what parts will undergo use up front is difficult at best but the simpler method of lazy-initialization exists.

Lazy-initialization is the act of foregoing initialization of a member until it’s absolutely needed. For instance, when a login view will appear it may need to initialize a set of components.

- (void) viewWillAppear: (BOOL) animated {

	[super viewWillAppear: animated];

	[self lazyInitUsernameTextField];
	[self lazyInitPasswordTextField];
	[self lazyInitLoginButton];
}

An example lazy-initializer method might look like this…

- (void) lazyInitUsernameTextField {

	if (_usernameTextField != nil) {
		// The text field is already initialized so return.
		return;
	}

	// The text field has yet to be initialized so do so now...
	_usernameTextField = [[UITextField alloc] initWithFrame: CGRectMake(20.0f, 50.0f, 200.0f, 30.0f)];
	// Logic to customize the text field goes here.

	[self.view addSubview: _usernameTextField];
}

The beauty of lazy-initialization is it allows the caller to not care whether the member is initialized or not at the time of method invocation. However, by the time the method has completed executing the member is known to be initialized.

 

In other words a one-liner call is all it takes to ensure the state of the application beyond the point of invocation. It is equally appropriate to invoke a lazy-initializer method from within another, and to even set up a chain of such lazy-initializations as needed.

On the other end of memory management is aggressive releasing. I’ve found it handy to use a protocol, JFLazyInitializedMemberReleaser, to expose a method tasked with releasing only members which were lazy-initialized.  Below is an example releasing method…

- (void) releaseLazyInitializedMembers {

	[_usernameTextField removeFromSuperview];
	[_passwordTextField removeFromSuperview];
	[_loginButton removeFromSuperview];

	JFRelease(_usernameTextField);
	JFRelease(_passwordTextField);
	JFRelease(_loginButton);

	if ([super conformsToProtocol: @protocol(JFLazyInitializedMemberReleaser)]) {
		[super releaseLazyInitializedMembers];
	}
}

This method should be invoked from some or all of the following methods (on a case by case basis)…

 

dealloc viewDidDisappear viewDidUnload didReceiveMemoryWarning

Putting it all together

When a view appears for the first time it lazy-initializes only the members it needs. Interaction with the view may trigger further lazy-initialization over time (action sheets that slide into view etc…) When the user transitions to a different view the aggressive releasing method jettisons the members which are no longer of use. Which members are released is arbitrary and depends on the application’s needs.

If/when the user returns to the view the viewWillAppear method will be invoked once again and re-lazy-initialize the members. The user is none the wiser as the view does not appear to have changed from the last time it was used. Finally, all this was accomplished while still keeping the memory consumption to a minimum.

Garbage collection on the iPhone

While Objective C 2.0 provides automatic garbage collection (GC) this facility is not available on the iPhone. However, mobile devices like the iPhone with limited memory are where proper memory management practices must be well followed.

In the course of my development I found it convenient to abstract away most of the calls to retain and release with a set of C macros I created and now share here. If memory management logic is polluting your code base or debugging memory leaks is giving you a headache feel free to use these macros to simplify your life.

Download: JFGC.h

//	JFGC.h
//
//	Created by Jason Fuerstenberg on 2008/05/01.
//	Copyright 2008 Jason Fuerstenberg
//	http://www.jayfuerstenberg.com
//
//	Licensed under the Apache License, Version 2.0 (the "License");
//	you may not use this file except in compliance with the License.
//	You may obtain a copy of the License at
//
//	http://www.apache.org/licenses/LICENSE-2.0
//
//	Unless required by applicable law or agreed to in writing, software
//	distributed under the License is distributed on an "AS IS" BASIS,
//	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
//	See the License for the specific language governing permissions and
//	limitations under the License.

/*
 * The JFAssign macro assigns the value of one object reference to another.
 */
#define JFAssign(to, from) { {id __temp__ = from; JFRelease(to); [__temp__ retain]; to = __temp__; } }

/*
 * The JFRelease macro releases an objective C object using the release method.
 * If the object reference is nil nothing will be released.
 * The object reference is then assigned to nil.
 */
#define JFRelease(a) { {id __temp__ = a; if (__temp__ != nil) { [__temp__ release]; a = nil; } } }

/*
 * The JFFree macro releases a non-objective C memory buffer using the free function.
 * If the pointer is nil nothing will be freed.
 * The pointer is then assigned to nil.
 */
#define JFFree(a) { if (a != nil) { free(a); a = nil; } }

How To Use

 

Instead of writing this…

- (void) setName: (NSString *) name {
	if (_name != nil) {
		[_name release];
	}
	_name = name;
	[_name retain];
}

You now write this…

- (void) setName: (NSString *) name {
	JFAssign(_name, name);
}

And now dealloc methods look like this…

- (void) dealloc {
	JFRelease(_nameLabel);
	JFRelease(_nameTextField);
	JFRelease(_passwordLabel);
	JFRelease(_passwordTextField);
	JFRelease(_loginButton);
	JFFree(_responseBytes);

	[super dealloc];
}

Instead of like this…

- (void) dealloc {
	if (_nameLabel != nil) {
		[_nameLabel release];
		_nameLabel = nil;
	}
	if (_nameTextField != nil) {
		[_nameTextField release];
		_nameTextField = nil;
	}
	if (_passwordLabel != nil) {
		[_passwordLabel release];
		_passwordLabel = nil;
	}
	if (_passwordTextField != nil) {
		[_passwordTextField release];
		_passwordTextField = nil;
	}
	if (_loginButton != nil) {
		[_loginButton release];
		_loginButton = nil;
	}
	if (_responseBytes != nil) {
		free(_responseBytes);
		_responseBytes = nil;
	}

	[super dealloc];
}

Developers coming from languages like Java with automatic GC will find this style more natural as a call to JFAssign(a, b) is similar to a = b and a call to JFRelease(a) to a = null;