> Are you perhaps referring to the Google Authenticator or the Microsoft Authenticator apps when you refer to TOTP
No, I'm referring to the actual RFC 6283 TOTP protocol. Which uses a trivially-cloned single private key. Which is, see the example above, in fact trivially cloned 'for convenience' by at least one widely-used 'enterprise' security solution.
> What makes you think they don't "securely" make a few duplicates themselves?
Since that literally makes no sense if you know how hardware tokens work.
Since about the moment that teams all over the world discovered they could just paste the enrollment QR code (a.k.a. private key) into their wikis, and thereby continue unlimited sharing of their role accounts?
The TOTP "private key" can be easily cloned. Targeted malware, a database compromise at your app provider that you "securely" sync your settings to, or just a few minutes access to your "authentication" device, will do the trick.
Yet, if you go into the "enable 2FA" settings on Github, you only get the option to enable insecure TOTP or SMS.
Apparently, once you do that, you might be able to add proper authentication. But no word on whether that then replaces the obsolete methods you were forced to configure earlier.
But, yes, right on track to enforce 2FA in 2023, I see...
Oh, that's lovely UX... "After you configure 2FA, using a time-based one-time password (TOTP) mobile app, or via text message, you can add a security key"
So, after you enable a broken-by-design 1.5FA method, which you don't want, and which will further expose you to account takeovers, you can, possibly configure actual security.
No wonder these guys are raking in the big bucks...
Well, given that Github today doesn't seem to support meaningful 2FA (only TOTP and SMS), wouldn't it be good to fix that issue before starting to talk about requirements like these?
Maybe it's just my account, but I can't currently enroll my hardware token with Github in any way whatsoever.
Sure, they offer some 1.5FA, but why would I bother with that?
@john_cogs: Are there any plans to connect a self-assessment of mental state to the assignment of issues/pings about mentions/incident-response pages in the GitLab app?
So, on "I'm on top of the world" days, I get assigned All The Issues, get a full-screen popup about each mention, and will be asked to be incident lead on just about anything.
Then, if my state is "slightly hungover", I mostly get a list of the most pressing issues still pending, without being overloaded with new stuff.
And finally, the "hugging my teddy bear" state: no additional automated workloads, respectful notifications to anyone pinging me, and a note to my manager if it lasts more than a few days?
Short-and-easy read that contains much truth. Especially item #10, "Lead by example" which encourages managerial review of recurring meetings (which often boil down to "well, here is my Excel sheet, you tell me how you're doing on each line item: I'll let you talk a lot, but I'll only jot down the completion percentage in the end") is worth emphasizing.
Well, the race to attract the outflow of the current Russian 'brain drain' is definitely on.
If the US is able to attract the majority of that (as it most likely will), while keeping out the Putin-aligned plants and/or otherwise mentally deficient factions (which remains to be seen), that will definitely be huge gain for them.
It doesn't seem they even tried this in this case? So this should be a dismissal right away, albeit at great emotional/monetary expense to the original owner. Unfair, but yeah, cryptobros will be cryptobros, and any harm to members of society is just for the good of society, I'm sure...
(Later edit: so, apparently I'm wrong, and there is no binding arbitration clause. Still, lame action, and this seems the exact situation arbitration is designed for, especially since 'local courts' is not exactly well-defined for .com...)
This is held up as a great example of transparent communication. For me, this is true, but only for the meaning of 'transparent' which equates to 'you can see right through it, to the extent there is effectively nothing there'.
But as per the article this comment thread is about, this kind of response apparently the 'professional' state-of-the-art.
Ah, yes, the same kind of guide that brought us "how to professionally respond to outages"... With classics like "We recognize the incident", "a small subset of customers", "degraded performance" and "the next update (which will be the exact same meaningless drivel as the current 'update') will be in 60 minutes". Don't we just love those? So let's add more of that to the shared vocabulary of IT professionals!
Or... let's just not? In writing, always avoid clichés. Whether it's "do the needful", "by utilizing" or "we did not live up to our customer's expectations", there is one simple rule: if you've seen the exact same sentence or expression before in the exact same context in the last week or so, you should probably avoid it.
And if that makes you unsure what exactly to say, just type what you mean, then get an editor before posting it to your blog or incident report. And if it's time-sensitive, then just ask for forgiveness later, not permission upfront (which is also a cliché but reworded, see what I did there?)
My question is whether Intel investing in AVX-512 is wise, given that:
-Most existing code is not aware of AVX anyway;
-Developers are especially wary of AVX-512, since they expect it to be discontinued soon.
Consequently, wouldn't Intel be better off by using the silicon dedicated to AVX-512 to speed up instruction patterns that are actually used?
Still, what does it signal that vector extensions are required to get better string performance on x86? Wouldn't it be better if Intel invested their AVX transistor budget into simply making existing REPB prefixes a lot faster?
That's hard to dispute, but will you accept https://guide.duo.com/duo-restore as a counterexample?
> Are you perhaps referring to the Google Authenticator or the Microsoft Authenticator apps when you refer to TOTP
No, I'm referring to the actual RFC 6283 TOTP protocol. Which uses a trivially-cloned single private key. Which is, see the example above, in fact trivially cloned 'for convenience' by at least one widely-used 'enterprise' security solution.
> What makes you think they don't "securely" make a few duplicates themselves?
Since that literally makes no sense if you know how hardware tokens work.