Re: [BLUG] How many of you run home servers?

Hey! I said "short password" not a bad password. ;)

For me, "short" is 12 to 24 characters, no embedded words, no 1337 substitutions, upper and lower case, includes at least one number and punctuation. Yeah, it can be brute-forced, but it isn't low-hanging fruit. More than that a casual aquantance can't learn I like "yams" and know the key to my password. ("Hey, he turned 34, let's try 'yams77'... Bingo!")

Now "long" is 240 characters or more. I have had one of those before, but they just feel so slow to type I am loathe to go that big.

I usually aim for 70 to 90 characters. Comfortably fast to type, and still long enough to thwart all but the most determined.

Yeah, there's the whole sneak-in-and-copy-key thing. It is suitably low risk for the reasons Mark mentioned.

If you really want to protect a PC you need a boot-time password and to power it off whenever it will leave your sight. This is what I do with my laptop when at conventions.

Ultimately we're talking risk mitigation. There is no way to remove all risks and have a usable system.

Cheers,
Steven Black

On Jul 21, 2011 12:53 PM, "Thomas C. Knoeller" <tck@pretend.net> wrote:
> On Thu, Jul 21, 2011 at 12:28 AM, Steven Black <yam655@gmail.com> wrote:
>> [...] Using
>> a short passphrase and a key agent that forgets the passphrase
>> immediately with public key authentication is still better than being
>> botnet attacked for months on end.
>
> Heh. This touches on the other part of my paranoia with PKI; the
> short passphrase. Imagine that your passphrase encrypted key gets
> loose in the wild.[1] At that point, you can brute force the file
> without anyone knowing you are doing it. No matter how many thousands
> of bits the key itself is, if the passphrase is simple or small
> enough, there is a possibility of it being decrypted. Whereas, if you
> are doing the password checking during the login process, if a failure
> happens, it is logged and you have a chance of seeing the attack
> before to many guesses of the password can be made.
>
> I agree that the script kiddie login attempts are annoying. But they
> are not likely to succeed if you use password best practices. And if
> you are really worried about them, and cannot lock down the ssh port
> to known remote hosts, using a port knocker of some sort is an easy
> way to only open the port when needed.
>
> As someone else said, 2 factor auth (something you have plus something
> you know) is still the best thing to do, but if you don't do that, and
> need to open ssh to the public, local password is my preference over
> keys.
>
> -Tom
>
>
> [1] Using the stroll to the kitchen example again, if you forget to
> lock your screen, and someone gets to the machine before the 2 minute
> auto kick in of auto screen locker, they can easily open a terminal
> and run a curl command to upload the public key[2] from your machine.
>
> [2] If you are using security by obscurity, while in the daemon rc
> file to change the port number, you should also change the default
> location of the public key file.
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug