> > There are multiple password guessing tools commonly available on > > the Internet. I eval'ed one of the tools and it took five seconds > > to guess a password that was five characters in length. It took an > > hour to guess a password that was eight characters, and around > > twenty-four hours to guess a password that was eight characters made > > up of uppercase, lowercase and non-alpha characters (eg, complex). > > Regardless, the guessing process is simply how much time does one > > want to devote to doing it (eg, what's the return value for spending > > the time exploiting a system). > > Sorry, not in my tests. I used John the Ripper (http://openwall.com/john/ > ), which is a tool for cracking passwords from password files using > dictionaries and brute force. > > The password files had passwords in varrying quality, and cracking time > was indeed affected. all-numbers password were guessed almost > immidietly. [*] Well-composed passwords of 8 characters were not > cracked by brute-force in resonable time.
I never use products that rely on pre-staged password files; they are no better then the person that assembled the password file and run about the same level of mentality as the script kitties. Try one of the tools that simply starts with "a", then "b", etc, then "aa", "ab", etc. There is no preconceived notion as to what the password should be, and will guess _any_ password given enough time. "That" was the key point, and one of only a few true mechanism to defeat that process is a short duration lockout. (Exception is the use of keys as noted in previous postings.) > [*] passwords that should be dialed from phones are relatively short and > all-numbers. Are they never exposed to the internet? And that statement is "exactly" why the fed and state banking examiners are raising all kinds of red flags relative to Internet Banking Systems. Complex passwords aren't a choice for telephone banking, but certainly are for PC Internet banking. One of the "controls" used to mitigate that risk is a backend system (sort of a batch process) that attempts to analyze customer banking patterns and alerts on unusal events. Lots of banks and international credit card companies use the process, and even the small rural banks use a manual process to do the same. (The majority of banks also use the account lockout mechanism even for the simplest telephone banking system.) If you apply the above discussions to asterisk, how hard do you really think it might be to write a small script to guess the password used to register a sip phone (as an example)? Given what you've already seen on this list, it would not take long at all to determine the IP address of anyone's exposed asterisk box that posts to the list, and beat on their asterisk box to guess the phone's assigned secret. That is exactly one of the common trade journal complaints relative to VoIP security. (Mark has added some code that essentially is an account lockout mechanism to help defeat that process. Not sure if that is cvs head only or if it was moved into stable as well.) > > It doesn't make much difference whether one exposes telnet or ssh. > > Both can be exploited. But, the more complex you make the password, > > the more time-consuming and difficult it is to guess it. > > > > So, if you must expose either telnet or ssh, make your passwords very > > long and complex. If your O/S has the capability to lockout the account > > after 'xx' failed passwords, then do that. > > And allow crackers to lock you out. A silly and effective DoS attack. Call it what you want, but a five minute lockout in my book (and a very large number of very professional security folks) is not a DOS at all. Of coarse, if you're one of the few that want to expose common userid's like root, then you're just creating the DOS problem for yourself. Moving ssh or telnet to another tcp/udp port is nothing more then security by obsurity. For anyone in the security business, that step only adds about ten minutes to the process of discovering which services are actually exposed (on any of 65,000 ports) and then beating on those services to exploit them. Very easy task (and since those tasks are automated, who cares about the extra ten minutes). The bottom line for those asterisk readers that have actually read this far is to use complex & lenthy passwords where possible, and some sort of alerting mechansim when xx number of passwords are guessed incorrectly (such as an account lockout mechanism with alerts as just one of many available choices). _______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
