Python implementation of passcode hashing algorithm used on Samsung Galaxy S4 | Hacker News Reader

Python implementation of passcode hashing algorithm used on Samsung Galaxy S4

gist.github.com

42 pointswatermel0n30 comments

No practical hashing algorithm, even Scrypt, would be able to securely hash a 4 digit PIN. If they don't have a hardware security module they may as well store it plain. The amount of cryptography fail in mobile apps is stunning... from Snapchats static encryption key to pointless obfuscation like this.

If you want to talk about weak passwords though, consider that millions of broadband customers in the UK are likely using cable modems/routers with the default Wifi password that came printed on the base... currently 8 random lowercase characters on Virgin Medias newest gear for example. WPA2-PSK handshakes only add 12 bits during key stretching, so that's only 2^50 hash iterations to compromise potentially millions of wifi networks.... which can be done in about ~2 minutes to a few hours with a bit of hardware investment.

The interesting part is whenever they use the same algorithm for hashing passphrases (there's an option to lock phone using a proper passphrase, not 4-digit pin).

Good point! Although really, breaking the unlock password on a phone isn't that interesting to an attacker unless the owner has encrypted their phone or, more likely, they suspect the owner uses the same password for other things.

I think most people just use face or pattern unlock these days though?

Android actually does quite well in this regard: KitKat now uses Scrypt... although both PIN and Face Unlock can still be used with encryption, which very secure. Oddly you can't use pattern.

>I think most people just use face or pattern unlock these days though?

Most average users, sure. I've seen a couple of family members using face unlock, and many random people and coworkers using patterns. Myself, I use a password.

Patterns are terrible. I've clocked a few friends patterns accidentally, let alone actually trying to shoulder surf. Far too visible.

Not to mention when dirty fingers leave pattern-showing streaks on the screen.

Ah, but it's a matter of what you're trying to protect against.

I'm having a number of devices, from 'swipe to unlock' via 'pattern unlock' and full passphrases.

My phone uses a lock pattern, because

- swipe to unlock would unlock the phone in my pocket. Rare, but happened a number of times

- my phone is the one device that consistently lies around the house and gets carried away by my 1.x year old son. Swipe to unlock was very easy to understand...

So - pattern aren't secure, agreed. They are just a way to lock the keyboard against accidents and for that they work quite well..

This. Arguably, if you're not using full disk encryption, your adversary is someone that (at least) hasn't entered high school yet... ;-)

I'd add that it also does add a bit of "intent" (in the same sense that (quite easily pickable) door locks do -- if your child/friend/coworker unlocks your phone with your pattern, that's clearly crossing a boundary - more so than just looking at your unlocked phone.

If you disable the "Make pattern visible" option, it makes it much harder to shoulder surf the pattern.

I don't understand why making the pattern invisible isn't the default. When it's visible, everyone within 20 feet of you can tell your unlock pattern. I wish you could also make failed patterns invisible, but AFAICT there's no option for that. Of course, as others said, if I were really worried I'd use a longer password and disk encryption.

Since Samsung's TouchWiz (at least on S4 mini) don't allow to take shots with camera without unlocking the phone (standard AOSP has such feature), I guess many users settle with swipe-to-unlock.

I disabled that feature since it's essentially an easy battery DoS (and can be activated in a pocket).

There's also an unlocking pattern, where you must draw a pattern between some circles in a grid. (the difficulty is adjustable, so it can be a 3x3 grid, a 4x4 grid, etc)

Not sure how this is stored in the cellphone though.

That, and if the 40-bit hash is used for aes full disk encryption (encrypting the device requires pin or passphrase). And, if full disk encryption uses proper key expansion, why don't the just use the same thing for the pin? (maybe so that if you reuse pins, you couldn't easily get the pin from an unsecured device? But then again, how hard could it be to brute force 10^4 keys, given that the device will need access to the salt before deriving the decryption key anyway? No HSM seems like it has to be a fail here, no matter what...).

How about car keys then? Are those strong?

Edit: I meant the encryption used to remotely unlock and lock a car

Newer car keys have a RFID so that you can't just copy the physical pattern.

If those RFID tokens are dumb ones like common anti-theft stickers in supermarkets, one can copy the electromagnetic pattern just fine.

There was a spate of thefts of new BMWs recently which were done entirely in software. There's security camera footage of people with laptops standing next to the car for 5 minutes, and then climbing in and driving away.

To bypass complicated physical security you at least need to be a skilled lock picker, own precision tools or physically break something. Once one person has figured out a software security flaw, they're a redistributable script away from everyone knowing it. Software based security is creeping into our lives, and it's scary how poorly thought out a lot of it is.

Why can't we just use the current rolling code system we use? A long, shared secret between the car and key is passed through a PRNG to produce random numbers that are sent as codes. If the secret is long enough and the PRNG secure enough, this cannot be guessed or bypassed.

To play devil's advocate: If Samsung had just stored it in plaintext, as you suggested they might as well do, then the title of the article would've been along the lines of "Samsung security FAIL! Stores your PIN code in plaintext, doesn't even try to obfuscate it."

Definitely. This makes me wonder how other Android implementations store it though, as the space for brute forcing a 4 (or even 8) digit number is so small as to be essentially nonexistent, as long as you're cracking some kind of hash rather than typing in attempts.

> No practical hashing algorithm, even Scrypt, would be able to securely hash a 4 digit PIN.

I was at first skeptical of this, but this seems right. Suppose that Samsung is willing to make it take 5 seconds for the phone to perform the hash to check the PIN (which is a ridiculously large amount of time). With 10,000 PINs you could still break it in brute force in 14 hours. And that's not even counting the difference between phone CPUs and desktop CPUs, or parallelism; in reality it would probably take an order of magnitude less time.

Is it possible to get the hash and salt off the device while the phone is still locked and not in developer mode? If not this doesnt seem too serious as a security risk.

If you can grab the phone while it's unlocked (steal it off a table when someone walks away, within the lock timeout window), you can grab the PIN before the phone locks itself and have the PIN forevery after that (or learn the PIN to change the PIN).

You can steal a phone regardless, but if the phone ever locks the screen, you're now locked out.

You can root the phone from a sdcard and then have access to it. You'll need root rights anyway to access the hash and salt. This might not work with every Android version.

maybe I'm wrong but don't you need to unlock the bootloader before, and doing the phone will be erased as a security measure?

If you have enough access to the phone to dump the hashed pin code then why would you care what the pin code is to begin with? This seems like a non-problem unless people are reusing their phone pin code for them ATM cards but no amount of security is going to fix that kind of stupid.

Question : how did you get the salt and algorithm used ? By retro engineering the code ?

"Get salt in signed numeric format by doing sqlite3 query SELECT value FROM locksettings WHERE name = 'lockscreen.password_salt' on /data/system/locksettings.db"

That does not answer his question.

Reply on news.ycombinator.com