 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Bug Report Micromite PIN function
| Author | Message | ||||
| jimbotron Regular Member  Joined: 27/11/2013 Location: AustraliaPosts: 46 |
Hi All, I'm trying out edge cases to see if I can break anything on the Micromite. The PIN function has a couple problems that I can see. First I think it is too easy to crack. The PIN is 16 bits, and as there is no delay between failed pin requests, you could brute force the pin in a few hours. A possible fix is to add a time delay between each failed attempt. Banks get away with a 4 digit pin because they swallow your card after a few attempts. But that would not be good for a device in the field. The second problem occurs if you try to use a pin greater than 32767. It will overflow and wrap around. Try the following: option pin 32768
32768 will not unlock the device, the PIN you need to enter to get back in is -1. Note you can't enter a negative PIN directly. A pin of 65536 with be treated as a 0 and effectively remove the PIN. Using Micromite II 4.6 B20 I think Geoff is doing a marvelous job on the Micromite. It is my first choice micro-controller these days as it is so quick to get something going and it is cheap enough to keep a bunch on hand. I have a Micromite housed in matchbox so I can try things out whilst commuting on the train. Jimmy |
||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Very nice discoveries there, my man. 
I too think that the PIN is too insecure, but then I guess everything is relative. EFTPOS and CC PIN's are only 4 digits, and don't get me started on the bank's latest craze - PIN-less "PayWave" cards - no security PIN AT ALL! - Fecking madness, IMHO. ...all in the name of "Convenience"... With cyber-crime and electronic theft being at a world-wide high and only ever likey to go up, banks bring in PIN-less cards - who thought that one up? (rhetorical) But I digress.......... NICE FIND! Something that needs attention then. What would be the possibility of changing the PIN to a alphanumeric code I wonder? This is becoming more and more common, as it offers a high level of security, and is very hard to crack in a short amount of time. A six character alpha-numeric case-sensitive code would be very hard to crack quickly. Given enough time, I guess any password can be cracked with brute-force - nothing is infallible. 
Smoke makes things work. When the smoke gets out, it stops! |
||||
| paceman Guru  Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
As long as I can still enter the pin numbers as they are - nice and straightforward for us non-commercial (hobby) players. I'd hate to have to use Pin(g7!H4*) or somesuch! Greg |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Perhaps Geoff can allow for both numeric and alpha-numeric PIN's - dare I suggest another OPTION?(rhetorical, and don't shoot me!). I guess he will post his thoughts here in due course if the subject interests him. Smoke makes things work. When the smoke gets out, it stops! |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
> us non-commercial (hobby) players Outta curiousity ..... What do "(hobby)" players use a PIN# for ? |
||||
| jimbotron Regular Member Joined: 27/11/2013 Location: AustraliaPosts: 46 |
When I think about it there is no need for short pins. You only need to turn on the PIN before you ship a device and it only checked when the console appears, therefore there is no real penalty for having a long difficult to crack PIN. In fact there is probably a case for a hard lock, where no pin can unlock the device. Jimmy |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
While on this kind of idea, I must say that I like the PICAXE no-readback concept. You can program the device, but you cannot ever read it back - this is to lock the code into the device, so people cannot read your code. Technically, at the moment, if the PIN can be guessed or cracked, the code can then be read out of the Micromite. I would favour a "Hard-locked" option. PICAXE forums has seen many a thread on people wanting to read-back their chips cos they did not have an adequate code-backup procedure in place, but I still think that locking the chip down and preventing reading-back the code, is a good idea. Re-writing or updating the code is still allowed, you just can't read the progam back out of a PICAXE - I think this is a good thing. My 2c only. Smoke makes things work. When the smoke gets out, it stops! |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Another excellent find, thanks. It was caused by me trying to be cheap and only using 16 bits to store the PIN. The next beta will fix it (the PIN is supposed to be between 1 and 99999). I will also put a delay in there to prevent brute force attacks. Geoff Geoff Graham - http://geoffg.net |
||||
| paceman Guru Joined: 07/10/2011 Location: AustraliaPosts: 1328 |
Absolutely nothing Michael; I'm totally screwed up here, I thought people were talking about the PIN function, as was written. What they're really talking about is the OPTION PIN command which was immediately given as the example - my apologies! Greg |
||||
| plasma Guru Joined: 08/04/2012 Location: GermanyPosts: 437 |
Haha my Credit Card has a 4 "byte" Pin ...
|
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Can you or anyone else explain how just adding a delay will prevent brute-force attacks? If your attacker program simply waits for the PIN prompt thrown up by the uM whenever you try to access the console with the PIN set, then the brute-force approach would still work, would it not? It may take a little longer because of having to wait for the delays, but would not brute-force still work? Smoke makes things work. When the smoke gets out, it stops! |
||||
| jimbotron Regular Member Joined: 27/11/2013 Location: AustraliaPosts: 46 |
Hi Grogster, You are correct, a brute force attack will still work, however the delay in conjunction with a larger PIN can make it impractical to crack. For example if you put a 10 second delay in after a failed attempt and allowed 9 digit pins then it would take on average 150 years to crack. You could try to get your hands on a hundred devices and try to crack all 100 in parallel, but you'd still take over a year and that assumes each device was given the same pin. Even with 5 digits, if you make each failed attempt cause the chip to take longer to respond up to say an hour, it would take about 15 years to crack. If you don't need to access the console in the field, then you can just lock it up without a key. If you need to reprogram the device then do a full reset. If you need diagnostic in the field it would be better to build your own interface so that full access to the console is not required. When you are developing you probably won't use a PIN. Jimmy |
||||
| Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9066 |
Thanks for that info - helpful. You are correct - during development, I have never used the PIN other then to just try it out to see how it works. I DO have one unit in service that uses the PIN. If someone wants to clone your chip or code badly enough, they will find a way to do it - just look at the FDTI debarkle recently with the corporation vs the clone chips... Smoke makes things work. When the smoke gets out, it stops! |
||||
| jimbotron Regular Member Joined: 27/11/2013 Location: AustraliaPosts: 46 |
I have retested the PIN issues and confirm that as of uMite II 4.6 beta 21 the problem has been fixed. Jimmy |
||||
 Print this page |
