Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keeping secrets out of logs (2024)

allan.reyes.sh

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Keeping secrets out of logs (2024)

#52

Post by tonymet »

petesergeant wrote: post #41
tonymet wrote: post #20

Earlier quoted context omitted.

for one it's extremely costly, in vcpu , storage , transfer rates. and if you're paying a third-party logger , multiply each by 10x

Axiom wants $60/m if you send them a terabyte of logs, which is basically nothing compared to the cost of developers trying to debug issues without detailed logs.

I think you're being naive on the costs but that's just me. That's the intro price, plus you have transfer fees , vcpu .

I've never used axiom, but all the logging platforms I've used like splunk, datadog, loggly are a major op-ex line item.

And telling your developers their time is priceless means they will produce the lowest quality product.

Re: Keeping secrets out of logs (2024)

#53

Post by otterley »

CraigJPerry wrote: post #4

With java theres a GuardedString implementation https://docs.oracle.com/en/middleware/idm/identity-governanc...

It doesn't look like it's a part of the standard API though. That looks like it's some sort of framework API for Oracle Fusion. It's also not open source.

Re: Keeping secrets out of logs (2024)

#54

Post by tonymet »

petesergeant wrote: post #41
tonymet wrote: post #20

Earlier quoted context omitted.

for one it's extremely costly, in vcpu , storage , transfer rates. and if you're paying a third-party logger , multiply each by 10x

Axiom wants $60/m if you send them a terabyte of logs, which is basically nothing compared to the cost of developers trying to debug issues without detailed logs.

not to mention the performance impact of synchronous logging. Write a trivial benchmark and add logging and you will see cost per operation 1000x

Re: Keeping secrets out of logs (2024)

#55

Post by HelloNurse »

dataflow wrote: post #50
HelloNurse wrote: post #36

Earlier quoted context omitted.

Can you elaborate on the situations and reasons that would make this approach appropriate? At first sight it seems a complicated and inferior approximation of techniques from the article: not automatically single use, not statically checked, somewhat error prone for proper secret usage, not really preventing well-intentioned idiots from accidentally extracting, "laundering" and leaking the secret, removing secrets fr…

I mean, I very much disagree on this being "complicated and inferior". But none of these techniques are substitutes for each other. Like the article said, there are a lot of lead bullets, no silver ones. You absolutely should deploy whatever techniques you can. All I was saying was that I think this one, on its own, would handle a larger set of cases than some of the other (run-time) ones listed. But one big reason I…

  >  You thought you made the Secret "single-use", but what you really did was to just encourage someone to keep the unsealed String around and reuse that, because you gave them a Secret type and they needed a String type
In a reasonable development process, one that doesn't abet dangerous mistake-makers, forcing clients to invoke a special method of the Secret class (single use or not) to "unseal" it gives a valuable auditing tool for free: every dangerous situation can be found by a simple search for usages of this method, while a marked string value that contains a secret is undistinguishable from a normal string and can be misused.
Post reply on HN