[NBLUG/talk] How do you handle physical device passwords?

[Allan Cecil]

My brute force concern was one of "my laptop was stolen".  Now, I have an encrypted home partition but not an encrypted disk (on one of my laptops, anyway) and thus /etc/password and /etc/shadow are in theory accessible if the volume is mounted which would in theory allow an offline dictionary attack.  That's probably the lowest risk aspect, of course.

Even the low attack rate of SSH passwords is too high for me so I've disabled password-based login entirely.  Not as a matter of security by obscurity but more because I have multiple hosts on one IP address I also use a non-default SSH port which substantially reduces attacks.  That leaves non-SSH password pilfering concerns, and after the talk at Thotcon about using everything from lasers to unopened potato chip bags to capture keystrokes I admit my paranoia went up a few notches. :)

Thanks for the lively discussion so far, it's interesting to see the different perspectives.  See you all at the meeting,

A.C.
******
President, North Bay Linux Users' Group

On 05/08/2017 06:26 PM, Rick Moen wrote:
> Quoting Chris Wagner (chris at cwcomputing.net):
> 
>> As Robert points out, you'd need the hash or really high bandwidth (and a server that wouldn't lockout the account).
> 
> Also, setup time of an ssh login session is significant.
> 
> Many years ago (90s), when my Linux machine lived directly on a T-1
> line, I did some shirtsleeve calculations of how long brute-forcing
> meaningfully random 8-character ssh passwords for a guessed login (like
> 'rick' on linuxmafia.com) would take to have a 50% chance of success.
> It was so extremely long to take that strategy out of even faint
> practicality except against 'joe accounts', which is why you really see
> only doorknob-twisting 'attacks' [sic] in your logfiles consisting
> solely of username/password combos that might be frequently used by
> extremely careless people.
> 
> A high-bandwidth brute-force attack against an sshd would also draw
> attention to itself if you started wondering why a 10GB
> /var/log/auth.log file had caused /var to hit 100% full.
> 
> 
> _______________________________________________
> talk mailing list
> talk at nblug.org
> http://nblug.org/cgi-bin/mailman/listinfo/talk
>