def getNaturalName(tag, globals)
if globals.lookup("0") is Just(Global(_, _, term))
if term is Numeral(_, type, _)
return Just(Name(getTermTag(type)))
error showSyntaxError("0 must be a numeral to use numerals", tag)
return Void
Though this ultimate conditional syntax is more general because lambda zero only allows one destructuring per conditional to simplify parsing.
I'm working on an open source pure functional programming language called Lambda Zero that aims to be a simple and elegant base language from which to derive more advanced languages and eventually a foundation of mathematics. Like Haskell, it is basically just the lambda calculus with a bunch of syntactic sugars, so it's more a process of discovering the foundations of computation than inventing an arbitrary new language.
There is currently a bootstrap interpreter written in C that is under 2000 lines of code, a self-interpreter (~1200 lines), and a static type inferencer written in Lambda Zero (~400 lines). I'm currently implementing pattern matching lambdas and algebraic data types and I have a long roadmap of things to do. It would be great if someone was interested in writing an optimizing compiler for Lambda Zero in Lambda Zero.
I've been surprised by how negative the opinions of deterministic password managers have been since I've been using one for over two years and it has been a much better experience overall than using KeePass on Dropbox, and I also think that it's more secure than cloud-based systems (see point 4).
My take on the points in the post:
1. Out of the 100 or so sites that I use, only a few have password policies that require tweaks, and it usually just requires disabling symbols and or adjusting the length. These tweaks are cached in my browser, so this hasn't been much of an inconvenience.
2. My passwords are rarely revoked, and when they are it is just a counter bump. This is state, but again it is cached in the browser.
3. It's true that they can't store existing secrets, but this can be viewed as out of scope for a password manager.
4. For the application I use, it's not true that exposing just the master password exposes all of your site passwords. There is a 512bit private key that is synchronized once between devices using a QR code. An attacker would need both the master password and the private key file to generate any passwords. Because the private key only exists on devices I physically own, this should be harder to obtain than an encrypted database that lives in the cloud, so I view this system as more secure than KeePass on Dropbox, Lastpass, or 1Password.
My experience over the past two years has been that the advantages are more significant than the disadvantages.
Only the override parameters for a site are cached, such as a boolean to indicate that symbols are disabled or an integer reset counter. The passwords are never cached.
Which is bad. I've reverse engineered script kiddie malware far too many times to find them shipping "iStealer" and similar, which basically just dump browser password stores and send them to a gmail or FTP account. Often these pieces of malware include the SMTP credentials to the same gmail account or FTP access to download the results.
And having seen their results, let me just say, these script kiddies can do damn well with this tactic.
Do not use a browser/system keyring store under any circumstances unless you can be 100% positive that you won't accidentally run that sketchy exe you came across.
If you use Keepass, it presents another layer, they have to actually get your keepass password too, or dump your database when it's logged in. Often something like that won't be hit by script kiddies but certainly would in a targeted attack. The best practice here is to run Keepass on a separate machine to prevent an all-at-once dump. Even a separate machine on the same network where you use Synergy or similar to sync the clipboards would probably be sufficient.
Anything worth more than dirt should of course have 2FA, which is why I also suggest a tiered password system (ie: junk password for common and worthless sites, separate passwords for banking, etc) and 2FA as an alternative to a real password manager.
> Do not use a browser/system keyring store under any circumstances unless you can be 100% positive that you won't accidentally run that sketchy exe you came across.
This is easy once you decide to do it. Just don't download and run random crap, don't be stupid and "curl URL | bash", etc. It really isn't that hard to be 100% if you pay attention. The main problem is that most people just don't care enough.
Wait, KeePass only decrypts the database into memory for a particular process, right? So it would take an exploit of some kind to read the memory holding the decrypted database?
No, it wouldn't take an exploit, it just takes a process running as an administrator, maybe even as the same user if the attacker is clever.
There's several ways to go about it:
1) Basic basic software keylogger, there are some mitigations against this via common APIs though with mixed success. It also would mean a lot of data to filter through. Not fun for someone just looking to grab as many passwords as they can.
2) Dump memory, just save the entire memory of the keepass process via ReadProcessMemory calls, as long as you have sufficient privileges this should be possible. The passwords are in there, KeePass has no memory shadowing support to my knowledge at least. And once you've logged in to keepass you don't get prompted for the password again, therefore, it should be entirely possible to read all passwords based on just this.
3) Replace the keepass executable with your own modified version that logs the password or other auth credentails to disk, or just dumps the database to disk on logon if they're using some esoteric authentication method like Yubikey. This involves shipping your own patched exe around though, which works, but isn't particularly clever, could be fairly large and will be revealed with a signature check.
4) Do the same, but rather than replacing it on disk, do it in memory - do it from a shared library or inject your own code via WriteProcessMemory/CreateRemoteThread, etc. This is usually less detectable. Doesn't matter if the executable is signed this way either, you bypass the signature system and can avoid the need for disk write permissions too. This is the way to get the brownie points.
Any and all of these are fairly trivial to someone who knows their way around the Windows API and has a copy of the Keepass source and IDA. However, none of these are things commonly used by script kiddies going for a hit-and-run operation. All of these however are on the table in a targeted attack with even a slightly competent attacker.
> I've reverse engineered script kiddie malware far too many times to find them shipping "iStealer" and similar, which basically just dump browser password stores and send them to a gmail or FTP account.
- Firefox Sync is not vulnerable in the sense that Mozilla, nor any attacker can read your passwords while they're on the wire or on Mozilla servers. Passwords are encrypted client-side only and are effectively unbreakable between your devices assuming your master password is secure.
- The Firefox browser password store is only encrypted if you use a separate master password to unlock your saved passwords each and every time your browser starts up. This master password would defeat the majority of script kiddie malware, but not a targeted attack, similar to separate password managers. However, it's also a real pain, no one wants to have to type all that extra stuff, so they just use the default - remembering passwords without a master password. Even if you use Firefox Sync, your passwords still get sync'd into this store. Firefox Sync keeps them safe everywhere between your devices, but not on your devices.
- If your Firefox password store has no master password set, that means that the Firefox browser must be able to read your passwords from it. They can (and do) encrypt it all they want, but ultimately all it takes it a little bit of reverse engineering to decrypt it, because the key needs to somehow be accessible to Firefox, that means that to read your passwords, malware simply needs to duplicate what Firefox does.
How is this to supposed to show "how vulnerable you are to this sort of attack"? This runs standalone.
1. As a general rule, if you download and run an untrusted standalone program, it could probably steal your passwords even if you use a password vault (although that would certainly make it a little bit harder).
2. You can just go into the Chrome password manager and click "show" to see any stored password. No tool needed.
Chrome uses sandboxing and process isolation extensively. Using the default browser password store certainly presents a ripe target if someone manages to totally own the browser, but technically there's not a huge leap from owning the browser to owning an external password store, and certainly not grabbing any and all passwords entered into the browser via a password vault.
I'm not disagreeing that a standalone password vault encrypted with a master password is effectively more secure than the built-in manager. I do think it has been exaggerated both how much more so it is. Saving strong passwords with the built-in password store is generally much less bad than, for instance, using a common memorized password, or using very weak passwords. Both of which are likely outcomes of "never use the password store."
Yeah, this is not an attack itself, just one of the most common post exploitation routes to easy profit. So common that if you have amateur people who try to pirate things, cheat at games or click on the big flashing red banner ad, they're almost certain to come across it and they're almost certain to have common accounts stolen.
Using even a separate password manager, even an integrated one like LastPass raises the bar beyond this extremely basic level and takes it from easy target to medium target, eliminating every common stealer malware I've seen. This definitely doesn't rule out targeted ones of course, like you say, on an objective level there doesn't seem to be much of a difference. At a practical level though based on what's in the wild for non targeted attacks, it's huge.
I never let my browsers store a password to anything, ever. I rely on 1Password to supply all passwords, and having my browser also store a password doubles the attack surface.
Open source, open standard, generative password manager with "two-factor" security using both a passphrase and a private key file: http://rampantlogic.com/entropass/
It only uses the industry standard pbkdf2-sha512 hashing algorithm, with no encrypted database, so it is much simpler and isn't susceptible to these kinds of issues.
It looks like its mainly used for storing site login/passwords. I like to store other things too in password files like credit card numbers, notes ,etc.
I must say, Paul Graham is a really good writer. His posts are very eloquent and convey interesting ideas without extraneous fluff. Too often people credit famous individuals with talents they don't actually deserve, but in this case the quality stands independent of the fame.
