Strong_password Rubygem hijacked • Hacker News Board

Re: Strong_password Rubygem hijacked

#131

Post by pharrington » Tue, Jul 09, 2019, 6:36 PM UTC

audience_mem wrote: post #128

pharrington wrote: post #32

Earlier quoted context omitted.

> This is a gem that checks the strength of a user-submitted password Does it, though? https://github.com/bdmac/strong_password/blob/master/lib/str...

Could you clarify? Is the algorithm deficient? To me that looks like code that indeed checks the strength, so I must be missing something.

It checks the length of a password, along with an arbitrary scalar for repeated characters. It does not do any entropy calculations.

The writer of that code at least needs to read https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpubli... one more time.

Re: Strong_password Rubygem hijacked

#132

Post by Anagmate » Wed, Jul 10, 2019, 11:08 AM UTC

redsymbol wrote: post #64

kibwen wrote: post #24

Earlier quoted context omitted.

To be honest, even the coarsest-possible permissions of "can do I/O" vs. "can't do I/O" would be exceedingly effective at stymieing these sorts of attacks; all malicious software of this sort needs to do I/O at some point, and relatively few libraries actually have a good excuse to do I/O (though logging might be thorny). That said it seems easier said than done to impose those sorts of restrictions on a per-dependen…

> few libraries actually have a good excuse to do I/O (though logging might be thorny). Yeah, logging would be tricky... Maybe a "logging" capability could be created. Separated from other I/O. Such a capability would be weird, and nonstandard, and messy, cutting across several several abstraction layers. But if pulled off, it might be worth the effort.

Haskell indirectly solves this by separating `trace` (a form of logging) from IO (trace is a procedure that logs function call while all other IO must be contained in an IO monad).

Re: Strong_password Rubygem hijacked

#133

Post by confiq » Thu, Jul 11, 2019, 8:07 AM UTC

bdmac97 wrote: post #114

Hi all. I'm the (actual) owner of that gem. As already hypothesized in the comments I'm pretty sure this was a simple account hijack. The kickball user likely cracked an old password of mine from before I was using 1password that was leaked from who knows which of the various breaches that have occurred over the years. I released that gem years ago and barely remembered even having a rubygems account since I'm not do…

one more reason why to use a password manager and have a unique password.

Thanks for sharing the info!