floBLOG

But Tobias isn't crazy. Far from it. He's a professional lock breaker, a man obsessively—perhaps compulsively—dedicated to cracking physical security systems. He doesn't play games, he rarely sees movies, he doesn't attend to plants or pets or, currently, a girlfriend. Tobias hacks locks. Then he teaches the public how to hack them, too.

Like many exceedingly bright people, Tobias has the exhausted air of a know-it-all. Over dozens of dinners, he has walked me through how to pick simple locks ("Uh, is there something wrong with your hands?") and bypass combination dials ("A brain-damaged monkey could do it faster"). He has described how to outwit security technologies like motion detectors ("Duh"), face-recognition software ("It's stupid, even if you think about it!"), fingerprint scans ("What child came up with that?"), and heat sensors ("You can get this one—maybe").

We've covered key card hotel locks over seafood, in-room credit card safes over sandwiches. While we ate a decent steak dinner, Tobias used the house crayons to diagram one of the largest jewel robberies in history; over dessert, he showed me how a person less honest than himself would pull the heist again.

[...]

Googling for "SQL injection" gets about 4 million hits. The topic excites interest and superstitious fear. This whitepaper dymystifies the topic and explains a straightforward approach to writing database PL/SQL programs that provably guarantees their immunity to SQL injection.

Only when a PL/SQL subprogram executes SQL that it creates at run time is there a risk of SQL injection; and you’ll see that it’s easier than you might think to freeze the SQL at PL/SQL compile time. Then you’ll understand that you need the rules which prevent the risk only for the rare scenarios that do require run-time-created SQL. It turns out that these rules are simple to state and easy to follow.