Update Hashing Algorithm

[davidcorrigan714]

All Submissions:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• My code follows the code style of this project.
• I ran lint checks locally prior to submission.
• Have you checked to ensure there aren't other open PRs for the same update/change?

What about the current behavior has changed?

This provider stores secret values in the state file by hashing them with bcrypt. bcrypt only uses the first 72 characters for the hash which results in issues with Artifactory JWTs because the first 72 characters of those tokens contain data about the algorithms and subjects which don't change when they're regenerated. The recommendation from OWASP is to use Argon2 as the current standard for password hashing. I've adopted that for our fork of the provider in this PR. I have no inclination of what Microsoft might ultimately do to resolve the issue upstream but worst case our secrets will get re-pushed to Azure DevOps when upstream resolves this issue and we either merge it in or use the upstream provider again.

Note that the real change is just the change to azuredevops/internal/utils/secretmemo/secretmemo.go and the replacement library really is just about a drop in replacement for bcrypt. Then I tweaked the tests, and updated the modules & vendoring.

Issue Number: microsoft#692

Does this introduce a change to go.mod, go.sum or vendor/?

• Yes
• No

Adding the Argo2 library to the bundle

Does this introduce a breaking change?

• Yes
• No

Not really "breaking" but maybe worth a release note should this be upstreamed since passwords might be updated on target systems when this goes live.

[irwand]

Hmm.. I didn't notice it before.. is it standard practice that we'd commit dependencies' code into git?

[irwand]

Can you comment on dependencies getting committed into the repo?

[davidcorrigan714]

From what I gather there's some history to why Golang has used vendoring, in this case that's how Microsoft has their package structured so that's that and I don't have much say or opinion either way on it.