Feed on
Posts
Comments

Disabling Nvidia

I have a MacBook Pro made in 2010 which is among the models which received faulty Nvidia chips. After this was discovered, Apple decided to extend the warrantee for the chips to 3 years. Instead of proactively replacing the faulty chips, they required that the machine exhibit the problem before they would consider replacement.

So, like clockwork, my computer’s Nvidia chip fails after the 3 years. It results in kernel panics in the GPU driver about once a week. Searching for this yields numerous similar results all stemming from the graphics card asserting its manufacturing flaw. Finally, since my computer is now more than 3 years old, Apple will not fix it without payment of several hundred dollars.

So, do I have to contend with a machine that kernel panics every week or so? Certainly not. Even Windows wouldn’t blue screen that often a decade ago and it’s far better now than it was then. There’s another solution: Download and run gfxCardStatus (http://gfx.io/) and switch it to the integrated graphics card only. This has to be redone on every login, but that’s a small price to pay.

I’ve been running with this machine for nearly a month now like this and no kernel panic yet. I did have to reboot because authd went crazy and stopped displaying all authorization dialogs, but I doubt if that’s due to the machine being locked into the Intel graphics card only; it’s more likely a bug in Mavericks.

Going to the future, whenever I get around to replacing this machine, it is extremely tempting to make sure I never buy one with an Nvidia chip again. Since Intel’s graphics cards have improved so much as of late, this is now a viable possibility.

Anyone else out there with similar experiences?

Mobile Passwords

Lately there have been several Ars articles discussing passwords and online security. In today’s world, people generally use passwords which are completely inadequate for securing anything, much less private or financial data. Additionally, the “tricks” people are taught on securing their passwords are the wrong lessons (cue obligatory xkcd). So, one of the best solutions is to use a password management system, such as 1Password or LastPass. This solves the problem of weak passwords and the memorization factor, but that still leaves the creation of a strong password for the password manager. A great deal of attention has been given toward creating a strong password, but it is geared toward a computer and not a mobile device. So, how does one create a secure password on a mobile device, particularly in the context of an encryption key.

The Problem
In the above articles, passwords are described as increasingly weak. The xkcd comic describes a guessing rate of 1000 tries per second, but this is assuming no access to the password hash or encrypted data. In light of recent data breaches, lousy security in cloud data providers, and what the NSA’s been up to, this assumption is entirely invalid. The only assumption that makes sense is that the attacker has access to all the data needed to start guessing passwords and does not need to hit a service. In that case, readily available hardware and software is available to literally test password guesses in the billion per second range. This clearly indicates the need for a strong password, but it must also be memorizable or it is essentially worthless. In this compromise, people have developed a whole host of tricks in development of a password, but the truth is these tricks add little to the actual strength of the password. The 1Password Blog has an excellent pull quote on the real security of a password generation technique. Essentially, given a technique, the strength is directly determined by how many unique passwords can be created. This measure, not the number of symbols, not the number of upper case characters, not the number of numbers, not even the password length, is the true test of a password’s security. In information theory, this is the measure of entropy, which is really the only measure that matters.

Taking the first password in the xkcd comic linked above: “Tr0ub4dor&3″ used in a system with a simple hash, with an experience attacker, the password would be cracked in less than a second. That not even one second!!! In a system with PBDKF2 with 32768 (number chosen for connivence of the math) rounds or so, then it would last about 4.5 hours. That’s still not very long. Clearly this is an unacceptable password for an encryption key. The xkcd goes on to show an example of a better password, which using the above numbers, would fall in 2.2 hours, and 17 years respectively. This is clearly a much better password but perhaps still not sufficient. As another example, I’ve used a long, non-sensical phrase for a truecrypt password that’s on the order 40-50 characters long. This password can be typed more reliably than the more random looking password that I type several times a day. The reason is that it involves the task of typing real words, of which I’ve had plenty of practice. Strangely enough, the long and very easily much more secure password, will not pass my work’s password requirements, but that’s a whole other story.

So, taking a word that’s more easily remembered, and modifying it using several “clever tricks” results in a less secure and less easily memorized password than 4 random words. That means we should be using a collection of random words for the password management system we use on mobile devices, right? I don’t know about the rest of you, but I could have a hard time typing words with high reliably in an iPhone without the autocorrect enabled (since this is a password field). There’s got to be a better way.

Better Mobile Passwords
I’m going to use the iPhone as my example here, but the same is true of other device keyboards as well. As I stated above, the entropy of the password is the only measure that matters in terms of a password’s strength. The convenience of a password can be measured in terms of how easy it is to remember and how reliably it can be entered. So, to put two of these measures together, I’m going to measure passwords by their entropy per tap on the keyboard (I’ll assess the ease of memory later).

Since I am measuring entropy, this measure is maximized when characters in the password are selected in a truly random fashion. So, this remainder of this assessment is going to assume completely random passwords, with some constraints in the form of the number of different on-screen keyboards. On the iPhone on-screen keyboard, there are essentially 4 different keyboards available. There’s the lower-case letters, upper-case, symbols and numbers, and the extended symbols. Switching from one of these keyboards to another requires 1 or in some cases, 2 taps on the screen. For simplicity, I’m going to assume that a character is selected randomly from any of the keyboards allowed in the scheme with equal probability, and that each keyboard has an equal number of keys (say 26).

Let’s first examine the truly random password using characters available on any of these for keyboards. For any given character in the password, the user will be on the correct keyboard about a quarter of the time. They can get to the correct keyboard in a single tap about half the time, and in 2 taps the remaining quarter of the time. Add in the tap for hitting the actual character and this means that entry of a single character in the password averages 1/4 (1 + 2 + 2 + 3) taps respectively, or an overall average of 2 taps. The entropy of this password is ln_2(26) per keyboard and adding 2 bits for the 4 keyboards brings this to a bit under 7 bits per character. This truly random password results in just under 3.5 bits of entropy per tap.

Moving on to a truly random password using characters available on two keyboards which are interchangeable via a single tap: Examples of this are upper and lower case letters, or lower-case letters and the numbers and symbols, etc… For this password, for any given character in the password, the user will be on the correct keyboard half the time and a single tap yields the correct keyboard in the other half. That means entry of a single character in the password averages 1/2 (1 + 2), or an overall average of 1.5 taps. The entropy of this password is ln_2(26) per keyboard and adding 1 bit for the 2 keyboards brings this to just under 6 bits per character. This results in just under 4 bits of entropy per tap.

Now, using a truly random password using characters available on only a single keyboard. For this password, for any given character in the password, the user will be on the correct keyboard every time. That means entry of a single character in the password averages 1 tap. The entropy of this password is ln_2(26) which brings this to just under 5 bits per character. This results in a bit under 5 bits of entropy per tap.

To summarize:

Keyboards Entropy per character Average Taps Entropy per tap
4 6.700 2 3.350
2 5.700 1.5 3.800
1 4.700 1 4.700

So, a password that’s secure and easy to type on a mobile device is all lower-case letters? That’s not what is taught in terms of creating secure passwords, but the math doesn’t lie.

Password Length
So, how much length is needed? I’ll refer you to another Agile bits blog entry which discusses entropy and guessing time (scroll down to the table on guessing times). Using this as an example, I’d judge that the password should have at least 50 bits of entropy to start to be considered secure (more if you are worried about the NSA). In the all-lower case letters case, that’s 11 truly random characters. These 11 characters can be entered in 11 taps on the screen, which is far less than what it would take to enter a password that conforms to the typical “secure password” rules. In contrast, “Tr0ub4dor&3″ takes 17 taps and is over a million times easier to guess. But what about memorization? Can the average user memorize 11 random characters?

Let’s try it out: Here are some random letters (generated by dd if=/dev/urandom bs=1 count=20 | base64, tossing the non-letters, lowercasing the rest, and finally truncating to 11 characters):

lvwaf osvcs x

Let’s generate a mnemonic. People memorize random factoids with mnemonic all the time, but usually they have a harder time memorizing what the letters stand for than the letters themselves. Fortunately, we only need the letters and that’s all, so our job may be easier. So, for the above let’s try:
Leaves Vary Weight After Fall; Operating Systems Validate Computer Science; eXecute;
The above took me about 5 seconds to create; it would likely be better if I spent more time on it, but I think the point is made. If this password is something I’ll type a few times a week, I’ll likely memorize it for the rest of my life. I happened to separate the letters in groups of five before I generated the mnemonic (solely to keep count), but don’t be constrained by that count. Use something that can be memorized using as many characters as appropriate for the mnemonic. The mnemonic doesn’t even have to be a true fact; make something up or flat out lie about it. If you see initials you recognize, use a person’s name. Make it scandalous so you smile a little every time you type in that password. If you have a hard time with some combinations of letters, generate another (just be aware that it is technically weakening the strength, but not by much).

Conclusion
So, hopefully this is useful to some of you out there looking to secure your mobile devices or the encryption systems contained with them. I know that all-lower case passwords being more useful is a surprising result, but that is why I went through the trouble to write this. The simple fact is, instead of trying to make a complex password that you have to type on a mobile device, simple use random lower case letters and make up for the reduced complexity by adding length. Going from a complex and purely random password to an exclusively lower case one only requires increasing the length by about 40% to achieve the same strength, but requires fewer taps on the screen.

P.S. If the random letters happen to form a word, or a word surrounded by a few letters, you may want to select another set. While this password is technically as strong as any other, it is only so if the attacker knew you were selecting letters at random. Otherwise, the attackers typically will do a word search first, and this password may fail faster.

Anyone who uses multiple IDEs along with Xcode recognizes just how far behind Xcode is compared to others. I would even go as far as to argue it is at least half a decade behind Eclipse. Features which I have long grown use to having are completely absent in Xcode. Then, about a month ago, I discovered AppCode and started using it for my Obj-C development at work. I could repeat the feature set mentioned on their website, but instead I’ll assume you’ve read that and outline the crucial parts.

Code Completion and Imports
The code completion causally mentions that it works with CamelHumps, but this is a huge factor in completing code. For example, if I wanted an NSMutableArray, in Xcode I must type NSMutableAr before the tab completion results in a single result. If the tab completion is aware of CamelHumps, I must only type NSMAr before the tab completion has narrowed it down to NSMutableArray alone. Furthermore, the tab completion after the insertion of a colon works better than it does in Xcode.

The killer feature in the tab completion is when the class has not yet ben imported. If I were to start typing the name of a class that is not included in the imports, not only can it complete the class name, it will also import the necessary files to satisfy the complier for the choice I made.

Code Generation
Declare Method in Interface: I used this feature a lot. I had long gotten used to copying a method line in the .m file, and then pasting it into the .h file, with a semicolon at the end, to declare it in the interface. Now, I hit option+enter at the method declaration and tell AppCode to do it for me.
Implement/Override: I use this one a lot too. Too often I am making a subclass or implementing a protocol, and I forget all the method name I may want to implement. Now, I just hit the override shortcut, and select the ones I wish to implement.
Change ivar/property to ivar/property/both: I used to use objectivecannotate for this task, but AppCode does it much more cleanly. I can tell it to declare the property for an ivar, or even make it read only in the interface with it being read-write in the implementation.
Live Templates: Yes, Xcode has their snippets, but these are more powerful because you can define what kind of completion to use for variables in the snippet as well as where the snippet is applicable. Thus far, I have only had to add the one that is a typedef of a block to a nicer type name. Such as:
typedef NSComparisonResult (^NSComparator)(id obj1, id obj2);

Refactoring
I have to admit, I’m scared of the refactoring in Xcode; it gets things wrong. I freely use the refactoring in AppCode and it has yet to screw something up. Often, I am renaming a variable or changing a method signature but two important ones must not be overlooked:

  • Selecting a section of a line or a line, and extracting the result to a variable.
  • Extracting several lines of code into a method

Unit Testing
I have gotten to creating unit tests to test if my code works (yes, not proper unit tests but I have to make sure it works anyway…). Lately I’ve been developing libraries, so testing in the app isn’t as applicable. The unit testing in Xcode is a bit, uh, pathetic. In AppCode, I’m often telling it to run a single test (selector), and then debugging it while it is running the test to see where things went wrong.

Integration
AppCode reads and writes Xcode’s project files. So, going back and forth is a non issue. I modify the project in one, the other sees it. AppCode also can run apps in the simulator or on the device, as well as debug both.

Deficiencies
AppCode cannot edit xib files or a host of other non-text files in a project. It at least will open Xcode to do this task. It is also limited in it’s ability to edit the project as well as missing some of the more specialized functions. The key-mapping is a bit off, making it feel like a windows application, but this can be mostly fixed by changing the shortcuts.

Conclusion
AppCode makes an excellent editor of code as well as debugging. It’s building doesn’t give as much in terms of a progress indicator, but it does work. Since I spent a vast majority of my time writing code and debugging, I spend more than 90% of the time in AppCode. When I’m doing anything else, I tend to use Xcode.

Now, if only Apple would make Xcode a better editor of code…. Nah, NIH syndrome it too well engrained.

I often use single vendor credit card numbers for my online transactions because in the event of a breach or theft, the numbers cannot be used elsewhere. Many credit card companies offer these under other names, such as Discover who calls these “Secure Online Account Numbers.” These work really well, except for the fact that these do not work well with Amazon purchases. There are a few other cases they fail, but Amazon is the biggest nuisance for me.

The Problem
Why do these fail with Amazon? Amazon has separate vendor IDs for purchases. Purchase made from Amazon are under one vendor where as purchases made from third-parties where Amazon handles the processing is another vendor. While I’ve not seen it myself, I’ve read that Kindle purchases are again another vendor. This means that a single vendor number cannot be used for orders which contain purchases which will be charged by more than one vendor. Furthermore, Amazon likes to save these numbers and if one were to use separate numbers for each vendor, they can easily become confused with one another.

The Solution
I’ve found a relatively simple solution that in my experience seems to solve the problem. Place and pay for orders which would be charged by multiple vendors while retaining the security of not giving Amazon a credit card number that can be used by anyone else.

  1. Put items in your cart and build your order to what you want to buy.
  2. Do not proceed to the checkout but instead view your cart and click on the link to “Estimate your shipping and tax.”
  3. Open a new tab to Amazon’s gift cards, select email, and fill in the amount which will cover your order size. It’d be prudent to add a buck or two extra in case.
  4. Put in your own email address and purchase your gift card.
  5. When you receive your gift card email, go back to your original purchase and proceed to the checkout. When you reach the payment page, copy and paste the gift card number into the appropriate section.

I’ve placed one order this way and it worked well. Though there was a random fluke where Amazon didn’t ship it for over a week, but they assured me it had nothing at all to do with the use of gift card. In fact, the guy on the phone couldn’t figure out any reason why it was delayed, strange.

I do this because it is an active protection mechanism against theft. Even though I do this most of the time, I did have my credit card number stolen recently and attempted use in Michigan. So, I’ve stepped up my use of single vendor numbers and decided that I will not purchase from Amazon anymore unless I can use them. Does anyone else take these proactive measures to protect their credit card number?

Now, if only this worked with AWS…

Suddenlink seems to think that this is 15Mbps:
2520933228

I’ve called them at 5-10 times in the past few weeks, and this is still the speed that I get. I have tried changing modems and three separate technicians have said that my connection is good and yet it is no better. This is consistent across nearly every evening. Using these numbers, if I were to extrapolate the speed to the 50Mbps plan, I’d still not get achieve 15Mbps in the evenings.

Just a note for those considering Suddenlink and have a choice with another provider. I used to think that Suddenlink’s service was great, but no longer.

Older Posts »