So, the attack vectors I see, especially once you pull the keypad face off and are talking directly to the 4 pin plug are:
1. How does it keep track of too many bad tries? How is a single bad try recorded?
Here is one way not to do it. The obvious way is to record a bad attempt to flash after a password check, but there's a tiny window where an attacker might read your poker face and pull the plug before commit. Or a gigantic window where you never had enough voltage for flash writes to succeed at all. If I were writing the firmware, I would FIRST append a failed attempt to flash (and verify it!), then test the password, and then if we have a match we'll go back and erase that black mark. (By append, I mean don't erase a 2 and put a 3 down as the number of failed attempts, somebody's bound to split that transaction with a power outage.)
2. How does the 5 minute timeout work? How goes the last bad try before dropping the timeout hammer? If there's anything special about how the flash writes "uh oh, we're in lockdown mode now", we might be able to take a miss on that and get unlimited retries. If pulling power causes the controller to forget about the timeout, somebody is hankering for a firing.
3. Seriously, how well do you deal with brownouts? Flash is a fat little piggy for voltage requirements, while the processor would probably be okay running significantly leaner. Are they counting on the MCU's BOD to cover the flash chip's needs too?
4. When does the password match actually happen? Lots of folks here are saying "only once the 6th digit is entered" which I like. Some are saying that you are typing into a rolling window of 6 digits, which would give you FAR too many free swings at bat if that were true. The 7th digit you enter must be taken as a clean slate entry of the 1st digit of a new attempt.
5. Does the processor's eyebrow twitch as it matches a correct or incorrect digit? If Dave spent the weekend plugged into that pretty little 4 pin plug instead of leaning against a drill, we might have seen some movement on this front :-P Love the lemonade that Dave made out of the lemons anyway!
6. How well protected is that I2C(?) pin anyway? I've heard of AVRs getting messed up in the head with crazy-fast thwacks on a GPIO, perhaps an ST is as vulnerable.
7. Did a web programmer do the communication code? Those jerks make buffer overflows all the time, geez keep it together guys.
8. Can the CPU skip instructions until it finds itself in the unlock routine? Don't let a few missed instructions just let it fall into the unlock code, put a minefield in between main() and there. Hmm, If I were a 2 stage pipeline CPU being induced to glitch, I think I'd try interleaving the code with tons of small JMPs past very bad instructions. I believe that the pipeline normally starts chewing the next instruction, but has it inhibited by a later clockcycle of JMP. If the JMP gets glitched, the evil instruction may be executed and induce a soft fault, throwing code flow into a (hopefully) more jailable exception handler. And how bout this - wire the board such that only a certain pattern on GPIO will trigger the solenoid without also smacking your own RST line. What are the odds of a drunk processor (a) accidentally falling into the GPIO port write and (b) having the correct magic pattern sitting in a register in the first place?
9. Is there a bitchin' bass frequency where the solenoid pin will dance out of the way? The opposing-mass pin (which is awesome!) may hold shit together when the solenoid is bumped out of the way, but it won't groove to the same tune.