On 01/10/2015 12:01 AM, Jerry Stuckle wrote: > On 1/9/2015 10:24 PM, scott wrote: >> On 01/09/2015 09:19 PM, Jerry Stuckle wrote: >>> On 1/9/2015 8:49 PM, Joel Rees wrote: >>>> On Fri, Jan 9, 2015 at 6:25 PM, Martin Steigerwald <mar...@lichtvoll.de> >>>> wrote: >>>>> Am Freitag, 9. Januar 2015, 00:24:06 schrieb Brian: >>>>>> On Thu 08 Jan 2015 at 22:36:46 +0100, Martin Steigerwald wrote: >>>>>>> Am Donnerstag, 8. Januar 2015, 14:20:27 schrieb Jerry Stuckle: >>>>>>>> Just ensure you're using good security practices - don't allow root >>>>>>>> login, use long, random passwords, etc. I also use a random character >>>>>>>> strings for the login ids, as well as passwords - just one more thing >>>>>>>> for the hackers to have to figure out how to get around. >>>>>>> >>>>>>> Only allow SSH key based logins. Of course, only after you copied a >>>>>>> public >>>>>>> key onto the machine with ssh-copy-id. >>>>>>> >>>>>>> And have SSH keys with *strong* passphrases, to protect against someone >>>>>>> stealing your key. Use ssh-agent wisely only on trusted machines. >>>>>> >>>>>> SSH password logins are just as safe. 20 characters gives a strong >>>>>> password for use on trusted machines. There is no need to worry about >>>>>> it being stolen because it is in your memory, >>>>> >>>>> I think SSH keys are safer, cause there is no password at all that can be >>>>> brute forced. >>>> >>>> What do you mean by that? >>>> >>>>> Okay, one can try to guess the key, but try that with a 4096 bit >>>>> key. >>>> >>>> Hmm. >>>> >>>> 10 characters, 6 to 7 bits per character, that's 60 bits. >>>> >>>> If the bits are truly random, straight brute-force will take, on >>>> average, half of 2^60 attempts. >>>> >>>> We can hold the integer 2^59 in a C variable on most recent desktops, >>>> but if we have bc (dc if you like post-fix), we can do this on even 32 >>>> bit CPUs: >>>> >>>> 576460752303423488 (base ten) >>>> >>>> At one milion attempts per second, that's 5764607523034 seconds, or >>>> 182678 CPU-years. >>>> >>>> There's no way that's going to happen on-line, if the password is >>>> truly random, and not randomly a password that's a quick permutation >>>> of common memes or of entries in rainbow tables. >>>> >>> >>> Actually, 62 possible characters (upper case, lower case and digits), 10 >>> positions is 62^10 or 839,299,365,868,340,224 possible combinations. >>> >>> Adding in special characters obviously would increase that. >>> >>> But there is no way you'll hit a server 1,000,000 times a second trying >>> to brute force a password. >>> >>> >>>> I currently use sixteen or more letters in my passwords, don't use >>>> simple permutations or common phrases (as for the first leter trick), >>>> use disconnected words from multiple languages. Or use 16 character >>>> true random passwords for the important stuff. >>>> >>> >>> All good suggestions. >>> >>>> SSH keys are useful, but you have to keep them somewhere. The real >>>> danger to good passwords is the off-line attempts, and the passphrase >>>> you use for your private keystore is potentially subject to off-line >>>> if your password is. >>>> >>> >>> Yes, keys may actually be less secure than passwords. >>> >>> Jerry >>> >>> >> If you have a dedicated hacker, or hackers, time is on their side. I >> would much rather use a key with a passphrase. >> >> > > That's fine, if you don't care about security. Lose your laptop and > your pass phrase can be broken at a rate of 1 billion attempts per > second, since it is local to your machine. > > There is no way you're going to get even 100 attempts per second into an > SSH server. And since the hacker doesn't have direct access to the > encrypted password on the server, he can't break it on a local machine. > Using the same password/pass phrase for both systems, it would take > 10,000,000 times longer to hack the SSH password than your local pass > phrase. > > And then there's the problem you can only access the server from a > system with the key file. And the more computers the key file resides > on, the less secure it is. > > Since a password is not stored on any machine (except the server), there > is nothing to break. > > Jerry > > I replied to your post to me specifically, so I 'll do it here, also. The fact is that if you have physical access to any machine, unfettered, it's game over. Scotty
-- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54b0b779.2010...@gmx.com
