I got so pissed when they threatened legal action as a way to "entice" me to upgrade my individual subscription into a team license that I quit it 6 months early. Now at a new company I jumped at the chance to cancel a 90-seat annual contract and we have not had any complaints from the department.
something doesn't add up, because I don't see how this extrapolates from stealing privileged Snowflake employee credentials. How does that become a keylogger on a client's computer?
"they were able to sign into a Snowflake employee’s ServiceNow account using stolen credentials, thus bypassing OKTA which is located on lift.snowflake.com.
Following the infiltration, the threat actor claims that they were able to generate session tokens, which enabled them to exfiltrate massive amounts of data from the company"
Yes, but how should ServiceNow create session tokens if it is not part of the SSO system? I don't know enough about ServiceNow, but I think every large company has some products that are not part of their-SSO system. So that makes sense, but I am not sure about the next step.
>> This is a new, agile, cloud-first company that grew very quickly and has faced significant turnover.
This is not really true of Snowflake, which is not some 2-person YOLO startup, and it's also pretty irrelevant as the weakest link is often a single employee regardless of the size or industry of the company. In my experience the support and security is way better than average - example: as a client of both Snowflake and Sisense, Snowflake reached out to me about the Sisense breach before Sisense did.
Its support and security posture could very well be better than average.
Looking a other breaches (Qlik Attunity, Microsoft AAD, ...) indicates that being better then average is not enough if you're a sufficiently attractive target.
The timing is super important. Writing on a chalk/whiteboard or overhead takes time, which is required to absorb the content. Hitting the right timing and cues with this approach seems like it would take a lot of practice, which isn't a deal breaker, though I believe the 2 biggest problems with most presentations is too much/too fast content, and not enough practice and this approach might make those both harder, not easier.
The beauty of this proposal is that it isn't a new standard -- it's suggesting that we use the already existing words and stop using the less understood acronyms.
authn/z are more abbreviations than acronyms, which come with less organization or domain specific required knowledge, which is the typical complaint of acronyms
I don't really get the point of this post. Yes naming things is hard, but the fact that these two words are similar is actually a good thing, despite laypersons getting them confused, because they are both functionally and implementation-wise closely related. The confusion is not going to be solved with trying to relabel the concepts. The author never actually illustrates the harm caused by this confusion either. My guess is they ran into something like installing a package that didn't cover their desired needs, attributed this to the "auth" name and instead of moving on decided to write about it.
>> "The canonical solution is to call these "authn" and "authz", the n and z evoking the longer words."
My experience: a lot of the confusion in technical conversations is due to two parties using the same term for different but related concepts. Relabeling the concepts to clarify the distinction is the right thing to do.
>> or could we just use longer words?
Agreed: relabeling, with longer words when necessary, can help.
The toolbar is called "tool controls bar," the tool controls bar at the left is called "toolbox," and the toolbox at the right is called "commands bar."
If you asked me I'd say it's 3 toolbars. And why is palette not palette bar?
If I had to guess, one day the author was having a personal moment where they realized they had been using auth incorrectly in some way, then started a blog post for ranting purposes. During research for the blog they realized they were probably just personally wrong but had invested too much time to just delete the post. And here we are.
Because what we call electricity is electrons moving. So it would make sense for electrons to have the electric charge.
Now we are in a weird situation where current flows from positive to negative, but electrons flow from negative to positive. It would be a lot more logical if the direction of the electrons was the direction of the current, but the name was arbitrarily decided before we knew what electrons were.
This seems to warrant an appreciation for the nuances of the electromagnetic field, electric potential, and that electron drift in a conductor isn't really the same as varying potentials in the electromagnetic field.
Electricity is generally defined as a flow of electrical charge(s). Nobody except scientists care to know which way the electrons went because we never run out of them.
Chemists building batteries might disagree with you. They have to understand which direction the electrons flow and which elements they are using have the free electrons to spare.
By convention, electrical current flows in the direction of the movement of positive charge.
However, in the typical case, what's moving is electrons, which means the "current" is flowing in the opposite direction of the movement of the electrons. This is stupid and everyone hates it.
In addition to the sibling comments, I have a somewhat esoteric reason to wish that the signs of electric charge were reversed.
In the coordinate system of an atom, the nucleus is at the origin, 0, while the electrons are a positive distance from that core. 0 is not negative, obviously, but it's non-positive.
When terminology is concordant in this way, the topic is easier for a student to grasp. When discordant, harder.
There's little chance for this wart to be remedied, invalidating every paper written up to that point is a bit of a non-starter. But I dislike it nonetheless.
Also when you're learning organic chemistry, where you need to mentally push electrons around molecules which are diagrammed in a highly compressed notation, the negative charges add just a bit more to your working-memory load (which might've already been on edge of what you can handle without dropping something) until you've had enough practice to compile the patterns down.
Negating when you move electrons is just one more step, but so is negation within a complex expression in language or programming, and we do try to avoid piling that up.
Chemistry was my major, and I considered adding this very point, but wasn't sure I could do a good job of explaining what the problem is. You did a great job there ^_^. Yes: there are positive 'holes' that you push a negative number to and then subtract. This is entirely backward and adds considerable difficulty to an already difficult operation.
Because in an electrical current it is electrons that move (usually, unless you have a hydrogen plasma or something), so since electrons have a negative charge, the direction of the positive current is the opposite of the direction the electrons are flowing.
Hey, as long as we are rewriting history, we could go with different names too.
Both the names of the things and which one was positive were arbitrarily assigned and I just think some mistakes were made… from a teachability/usability perspective.
Like the original USB inventor not making usb reversible from the start.
For some reason, with both words, I have to stop and think about what the "other auth- word" is so I can be sure I'm thinking of this "auth word" correctly.
1. Sees <authentication>
1a. "That's who I am, but to be sure..."
2. "Ehh... the other one is... <authorization>..."
3. "<authorization> is what I'm allowed to do so..."
4. "...yes, this one is who i am"
Seriously, every time. I probably worried I'd remembered it backwards at one point early in my career and have never shaken the habit of double-checking myself on it.
I did the exact same thing when I was reading the post! I had to stop reading and take a good 10 seconds to verify which one was which in my head. I use "auth" all the time as a placeholder for "you need to login to use this". I've never really thought too much about authorization versus authentication because to me, those are just implementation details under the "auth" umbrella.
we could but don't expect anyone with dyslexia noticing that a text says authorization when they subconsciously expect authentication (and don't explicitly double check)
Through also if we use AuthN and AuthZ (with capitalization) it's quite clearly readable and hard to mistype and no longer the kind of words dyslexia makes it easy to misread (it never was in the category of things dyslexia makes easy to accidentally mix up when writing I think).
Using authorization and authentication also can have issues if you use a text editor with auto completion, for AuthN/AuthZ you simply could not use autocompletion.
> My guess is they ran into something like installing a package that didn't cover their desired needs,
or got into problems because they used the wrong term in technical documentation, maybe in context of a security review or a requirements document which has been legally binding singed of
> The confusion is not going to be solved with trying to relabel the concepts.
Especially given that login likely implies both AuthN and AuthZ so it's not even "just" relabeling.
reply