Security keys 2FA #38
Replies: 3 comments 5 replies
-
|
Wow, impressive information exchange. Hard to follow for me at some points. Regarding 2FA, FIDO protocols: what do you think of the Yubico hardware key? Actual physical access is usually the weakest link right? Information would be greatly appreciated, as I mentioned earlier your cryptology knowledge is amazing, kudos. |
Beta Was this translation helpful? Give feedback.
-
|
"Yubico hardware key" However based on your description (sandbox debug with virtual machine): The weakest chain, unsure. |
Beta Was this translation helpful? Give feedback.
-
|
What would you recommend as a preferred method, for server management and security algorithms? |*| OpenSSH Oh and salting I suppose, since entropy is the issue and randomness if I'm correct? Memorizing 100+ individual keys with decent password strength is daunting. |
Beta Was this translation helpful? Give feedback.
-
|
For server managements, it much depends on the exact workflow, and expectations. For the proxy choice: If your potential adversary could confiscate your servers outright: Salting or not, if the input is already random-like (e.g. "/dev/random"): As for the various exploitations, it just met the aforementioned general reference. "Where there is a will, there is a way." "Memorizing 100+ individual keys ..." |
Beta Was this translation helpful? Give feedback.
-
|
Very well stated, appreciate the info, layout and forum. 🙏 |
Beta Was this translation helpful? Give feedback.
-
|
I'm curious, was my post edited for grammar?
Is this an AI exchange, Master & Explorer?
Am I just overthinking this?
In review, I don't think my grammar is, that great?
…On Tue, Dec 3, 2024, 10:22 PM Alice Lee Poetics (李 诗诗) < ***@***.***> wrote:
For server managements, it much depends on the exact workflow, and
expectations.
In general:
“Security doesn't itself come by following random security advices or
blindly deploying "security-enhanced" setup:
Well realizing the underlying implementation is the essence to
guarantee effectiveness and security.”
.
What ensures security is not obscurity but well defined implementation.
Well known or not doesn't really affect an implementation's security.
Counting on others' mercy is never a good practice.
For the proxy choice:
#30 (comment)
("AB/ABA structure multi-stage")
If your potential adversary could confiscate your servers outright:
You need to have some extra considerations.
Perfect randomness doesn't exist: it demands the property of infinity.
(while which practically unattainable; or doesn't exist)
All finite sequences must be deterministic. That is, known, certain.
Salting or not, if the input is already random-like (e.g.
"/dev/random"):
Salting won't make any real difference. (somewhat even, fancy no-op)
Salting specifically mitigates the case where the input is easily
guessable. (which is somewhat unsolvable; per the weakest-chain principle)
As for the various exploitations, it just met the aforementioned
general reference.
The XZ Utils one further proved why auto-update is bad idea.
"Where there is a will, there is a way."
However the price does matter.
Many things effectively working in such manner:
Truly unbreakable? No.
Just expensive enough to deter breakage.
The art of balancement.
"Memorizing 100+ individual keys ..."
Writing the credentials in Plain Text and keep it safe.
The crucial part is "keep it safe": essentially "well regulating the
execution environment (workspace)" aforementioned.
—
Reply to this email directly, view it on GitHub
<#38 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BIEVIXQM3SMVXJJ5KUQHSWT2DZ7SHAVCNFSM6AAAAABQVH3AH6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBVGY3TOOA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
For ease of access, generally. You may check the diff from the edit history. The thread gather is transcribed from corresponding links. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome we love it full transparency model, thank you..
…On Wed, Dec 4, 2024, 7:04 AM Alice Lee Poetics (李 诗诗) < ***@***.***> wrote:
For ease of access, generally.
I indeed use AI techs for linguistic analysis. And content generation,
partly.
(all posted contents are extraordinarily verified for quality)
You may check the diff from the edit history.
(probably you have to dump the content and use more effective diff,
for certain cases)
The thread gather is transcribed from corresponding links.
(some sources might be dead/deleted; the transcription keeps when last
accessed)
—
Reply to this email directly, view it on GitHub
<#38 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BIEVIXXOAQPVO3BVZYYBMUL2D34XLAVCNFSM6AAAAABQVH3AH6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBWGEZDCOA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
[[
[ MasterInQuestion @ CE 2024-10-24 01:53:34 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11035416
“Very strong password are not sufficient anymore for great account security.
Today, too many accounts are being hacked on all websites, even if they have strong passwords because there are much more powerful hacking techniques than just brut forcing their passwords.”
Password itself may function as if security key:
"/dev/random" derived, unique for each site.
When properly managed: much identical. (and likely more reliable)
See also: https://github.com/orgs/community/discussions/63813#discussioncomment-10626201
It appears many people have fundamental flaws on the understanding of security:
Thoughtlessly phasing things out in vain hope, for feigned sense of "security".
But failed to realize:
“Security doesn't itself come by following random security advices or blindly deploying "security-enhanced" setup:
Well realizing the underlying implementation is the essence to guarantee effectiveness and security.”
.
https://github.com/orgs/community/discussions/22814#discussioncomment-7571079 ]
----
[ Explorer09 @ CE 2024-10-24 06:37:50 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11036997
Why are we believing in a bulls**t that "Password itself may function as if security key"?
Passwords, no matter how random or secure you generated them, are the same tokens every time you log in.
Passwords are vulnerable to replay attacks. That was the reason for 2FA in the first place.
Applications that have to stick with password authentication are shifted to use personal access token as a password alternative.
Personal access tokens can expire after a set days, and have limited privileges per token: and thus reduce the risks of what passwords can do. ]
----
[ MasterInQuestion @ CE 2024-10-25 03:51:23 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11047758
Before bold assertion: do proper research.
Why would you fallaciously believe that random keys each time would miraculously increase security?
For some inconsiderate genius coined that the ideal encryption model would be alike, given the "absolute reliable" key-exchange channel..?
For really security-critical applications: 1 compromise already means done.
Reusable or not is already passé.
Your thoughts are exactly like those who coined security models that don't work at all:
Secure or not: much in question.
Functionality-wise: everything broken.
Your quoth of Replay Attack is also not much appropriate:
But whatsoever doesn't matter much. ]
----
[ Explorer09 @ CE 2024-10-25 08:02:58 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11049564
"Why would you fallaciously believe that random keys each time would miraculously increase security?"
I don't. I am just refuting your claim about passwords being secure enough.
If what you claim is true, why the heck do websites force 2FA on us? ]
----
[ MasterInQuestion @ CE 2024-10-25 11:46:16 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11051733
Thoughtless assertion that users are all thoughtlessly using literally "password" as password.
Some did alike, indeed.
But such apparently don't care about security.
Mostly nor capable of maintaining security.
Critical business demands operator competence: an unavoidable fact.
Good faith assumed, however:
Some just excuse this for data collection. ]
----
[ Explorer09 @ CE 2024-10-25 11:50:58 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11051892
There are a lot of password strength checkers you can find on the web.
Please don't assume we know nothing about password strength.
https://www.security.org/how-secure-is-my-password/
https://bitwarden.com/password-strength
https://www.passwordmonster.com/
For your argument about data collection, yes.
This is my own reason not to use 2FA approach other than the security key:
SMS based 2FA leaks your phone number.
App based 2FA (including TOTP) requires you to trust the app - something can be programmed to spy on you.
Hardware security keys stay offline until you need them for authentication: so it is the best 2FA approach for people who have privacy concerns. ]
----
[ MasterInQuestion @ CE 2024-10-25 12:32:50 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11052259
I don't. Find who force 2FA to blame.
Hardware-based are not necessarily safer than software.
And actually hardware and software cannot really separate...
The key benefit of security keys alike: is the key generation core being not easily copiable from outside.
In some cases this may of help.
But do note: operating security keys in untrusted environment still presents the risk of session hijacking. ]
----
[ lriley2020 @ CE 2024-10-25 12:47:07 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11052347
Just to add to the discussion about SMS 2FA.
Not only is it collecting even more user data, but it is shockingly easy to hack an account with SMS 2FA:
A simple social engineering attack (for example calling the user's phone company and asking for a new SIM card for that phone number) will easily bypass the security.
And there are many documented examples of that specific "SIM swap" attack happening in real life. ]
----
[ Explorer09 @ CE 2024-10-25 12:42:40 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11052362
"Find who force 2FA to blame."
GitHub.
"is the key generation core being not easily copiable from outside."
Hardware security keys rely on physical security.
Yes, the key themselves can be cloned if they are physically stolen.
But remote stealing of security key data is very unlikely (because NFC requires a very close range (a few centimeters) to communicate).
As long as I physically hold my keys (thus having control on the physical security), there is no security weakness with the keys. ]
----
[ MasterInQuestion @ CE 2024-10-26 10:44:20 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11052638
Depends how you use it.
Eventually fallback to the key problem: key management.
Note what adversary targets is your access: not necessarily you keys. ]
----
[ Explorer09 @ CE 2024-10-25 13:22:28 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11052767
Your argument was about passwords being as strong as the security key.
While we refute your arguments, you are now dodging questions.
Don't propose any substitute for security keys while you know little about security keys.
This whole thread is about "we want security keys as an exclusive second factor; no TOTP", and discussions about password strengths are already off-topic.
Please don't waste our time. ]
----
[ MasterInQuestion @ CE 2024-10-25 13:49:32 UTC:
https://github.com/orgs/community/discussions/22500#discussioncomment-11053108
I don't use it doesn't mean I don't understand the technicality behind.
The point was not on keys themselves, but security.
Note my original "much identical", not "identical".
I've explained the primary differences.
On-topic with the adjacent posts.
Per main topic OT in deed. ]
]]
Beta Was this translation helpful? Give feedback.
All reactions