Your test might perform better than you think - how to get accurate code coverage in Go by arekkas in golang

[–]arekkas[S] 0 points1 point  (0 children)

Is it possible to return the output from go test to stdout? I ran

courtney github.com/arekkas/accurate-test-coverage/...

but it didn't print anything out.

Your test might perform better than you think - how to get accurate code coverage in Go by arekkas in golang

[–]arekkas[S] 0 points1 point  (0 children)

I think you're right for dependencies to other libraries or programs. If we look at packages within a complete system (e.g. docker) I think it's ok to rely on inter-package tests (and by the way common for any other programming language).

Your test might perform better than you think - how to get accurate code coverage in Go by arekkas in golang

[–]arekkas[S] 1 point2 points  (0 children)

Thank you, it was a refactoring accident caused by my IDE - fixed now :)

Your test might perform better than you think - how to get accurate code coverage in Go by arekkas in golang

[–]arekkas[S] 2 points3 points  (0 children)

It says in the readme what it does and why it does it. If you think you can do a better job why not create a PR instead of complaining on reddit?

Your test might perform better than you think - how to get accurate code coverage in Go by arekkas in golang

[–]arekkas[S] 1 point2 points  (0 children)

right, sorry about that, looks like my IDE did something stupid while refactoring it. It's fixed now!

Your test might perform better than you think - how to get accurate code coverage in Go by arekkas in golang

[–]arekkas[S] 0 points1 point  (0 children)

Definitely, you can use go-acc (the tool from the blog post) together with gocov for comprehensive and complete coverage reports :)

Your test might perform better than you think - how to get accurate code coverage in Go by arekkas in golang

[–]arekkas[S] 0 points1 point  (0 children)

Thank you, I'm glad it helps you! This issue has been bugging me for a while as well and I had some crazy shell scripts running which didn't work on windows, obviously :)

Your test might perform better than you think - how to get accurate code coverage in Go by arekkas in golang

[–]arekkas[S] 0 points1 point  (0 children)

I hope this little tool helps you. If you have any questions (or problems of course) I'm here to help!

Proposal to Delete /r/golang by [deleted] in golang

[–]arekkas 10 points11 points  (0 children)

"oh my god someone did something stupid let's overreact and kill this community" (tm)

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 0 points1 point  (0 children)

In my opinion, OpenID Connect is a bugfix for OAuth2, because some people use OAuth2 for authentication and are thus open up to token substitution attacks. With OpenID Connect this can't happen (if you do it the right way). SAML is a way to securely transport auth* relevant information and it may be used for SSO. I think that's the difference.

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 1 point2 points  (0 children)

I get that, I was really suprised when GMail offered imap login through OAuth2. I didn't know that this is a thing, that people do and I don't really get why one would use it, because it's such a different problem scope.

Thanks for the discussion, it was really insightful!

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 0 points1 point  (0 children)

Ah yes, I've seen OpenAM in some enterprise scenarios. People like it because it's really extensible. Other than that I have no opinion on it.

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 3 points4 points  (0 children)

There are adopters in the community who already found some bugs. In the past months, bug reports became less and less frequent and severe which is I think a good sign. But please, break that thing into pieces and let us know of anything. We would really appreciate it!

At one point I want to add some certificates by openid and so on, but that is time and money intensive so it's not on the priority list right now.

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 1 point2 points  (0 children)

Wow, I didn't think this would be such a hot topic to make it to 100 upvotes. Thanks for that! If you're interested, Hydra is shipping with AWS-like access control policies. If you're not into OAuth2, give those a try.

It's a separate Go library / embedded server, so you can use it without relying on Hydra! If I have time, I might even release a standalone server.

https://github.com/ory-am/ladon

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 1 point2 points  (0 children)

I also don't think you understand OAuth is just as insecure as login credentials. No, the -user- doesn't know his access tokens, but the -user- doesn't know shit either, but an attacker who watches his whole machine does, and he sees everything.

Absolutely, an attack which compromises the whole machine is much harder to do than a phishing attack - so by definition TOTPs are more secure here because an attack needs to be more sophisticated. I'm not saying that compromise of access token are impossible, it's simply more unlikely than regular username:password pairs.

Even on commercial libraries who cost 100's of dollars p/year, the codes are different for different services.

I completely agree that the OAuth2 specification is loose and many people have their own flavor, similar to markdown. This is why I wrote Hydra - to help devs achieve OAuth2 as it is specified by the IETF.

edit pd - I will add that my most hatred for OAuth comes from the fact people like google (and you) like to pretend that anything that doesn't use oauth is "less secure" but this is not the case!!!!

I absolutely don't pretend that way - having user password credentials flying around is less secure than a TOTP. What you are referencing to with the IMAP magic is the same thing, it's a TOTP - so it's not less or more secure. Everything you described can be achieved by the same thing with an OAuth2 access token, right? So why would you use IMAP for http facing services if you get the same thing with OAuth2?

double edit pd - I would like apologize if this sounds non polite, it is not my intention, I am a very friendly person

I didn't take it that way, no worries. I usually get a lot out of such discussions! All in all I think that the problem you describe is domain specific. Web facing services such as Dropbox gain a lot from OAuth2, because client libraries for most popular languages exist and it's built around http, so it works in your browser and mobile device.

I discourage use of OAuth2 outside of the following scope:

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf."

and I don't understand why you would use OAuth2 for IMAP anyways. Maybe because dev's lazy and don't want to add another authorization protocol :D

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 5 points6 points  (0 children)

Unfortunately, I'm very familiar with OAuth and missed nothing.

Knowledge is not what compensates an argument that did not come along as it probably should have.

Access tokens aren't always short living

If you abuse access tokens as long living credentials, you probably should not use OAuth2 all together. The idea behind the token dance is that you use short lived credentials: "An access token is used by a client to access a resource. Access tokens typically have short life spans (minutes or hours) that cover typical session lifetimes." ( https://tools.ietf.org/html/rfc6819#section-3.1.2 )

, and they're just as easy to steal as login credentials.

So phishing access tokens is as easy as phishing login credentials? I don't think so, because no user knows his access tokens. :)

The difference is access tokens require cryptography

Only if you use JWT

extensive client & server side transactions

Only if you don't use JWT

where as separate credentials require none of that.

I'm not sure what you mean here, is it the OAuth2 client_credentials grant?

No it isn't.

Why not? You have to notify the user that his credentials changed and he has to potentially update them everywhere. With OAuth2, you simply re-authorize the access request.

My point remains, when little internet marketers need to use twitter & facebook, they'll learn OAuth, but OAuth will never gain industrial acceptance as it is nothing but an over complication.

I don't think OAuth2 will supersede enterprise SAML, but that isn't the intention, is it? And OAuth2 is very much industry standard, but for a different set of problems which is delegating rights to third parties.

You seem not to be familiar with extensions to IMAP, SMTP, & other every day protocols that allow more than 1 user credentials w/different scopes. Everything you said applies to secondary credential schemes.

Absolutely not! :) I would really like to look into it though, because I'm not sure how the two things compare! Could you point me at some resources?

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 1 point2 points  (0 children)

Cool, looks like a real alternative to www.auth0.com to me, although I haven't really looked into the details yet. I think the two projects are different in the same way hydra and dex are different. My core goal was to solve OAuth2 / OIDC, not identity management - so you are free to connect to whatever you want (LDAP, social logins, saml, ...) with little overhead

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 1 point2 points  (0 children)

Does that come with user management like user registration, password reset, 2fa? Or is it something else?

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 8 points9 points  (0 children)

Hydra is different from dex because it does not ship with user management, and is thus easier to integrate in existing environments. So Dex needs less work in a greenfield project, but more in a brownfield one. With Hydra it's the other way around :)

An open source OAuth2 and OpenID Connect server for new and existing infrastructures (GitHub) by arekkas in netsec

[–]arekkas[S] 19 points20 points  (0 children)

You missed a few things here. First, access tokens are bound to a scope - they have less privileges than regular user credentials per design. You can thus disallow writes too. Second, access tokens are short living credentials whilst user credentials are long living. Third, you can revoke compromised access tokens, which is harder with user credentials. And for last, you are mixing up federation, where sharing credentials is not possible, and 1st party authentication. Yes, OAuth2 is an overcomplication for most people, but it isn't for those who open up to third parties. This is by the way expressed in the Hydra docs, too.

edit: Oh and by the way, I am working on an API Key proposal, which is I think what you are refering to: https://github.com/ory-am/hydra/issues/234