On 02/05/2015 10:34 AM, Always Learning wrote:> On Thu, 2015-02-05 at 09:51 -0500, Lamar Owen wrote: > >> Those crackers who build these botnets are the ones who rent out >> botnet time to people who just was to get the work done. There is a >> large market in botnet time. > Surely its time for the Feds to arrest and change them ?The Feds in which country?> Gee thanks. I'll use it for root on every server ;-)Do note that now that it has been posted to a public list, while it was safe while unpublished, it would not be safe in the future. I have in my possession a file of passwords from a compromised server here, from several years ago. This was part of one of the slow-bruteforcer networks out there, and is one reason we now whitelist only needed outbound connections on port 22 and block all others on our two internet connections. Incidentally, this particular slow bruteforcer didn't need root to operate. The password list has about 65,000 passwords in it, some of which would have been considered strong passwords. Well, until they made the list. Your password is just about guaranteed to be on future lists..... However, another password with similar characteristics would be fine. You just never want to use it on more than one server to be safe.....
On Thu, 2015-02-05 at 13:59 -0500, Lamar Owen wrote:> On 02/05/2015 10:34 AM, Always Learning wrote: > > Surely its time for the Feds to arrest and change them ?> The Feds in which country?The USA for a start. The USA's law enforcement is never slow at working with foreign countries law enforcement to secure the arrest of offenders upsetting the USA - sometimes having them extradited to the US of A for trial. More effort must be made tracing the hackers. Hacking is routinely accepted too often. If a burglar attempts to break into a bank, does law enforcement forget about it ?> > Gee thanks. I'll use it for root on every server ;-) > > Do note that now that it has been posted to a public list, while it was > safe while unpublished, it would not be safe in the future.Have absolutely no intention of using it or anything resembling it. The security risk is too great !> ..... is one reason we now whitelist only needed outbound connections > on port 22 and block all others on our two internet connections.Port 22 is always blocked, port 21 too, on all machines. Too risky. Having port 22 open will give me sleepless nights.> Your password is just about guaranteed to be on future lists.....Then let them waste their time and energy attempting to crack a non-existent password.> You just never want to use it on more than one server to be safe.....Agreed. Never ever repeat the same passwords on different machines. -- Regards, Paul. England, EU. Je suis Charlie.
On 2/5/2015 10:59 AM, Lamar Owen wrote:> However, another password with similar characteristics would be fine. > You just never want to use it on more than one server to be safe.....there's a very useful tool built into centos's 'expect' package... $ mkpasswd -l 15 -d 3 -C 5 5ufkpX at SDxa2DF3 $ mkpasswd -l 24 -d 3 -C 5 xRyijvCo4fhph!QcY46xbprK $ rpm -qf `which mkpasswd` expect-5.44.1.15-5.el6_4.x86_64 but, Dog save someone from having to type said passwords even once and get it correct. -- john r pierce 37N 122W somewhere on the middle of the left coast
Jonathan Billings billings at negate.org Tue Feb 3 20:35:44 UTC 2015> Honestly, of all the faults and foibles in the Red Hat/CentOS installer, > I'm > amazed that someone is complaining about that.Someone is trying to keep the scope of such faults and foibles on topic, otherwise they'd easily be tempted to get carried away. "Oh No! They released a> product that's *incrementally* more secure than before! Heavens > Above! (faints)"I agree it's incremental, in the realm of turning hours into days, or days into weeks. I think we're well past 8 character passwords taking centuries to crack by brute force. Therefore I think it's a distraction, pointlessly incremental for staving off remote login attacks. The common attack vectors on users gets them to reveal their password, no matter its length. Or tricks them into agreeing to escalating process privilege even without a password. If you want something meaningful, disabling sshd by default has a more meaningful effect, and it's more typical (at least in terms of deployment volume) so everyone should be familiar with the idea. This is one of those decisions many software products have to make:> Weighing the general security gained by requiring somewhat more secure > passwords against the inconvenience of having to remember a somewhat > more secure password. Since it's possible to get around the > requirement in multiple ways, it makes sense to lean toward the more > secure option. Make it inconvenient to be less secure.I can set "moon" as the password on OS X, as an admin. Do you think a company, and its users, with such a big target on their backs, haven't considered the benefit of requiring somewhat more secure passwords? So far they've spent quite a lot of development effort (their own and 3rd party developers) on sandboxing functionality and constant policy adjustments over the past few years. If it were worth it, it'd be a lot easier to just say, shift the burden to the user, and make them pick a 10 character password. Chris Murphy