Duo Security's company blog (now Cisco) publishes security research on SAML, authentication, npm malware, and update mechanisms.
HN links its Beer Drinker's Guide to SAML as the best conceptual explanation; other comments discuss Duo's two-factor product and Cisco's ownership.
Some of the comments here seem to argue that creating legislation that demands basic security baselines will not get the job done. In fact in a recent interview[1] Jen Easterly (head of CISA gov) fell into the same trap (assuming because she didn't want to upset tech company lobby groups) so her message was reduced to shouting into the void (asking vendors "please be-good"):
> Addressing these issues requires a long-term approach and not simply a new set of regulations or industry standards. Easterly said it will require the leaders of technology companies to focus explicitly on building safer products, provide transparency into their development and manufacturing processes, and an understanding that the burden of safety should not fall solely (or even mainly) on customers.
I'm right now struggling to get a bunch of US IoT companies to agree on a very basic set of security standards that would allow more interoperability. All we're asking are basic best practice to anyone working in security (e.g. ETSI 303 645). And the reason why I'm struggling is because in the EU these baselines are becoming the law as of 1st Aug. 2024 with the Radio Equipment Directive (RED). And in addition these same kind of guardrails will also become law with the Cybersec Resilience Act in 2025 expanded to the cloud and mobile apps. So this thing is coming and the US which has a lot better standards (thanks to NIST but lacks legalization due to power of lobby groups) looks like a total laggard here…
1Password family has been hard to get everyone on… one or two people yes, but not the entire family.
YouTube Premium is probably the only thing everyone in the family uses significantly and frequently… but mostly because they don’t notice it. Netflix, Disney+ maybe go without saying. Alexa/Google/HomePods too, mostly for music playback. Spotify Premium has excellent family features also.
Background but storage from Google One, Apple and Microsoft Office are also frequently used and relied on.
For me the hardest part is actually telling family what they could have access to - I wish there was something like https://duo.com/assets/img/leadin-images/sso_leadin_img.jpg but included all the content, apps and subscriptions we share, regardless of service provider. Whatever it is, it has to have tight integration with mobile and desktop computers so I and others can push notifications like, “Amy just signed up for NYTimes, add a shortcut and saved password?” Or a banner appears or customized Kagi results that could say, “Listen on Spotify,” if that’s what we have signed up for would be nice.
I’m thinking it might work like Apple’s notifications for health and/or activity sharing, where you get to see what others do, but instead you get to see what you have access to via the family, etc.
I tried setting up enterprise style accounts and domains and even a Google Site for this purpose and it went nowhere. Everyone already has logins and identities and half the problem is no one…
Duo Security | Senior Application Security Engineer | Ann Arbor, MI or Austin, TX | ONSITE | https://duo.com/
We are Duo, and we’re here to democratize security for everyone. Our mission is to protect the mission of our customers like Facebook, Twitter, and Etsy by making security simple. We’re a diverse crew of makers and builders, skaters and coders, filmmakers and DJ’s, teachers and students brought together by a shared belief in adding value to the world. This diversity allows us to bring an empathetic approach to solve some of the most complex global business and security challenges we face today.
What you’ll do…
-Perform security activities, including security design reviews, threat modeling, code auditing, and security assessments on internally & externally developed software.
-Support product security issue triage, help coordinate 3rd-party security assessments, provide ad-hoc technical security expertise to product, sales, & engineering teammates.
-Create and maintain application security development policies, procedures & standards.
Skills you have…
- You have a strong understanding of many vulnerability classes impacting a variety of languages, with an expertise towards Python, Javascript, Java, C, C#, and Objective-C.
- You’re comfortable manually auditing code for vulnerabilities, using static & dynamic code analysis tools, building custom security tools, and bootstrapping test environments.
- You understand security engineering principles, and how to…
Note, Google in typical fashion has named 6+ products "Titan." (Titan M, Titan C, Titan Security Key (available in USB A, C, Bluetooth versions), Titan Security Module, OpenTitan, and maybe a few more if you count the old Bluetooth versions that were recalled that look identical to the new Bluetooth version).
The various Titan Security Keys are also made by Feitian who sometimes use the same auth chip and sometimes don't but externally look identical.
The products sole purpose is to establish a secure chain of trust and starts out the gate broken with ambiguous or misleading claims for verifying exactly which Titan it is.
Google will pay you $1 million to hack the Titan but not the Titan hacked here - the other Titan[1]. Furthermore they are happy to tell you that their products, like Google Cloud Platform, are "Secured by Titan" but not which Titan [2].
This is frustrating because the Titan M is an absolutely brilliant device, with some real advancements to normalize embedded security, including an SPI interposer to monitor communications (a real leap forward) - and should not at all be conflated with a generic, whitelabeled, non-hsm product that makes no claims whatsoever and has been broken at least twice before [3] [4]. The Titan C is an even bigger improvement over the Titan M but not in anyway they care to disclose which may or may not indicate weaknesses in Titan M [5]. Likewise, OpenTitan[6] is crashing through barriers others didn't even know were there in…
I don't think it's that the stack doesn't exist anywhere. It's more that the best authentication systems are siloed within a few select organizations and trust across organizations is spotty.
If I had to recommend a single simple+powerful auth system right now, it would likely be Duo Security[1].
And there are countries (SKorea, Estonia) and even organizations within the US (US DoD) which have largely solved authentication. SKorea and Estonia allow (require?) digital transactions to use their state-issued digital ID. The US DoD has ID cards, digital login systems, etc (although it's not clear to me how homogenous or "simple" it is).
Windows is working on "Hello".
Apple has (TouchID + FaceID + iTunes/iCloud).
Facebook properties use the FB auth stack(s).
Google properties use its auth stack.
Amazon properties use its auth stack.
I think the complexity is that there is no "one account to rule them all", but I'm not sure I would trust any organization listed above to not screw it up. The US DoD is probably best equipped to understand the needs of building a robust authentication solution, but they also have physical control of their persons and don't necessarily need to work on the timeframes that the other companies listed here work on. Every single organization I've listed has had at least one high profile data/IP breach, so I would argue it's the asymmetric nature of defense versus attack that is the problem in the current internet space.
[1] https://duo.com/
If you are interested in a conceptual guide to SAML, rather than a walk through which shows XML, this is still the best one I know of: https://duo.com/blog/the-beer-drinkers-guide-to-saml
Saw some simplifications in the post like where the signature goes (it can go in the assertion but also can go in the response) but appreciate this is a gentle intro, as the author states:
> I’ve omitted a lot of details here, some of which matter greatly for security reasons.
One thing about SAML is that, like HTML, the world is the best test case, and you can run into compatibility issues over and over (hyrums law and all that). My employer, FusionAuth, also supports SAML and has for years (first commit to our open source SAML bindings was in 2019) and there are still edge cases we run into.