I read the post. It seems to be mainly applicable to statically-typed languages. Apparently, the core problem with validation is "shotgun parsing":
> Shotgun parsing is a programming antipattern whereby parsing and input-validating code is mixed with and spread across processing code—throwing a cloud of checks at the input [...]
> The problem is that validation-based approaches make it extremely difficult or impossible to determine if everything was actually validated up front [...]
Err, what? So validating against a well-defined schema won't necessarily cause this. But okay, again, I can buy the benefits for statically typed languages. There's more though:
> Don’t be afraid to parse data in multiple passes. Avoiding shotgun parsing just means you shouldn’t act on the input data before it’s fully parsed [...]
> Use abstract datatypes to make validators “look like” parsers. Sometimes, making an illegal state truly unrepresentable is just plain impractical given the tools Haskell provides, such as ensuring an integer is in a particular range.
I've experienced this in Java/Jackson (which btw, proves this is not exactly new, sexy, or rare in the statically typed world).
What is the suggestion for a dynamic language? In e.g. Javascript, classes will only get you so far, and seems needlessly heavyweight if you aren't going to get other benefits of type-safety. I really don't see how this is helpful, even after putting in the time to investigate this.
In JS, my preferred way of handling json is heavily inspired by the elm json decoding way.
I want my decoders to essentially do 2 things:
1. Transform received data into a data structure that is best suited for my app. This might involve converting lists to objects, objects to sets, parse dates etc.
2. Only succeed on valid data
This way, my application never has to deal with bad data. Also, I get to design the data structures I use, not the APIs I use. By only validating and not transforming, you are pushing more advanced validation further away from where the data was received (since you'll need to transform the data at some point anyway).
You might be interested in lamdera.
It abstracts away database access, data transport and data encoding between client end server.
Here is a talk about it: https://www.youtube.com/watch?v=nSrucNcwlA8
If you're interested, you can probably get an invite from @supermario on the elm slack, or on: https://lamdera.app/
Disclaimer: I'm not affiliated with the project, but I've met Mario in person and he's a cool dude with great ideas ;)
Thanks. I was always wondering why others don't do this more often.
I find it much easier to remember and type in a few words compared to a long number.
You lose access to your passwords, that's the consequence of that approach.
That's why it's a very good idea to pair as many devices as you can, e.g. an old phone, your work PC, etc.
This way you're pretty save from any loss.
In general, if you save your passwords with security level N (meaning you need N devices to unlock), if you lose all but N-1 devices, you lose access.
You can also add a "key box", which gives you one more "device", but requires you to remember a password.
> That's why it's a very good idea to pair as many devices as you can
Doesn't this increase your attack surface greatly though? The more devices you have this on, the greater chances that one or more of them could be compromised and used to access your passwords. Since there's no master key, one has to only compromise the OS to get at everything. Given that so many devices do not receive regular security updates, this seems like it would be a concern..
> Doesn't this increase your attack surface greatly though?
That's true. I suppose it's a trade off between protection against lost vs. smaller attack surface.
> Since there's no master key, one has to only compromise the OS to get at everything
That's wrong, compromising one device doesn't give an attacker anything useful. Only if two or more devices have been compromised can passwords be decrypted.
But in any case, I think if your device is compromised you might be in bigger troubles anyway.
E.g. if an attacker controls your device, ransomeware might be easier and more lucrative to them than going after more devices to hunt for passwords.
> That's wrong, compromising one device doesn't give an attacker anything useful
Yea I understand that, but by having a large number of devices with this on it, you increase the chances that any two of them could be compromised. That was my point, I just didn't articulate it well enough.
My GitHub.com password is >100 characters long and I deem it a critical account (hence the password length), so yes, I do use a password manager for it.
This is my first time posting something to HN, so please be kind.
I wanted to show what I’ve been working on for the last 6 months:
NoKey, a password manager without a master password.
Instead, you can unlock your passwords by confirming from another device. E.g. if you need a password on your PC, you only have to confirm this on your phone. No need to remember any passwords!
The vast majority of the code is written in Elm and it’s fully open source.
There is a browser extension for Chrome and Firefox and an Android app.
The application is only useful with at least two devices, so to really test it out, you’ll have to install it on two devices.
There is no iOS version and the web app doesn’t work on Safari either (it's missing some stuff from the Web Crypto API), sorry!
Any feedback or questions are greatly appreciated!
I love the Idea, and I think it's pretty smart.
When I'm doing work on my laptop, I always have my phone nearby. I think it's unlikely that both of them are compromised or stolen simultaneously.
Also, the Android app requires no device permissions, haven't seen that in a while.
That's not true, it just uses the new way to ask for permissions. E.g. when you want to scan a QR code it requires the camera permission. But it only asks at that moment, not upfront as older android apps used to do
Yes, but it's a very bad idea.
If you'd do this, you could unlock your passwords with a single device by confirming on Firefox or vice-versa on Chrome.
This of course also means that if someone steals this device, they can unlock it too.
Yeah. That's what I don't want. So how do you prevent someone doing just that? They have Chrome open. They then confirm setup in Firefox using Chrome on the same device.
When pairing a new device (or in this case a new browser), that device doesn't automatically get any keys! When adding a new device, to complete the setup you also have to be able to unlock a password group, for which you need another device that already has keys.
In short, a new device doesn't have the same power as the others from the start, first new keys have to be generated which can only happen if you are able to unlock your passwords.
So just don't setup both the Firefox and Chrome extension and you're golden.
That's pretty interesting. It's a trade-off between remembering a password and making sure you have enough devices. I personally would trust my brain (and a backup piece of paper) more than one of my devices that might die at any moment. I use KeePass, but NoKey seems great.
But wouldn't you agree that your brain + NoKey instead of a piece of paper as a backup would be more secure? And more convenient, as you don't have to type your passwords anymore.
I don't wanna push you, just wanna give you some things to think about. As long as you use strong and unique passwords everywhere you're good.
Also, it's not a big problem if one of your devices dies, as long as you paired enough devices you won't lose any passwords.
Ah ok, got it. If you are already using KeePass than there is no reason to use NoKey, KeePass is great!
> Not everyone has a million devices.
I don't think that's fair. With 3 devices you're perfectly ok. Or even with only 2, if you also use a "key box" (gives you one "device" more at the cost of having to remember a password).
I only routinely use 2 devices. I'm very heavily into the tech scene and could afford more devices if I wished.
Some people don't live in a place where it's easy to afford multiple devices.
Many non-tech people don't even use a desktop PC anymore. They just have a smartphone.
Believe what you will, but it is certainly fair to say not everyone has enough devices for this service to make sense. For example, me, with 2 devices.
>If you are already using KeePass than there is no reason to use NoKey, KeePass is great!
