It's time for SaaS companies to stop charging their users for MFA/SSO. Looking at you Notion and Lokalize, just to mention a couple we use..
Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
21–30 of 33 posts
Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#22"migrating to programming languages that eliminate widespread vulnerabilities." "Some examples of modern memory safe languages include C#, Rust, Ruby, Java, Go, and Swift." "Too often, backwards- compatible legacy features are included, and often enabled, in products despite causing risks to product security. Prioritize security over backwards compatibility, empowering security teams to remove insecure features even…
lol java? mind as well pick PHP
Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#23It's time for SaaS companies to stop charging their users for MFA/SSO. Looking at you Notion and Lokalize, just to mention a couple we use..
The commonly used term is the SSO tax. See https://sso.tax
Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#24yeah, by default my ethernet cable is unplugged.
Harder to do with a smart phone though.
Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#25It's time for SaaS companies to stop charging their users for MFA/SSO. Looking at you Notion and Lokalize, just to mention a couple we use..
I'm really split on this.
MFA -> this seems like a no-brainer to have out of the box.
SSO -> if we're talking SAML and "mega corp looking to put everybody sync'd to their Active Directory" then it seems kind of reasonable. In part I think that the pain of employee onboarding/offboarding is just much more at larger corps.
Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#26"migrating to programming languages that eliminate widespread vulnerabilities." "Some examples of modern memory safe languages include C#, Rust, Ruby, Java, Go, and Swift." "Too often, backwards- compatible legacy features are included, and often enabled, in products despite causing risks to product security. Prioritize security over backwards compatibility, empowering security teams to remove insecure features even…
> The fundamental challenge is that by the time a "secure default" has been universally agreed on, and implemented widely in a space, the target moves again.
That is certainly true, but there is also such a thing as "definitely insecure default", which can (and I believe should) be discouraged piecewise.
Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#27"migrating to programming languages that eliminate widespread vulnerabilities." "Some examples of modern memory safe languages include C#, Rust, Ruby, Java, Go, and Swift." "Too often, backwards- compatible legacy features are included, and often enabled, in products despite causing risks to product security. Prioritize security over backwards compatibility, empowering security teams to remove insecure features even…
lol java? mind as well pick PHP
How so?
Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#28Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#29Earlier quoted context omitted.
All of those OSes are written in C, C++ and sputterings of asm.
The entire point of an OS is to handle low level unsafe stuff so the user doesn't have to. Writing in a lower level language doesn't just make sense, it's straight up necessary. Rust is the only "modern" language that's anywhere near the stability and maturity required, but it's still quite young and rough.
As a note, there are a few other languages that might get there eventually, including Zig and Circle.
Re: Shifting the Balance of Cybersecurity Risk: Security-by-Design and -Default [pdf]
#30Earlier quoted context omitted.
How so?
Because PHP is a memory-safe language? The problem with Java and PHP is not that they are insecure, its that there is barely any barrier for entry and thus much of the existing code is very low quality.
The problem with Java and PHP is mostly bad stdlib design although in completely different ways (PHP also has some weird footguns about equality but those are avoidable).
PHPs stdlib is of the "stickball" variety - they just started adding to it with no style guide, which has resulted in very inconsistent naming, poor rules and lots of security issues that they for ages had to fix with workarounds since people coded against the security issues as if it was correct implementationwise.
Java suffers from an overly interfaced stdlib; the stdlib pretty much only contains standards on how to do something rather than actual implementations. The result is that the default values in the stdlib are ancient/unsafe and also aren't amended, so you don't break compatibility with older Java APIs.
Basically both have too much low quality code in their stdlib which propagates out into bad library design (since the quality of the stdlib tends to the rest of the ecosystem - see how javascripts absurdly barebones stdlib led to it accruing thousands of microdependencies).