timothy-quinn

This is how most critical articles of crypto end. They criticise the algorithm or system, and then don't offer much in the way of solutions.

They _do_ suggest using ECC, but in practice ECC support is super sporadic, and a lot of products charge extra for it.

The value of hooks became apparent to me after working with a very large react-redux application. It was so large and the forms had so many elements that the capture of data, testing, and subsequent state management in redux was enormous.

It wasn't overly complicated from a technical perspective, but when there were forms with say 50-100 different inputs and dozens of state transitions, it was a mentally taxing experience every time to try to maintain the data model and state machine in my head when debugging or introducing changes.

For me the introduction of hooks was amazing as it's allowed us to strip most of the redux state management in favour of managing state with hooks inside of functional components. We still use redux for global application state, but there are also hooks for interacting with that redux state too.

We effectively went from class-based components in react-redux with say 500 LOC in each class, 500 LOC in each action file, 500 LOC in each reducer file, all the way down to about 700 LOC in each functional component file.

I do agree though that debugging sucks. It's incrementally getting better, but it's got a long way to go.

Thanks to this I've found building a product in the cryptocurrency market has been the most challenging for applying typical online marketing strategies - I've exhausted most avenues of advertisement - basically the only tools left are the more expensive sponsorship arrangements as every advertising platform will instantly reject your content.

I can appreciate why the pendulum swung hard against ads - it's incredibly hard to differentiate between real and fake ICOs, and we're seeing that again with the defi craze at the moment. It's just made it so much more expensive as an emerging company to try to sell services in this market even when you _aren't_ trying to sell a coin.

Support for PIV cards on Linux/Mac is kind of sporadic, and very much DIY. In most cases authentication gets kind of tricky because you need to set up everything yourself on the workstation.

For web-based certificate authentication, if you follow instructions for setting up CACs, then you're usually good (but you have to just ignore the US Military specific stuff): https://militarycac.com/macnotes.htm

Yubico also provide some instructions for each platform: https://developers.yubico.com/PIV/Guides/Smart_card-only_aut...

https://developers.yubico.com/PIV/Guides/SSH_with_PIV_and_PK...

In the end though a centrally managed authentication solution isn't really easy a quick and easy set up for *nix or Mac, unlike Windows with Active Directory. Perhaps in the future something better will come along.

And the same applies with iOS and Android - I've seen some pretty hacky products where they'll interface with smart card readers onto phones do things like authentication to websites or email encryption, but in the end you had to use the vendor's browsers/mail clients instead because only they could handle the integration with the PIV cards. YubiKeys can now connect to phones too, but you've gotta have the right combination of YubiKey and phone to get that connectivity going - and you're still limited to what the apps on the phone actually support.

I think we all end up on our own journey of trying to find the note taking style that works best for us, and the variety of styles (git, onenote, evernote, pen & paper, notes app, etc.) has lent to a variety of applications being built to cater for each.

I've got my own slightly different style of note taking that works really well for me, but only when I start to work on multiple projects simultaneously and I need a way to track tasks across them all. When I fall back to one or two projects, then my note taking needs disappear. I joined the fray anyway and turned it into a web app so I could at least have something that _I_ want: https://screwnotes.com

Exactly - but the reactions I saw when he first released Pwned Passwords was "this is a malicious tool, don't give your password to anyone". Even if you're hitting the API from your own service, you need the entire password first to submit the partial hash to the API.

We who understand what's going on know it's perfectly fine, but it's hard to get that message across. Just like the first time you try to explain what a hash is to a non-technical person.

I've always found HIBP in this funny conflicting situation - on hand you should never provide your email or password to a 3rd party service because it's probably malicious, but on the other hand in HIBP's case it's very evidently not malicious, so it's totally fine. But it's evident only if you follow Troy for a while to see what he's doing.

I think it's a good study in game theory at the least.

The Aus Government has a good guide called the "Essential Eight" for reducing risk. It's a good starting point for businesses, and is pretty much universal advice, not just applicable to government departments: https://www.cyber.gov.au/publications/essential-eight-explai...

My take on the E8: https://blog.congruentlabs.co/essential-eight-essentially/

So far GA is answering two important questions for me - which marketing strategies are actually working (because it's hard to tell when you've got multiple going at once), and also making sure my marketing is actually hitting the geo-regions I need it to.

That said though once I know which marketing tools are effective, there's nothing more that GA does that CloudFlare couldn't just tell me anyway (i.e. am I getting more or less traffic) and I'll probably drop it as it's one less dashboard to look at - like you said that conversion to subscriber _is_ the ultimate metric for success.

Yeah that's why I added the "if" - But I have seen a lot of very small teams running AD (or Azure AD if they've chosen the Microsoft path), but they tend to just be paranoid about security or running in countries with poor internet connections.

Microsoft also provide pretty cheap deals for startups if they want some basic infrastructure for the office (excluding the hardware of course), so it's not entirely out of the equation on the licencing side either.

Really small teams typically will find U2F auth easiest to work with in the beginning, and then after hitting like 20 users they'll bump into problems like a large enough number of connected systems that they need to manage 2FA for.

Oh yeah good point, I always forget about the OATH part of the YubiKeys - unfortunately it's like the OTP feature in that I haven't had enterprise customers asking me about it at all (they're all hyped about U2F), so I start to forget its there.

I'll have to add it in to the article :)

Hi! I'm actually the product manager for the product mentioned in that article: https://enterprise.signata.net.

Are you heavily SaaS based for the tools you use in your startup, or do you have some on-prem infrastructure? That'll kind of dictate which path you should go down for provisioning the keys to your users. Our product will be perfect if you're using AD & a Microsoft CA internally (or are willing to set one up), as you could then just set up 3 YubiKeys for each employee, all loaded with certificates for authentication.

And, should one be stolen or an employee leaves, just revoke the certificates on it to kill the access immediately.

Any path you go down should really still only take a bit of time upfront and almost nothing longer term, unless your team grows fast.

You can also hit me up at [email protected] and I can give you more advice if you don't want to mention specifics publicly.

It depends on the context really - I love the push-driven MFA products, but they specifically require you as a user to be carrying a phone with you at all times, and are usually considered "low" assurance of the user's identity.

If your business is seeking "higher" assurance (yes, assurance levels are very subjective) then certificate-based MFA can meet the needs better. Or, if your business is working with sensitive data/systems, phones may be banned from the office (e.g. military, intelligence, banks, etc.).

Yeah Nitrokeys are probably the closest device, but cost even more https://www.nitrokey.com/

And usually it's twice what they charge, because you need a backup device to handle losing the first one.

I'd like to see a competitor come out with a combo PIV card & FIDO device. At least from the enterprise perspective it would cover 99.9% of MFA situations. And the majority of my personal uses of YubiKeys.

Luckily I wrote down the steps I took. Based on this, but the original seems to be gone now: https://nicluo.com/projects/secure-your-mac-with-yubico-u2f-...

  brew install pam-u2f
  mkdir -p ~/.config/Yubico/
  pamu2fcfg > ~/.config/Yubico/u2f_keys
  <Press the U2f device>
  cat ~/.config/Yubico/u2f_keys # should output <your username>:<really long hash>

  In /etc/pam.d/screensaver 
  Add to the top:
  auth       sufficient     pam_u2f.so

  In /etc/pam.d/authorization
  Add to the top:
  auth       sufficient     pam_u2f.so

I've personally never seen it work that way - usually because RDP doesn't pass through direct USB devices, only their abstracted forms (e.g. smartcards don't get passed through, only the "Smart Card" device registered in the OS, and only if you enable that to be passed through in an mstsc session.

There are products like Silverfort (https://www.silverfort.com/) that can handle agentless auth, and might be able to do that kind of MFA inside an RDP session. But, products like this usually require some 3rd device (i.e. your phone) to perform the MFA action, which is kind of not really just a simple WebAuthn logon...

Does anyone use YubiKeys on OSX for business use? I've tried integrating them on my personal mac before, but the U2F PAM experience was pretty clunky, and caused weird messages from services like Keychain that (I guess) couldn't decrypt without normal credentials being provided at logon.

Probably a backup. It makes sense to have an offline backup in cleartext (for DR), as long as you have the appropriate storage and security controls in place to protect it.