profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/abergs/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

abergs/Crowdspell 37

The crowdspell service client scripts

abergs/Butler 6

Simple .NET CMS - Build your site as you wish, then add Butler to handle editable content. Read more in the readme.md

abergs/Dibs.Client 2

A client for DIBS payment using form POST. Includes all the .net classes used for HMAC encryption. It also have .NET classes for postmessage and callback response.

abergs/andersaberg 1

Me on the internet

abergs/ApplicationInsights-dotnet-server 0

Microsoft Application Insights for .NET Web Applications

abergs/AsyncUsageAnalyzers 0

Analyzers for asynchronous .NET code

abergs/awesome-typescript-loader 0

Awesome TypeScript loader for webpack

issue commentektrah/nsec

KDF: Difference between adding context in sharedsecret vs info?

@ektrah Hej! Så trevligt att möte en granne.

Thanks for the detailed reply. I'm working my way through the PDF. Not being "fluent" in cryptography, I must admit some concepts are not easy to grasp.

The "passphrase" in my question above is however a simplification. My idea was to use a static random value (e.g uuid/long random string/ 32 random bytes) and then supply a "userId" to make sure the key source is different for each user.

From reading the PDF, I'm still not sure if a static (seldom rotated) source of 32 random bits is considered a safe source.

Supplying the UserId as salt would not be enough from that I can understand (value can be known but must be random) - but a sha256(userId) would be a suitable salt.

The derived key would be used to HMAC shortlived API payloads.

If your open to discussing this more I'd be happy to share some more code and then make sure to write up something so that others can learn from my mistakes 🙂

abergs

comment created time in 12 days

push eventpasswordless/passwordless-nodejs-example

Anders Åberg

commit sha 055b363c8aa2391add579bc5a9599d0bccb3e04b

Don't force alias

view details

Anders Åberg

commit sha 98261b57e9872992442705aa35472d1833b1d814

Made need for unique alias more visible

view details

push time in 14 days

issue openedektrah/nsec

KDF: Difference between adding context in sharedsecret vs info?

Hello,

I'm wondering if there are any practical differences if I encode "context" into the shared secret vs adding it in the info?

Alt 1:

var passphrase = "my-secret" + username;
var secret = SharedSecret.Import(Encoding.UTF8.GetBytes(passphrase));
var key = KeyDerivationAlgorithm.HkdfSha256.DeriveKey(secret, null, null, MacAlgorithm.HmacSha256)

Alt2

var passphrase = "my-secret";
var info = Encoding.UTF8.GetBytes(username);
var secret = SharedSecret.Import(Encoding.UTF8.GetBytes(passphrase));
var key = KeyDerivationAlgorithm.HkdfSha256.DeriveKey(secret, null, info, MacAlgorithm.HmacSha256)

While using this library, I missed some practical guides. Would you like to receive contributions with "scenario" guides, e.g. "Using NSEC to HMAC your data and then verifying it"?

created time in 14 days

startedektrah/nsec

started time in 14 days

pull request commentpasswordless-lib/fido2-net-lib

Support MDS3

Is there any breaking changes related to UserVerificationMethod?

aseigler

comment created time in 15 days

pull request commentpasswordless-lib/fido2-net-lib

Support MDS3

Not to self: I need to fix that label verification spam.

aseigler

comment created time in 15 days

create barnchabergs/passwordless-blog

branch : main

created branch time in 16 days

created repositoryabergs/passwordless-blog

Blog content for passwordless

created time in 16 days

push eventabergs/ideasofanders

Anders Åberg

commit sha 36a6b1d3e1aa30416aa3882109fd167e2b97237a

Grafana for slack

view details

push time in 23 days

Pull request review commentpasswordless-lib/fido2-net-lib

Support Multiple Origins

 protected void BaseVerify(List<string> expectedOrigins, byte[] originalChallenge              // 5. Verify that the value of C.origin matches the Relying Party's origin.             if (!fullyQualifiedExpectedOrigins.Any(o => string.Equals(fullyQualifiedOrigin, o, StringComparison.OrdinalIgnoreCase)))-                throw new Fido2VerificationException($"Fully qualified origin {fullyQualifiedOrigin} of {Origin} not equal to fully qualified original origin {fullyQualifiedExpectedOrigins} of {expectedOrigins}");+                throw new Fido2VerificationException($"Fully qualified origin {fullyQualifiedOrigin} of {Origin} not equal to fully qualified original origin {string.Join(", ", fullyQualifiedExpectedOrigins)} of {string.Join(", ", expectedOrigins)}");

I think 5-10 should be enough. Our original intention was to make sure the developer understod what value we were expecting. I think we could include a count just to avoid confusion now that we are hiding some.

Hinton

comment created time in a month

PullRequestReviewEvent

Pull request review commentpasswordless-lib/fido2-net-lib

Support Multiple Origins

 protected void BaseVerify(List<string> expectedOrigins, byte[] originalChallenge              // 5. Verify that the value of C.origin matches the Relying Party's origin.             if (!fullyQualifiedExpectedOrigins.Any(o => string.Equals(fullyQualifiedOrigin, o, StringComparison.OrdinalIgnoreCase)))-                throw new Fido2VerificationException($"Fully qualified origin {fullyQualifiedOrigin} of {Origin} not equal to fully qualified original origin {fullyQualifiedExpectedOrigins} of {expectedOrigins}");+                throw new Fido2VerificationException($"Fully qualified origin {fullyQualifiedOrigin} of {Origin} not equal to fully qualified original origin {string.Join(", ", fullyQualifiedExpectedOrigins)} of {string.Join(", ", expectedOrigins)}");

We should probably add a .Take(MAX_ORIGINS_TO_PRINT) to the list before string joining to stop a very long list of origins to generate huge strings in the exceptions

Hinton

comment created time in a month

PullRequestReviewEvent

Pull request review commentpasswordless-lib/fido2-net-lib

Support Multiple Origins

 protected void BaseVerify(string expectedOrigin, byte[] originalChallenge, byte[                 throw new Fido2VerificationException("Challenge not equal to original challenge");              var fullyQualifiedOrigin = FullyQualifiedOrigin(Origin);-            var fullyQualifiedExpectedOrigin = FullyQualifiedOrigin(expectedOrigin);+            var fullyQualifiedExpectedOrigins = expectedOrigins.Select(FullyQualifiedOrigin);              // 5. Verify that the value of C.origin matches the Relying Party's origin.-            if (!string.Equals(fullyQualifiedOrigin, fullyQualifiedExpectedOrigin, StringComparison.OrdinalIgnoreCase))-                throw new Fido2VerificationException($"Fully qualified origin {fullyQualifiedOrigin} of {Origin} not equal to fully qualified original origin {fullyQualifiedExpectedOrigin} of {expectedOrigin}");+            if (!fullyQualifiedExpectedOrigins.Any(o => string.Equals(fullyQualifiedOrigin, o, StringComparison.OrdinalIgnoreCase)))

While not a dealbreaker, I'm wondering if a HashSet would be better than a List? My gut feeling is that it would be able to do a lookup without iterating (like linq Any does).

It is mostly relevant if the list of origins grow due to large number of unique origins.

Hinton

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

issue closedpasswordless-lib/fido2-net-lib

Checking Origin

I was exploring the code, I have a question relative to the Origin, when an application sends the Authenticator Assertion Response, the origin of this response needs to be checked with the origin in the Authenticator Assertion request, correct?

Exemple:

  • In the case of Web, a user requests to authenticate he has Origin “domain.com”, and then he sends a challenge signed with Origin “domain.com”, the origin of the request and the origin sent with the challenge signed must match.
  • In the case of Android, a user requests to authenticate he has Origin “android:apk-key-hash:LBpmHljqwJJLdXVNpjfdA”, and then he sends a challenge signed with Origin “android:apk-key-hash:LBpmHljqwJJLdXVNpjfdA”, the origin of the request and the origin sent with the challenge signed must match.

So if the origin of the request must be the same as the origin sent with the challenge signed, it wouldn’t be better if instead of putting Origin in the Fido2Configuration, put in the function MakeAssertionAsync? This way Fido2Configuration doesn’t have to change every time a different origin comes, for example, the android sends a different origin from the web.

closed time in a month

DestruidorPT

issue commentpasswordless-lib/fido2-net-lib

Checking Origin

@Hinton I think that seems like a very reasonable approach. I especially endorse the backwards compatibility thought. I will close this ticket. See #237 for further discussions.

DestruidorPT

comment created time in a month

startedgchq/CyberChef

started time in a month

push eventabergs/piano

Anders Åberg

commit sha 2c0bc8b0430dc8704044eb7d878db42a3cee172f

-5 is probably enough

view details

push time in a month

push eventabergs/piano

Anders Åberg

commit sha fe34ed182c3ddfbe5e8a9c5ca01b8b14285274a1

Fixed loading issue

view details

push time in a month

push eventabergs/piano

Anders Åberg

commit sha 3d53b202a5a1a351fae11fb0df9d31d871eaf6dd

Fixed loading issue

view details

push time in a month

push eventabergs/piano

Anders Åberg

commit sha e70b5d9a9ef38de68c9e3d11e5c977d129c1032c

Added playbtn

view details

push time in a month

push eventpasswordless-lib/fido2-net-lib

Anders Åberg

commit sha 9e63b44645e94b0decd8a14fbf0ba129091df814

Updated links

view details

push time in a month

push eventpasswordless/docs

Anders Åberg

commit sha e5c478d49689d0bbee430b3a2201c415a38e2197

deploy

view details

push time in 2 months

push eventpasswordless/docs

Anders Åberg

commit sha ce73e71e92c68a504464ab620fef082db97de28b

deploy

view details

push time in 2 months

push eventpasswordless/docs

Anders Åberg

commit sha a18a771e104d758058e275cf695d507b0d0215a1

deploy

view details

push time in 2 months

push eventpasswordless/docs

Anders Åberg

commit sha c5e2965efa4387d5c653333d0fe1885f4bfe8981

deploy

view details

push time in 2 months

push eventpasswordless/docs

Anders Åberg

commit sha efccaf6f7a13132bf264c9902980cc1ff54d68e6

deploy

view details

push time in 2 months

push eventpasswordless/docs

Anders Åberg

commit sha a9c886086223fe7939f3224e22e93d3c176a5329

deploy

view details

push time in 2 months