I received an email from snipped-for-privacy@eircom.net this morning using the subject of, Dear webmail Users, with the following contents:
"Dear webmail Users,
We are currently carrying out maintainance on our webmail email database,as soon as you receive this message you must reply to this email immediately, and enter your Username here (**********) And Password here (**********) if you are the rightful owner of this account.
This process we help us to fight against spam mails. Failure to summit your password, will render your email address in-active from our database as you shall be deleted from our database.
Thank you for using webmail! The webmail support team."
. . . . .
I *appears* that someone is wishing to fake some mail from someone else! . . . A phishing expedition to get passwords.
No problem, just give them a username and a password; any username and password that happens to pop into your head at the moment! Let them waste their time trying to do something with it.
Worse yet, it gives the spammers a link between a valid e-mail address and an IP address, which gives them an approximate geographic location. It also allows them to correlate that e-mail address to IP logs of other web services and, potentially, link tour e-mail adrress to accounts on those services.
Only if they have encoded something unique in each message that links it back to who they sent it to. Certainly, some phishers do exactly that. But, if you go to their hacked web site and enter a username and password, it normally will NOT have your email address available unless you give them that. (There are exceptions, such as if they can scrounge around in your cookies. I don't allow any sites to see cookies left by other sites for this reason.)
Yeah, my server got hacked a few weeks ago and they put up a fake web page from a Madrid (yes, Spain) bank. They'd been working very covertly for a week setting it up after initially penetrating the system. Then, I get an email from RSA security asking me to take down the page. A couple hours later, i get a phone call from my ISP, and can tell them I've already removed the offending page, and am trying to secure the system better.
(System is Linux, running SMTP server and Apache. I had added the denyhosts program, and thought that was enough. (It scans for multiple login failures from the same IP (even if different user names) and puts those IPs into the hosts.deny file, so, to the offending user, it appears that you just pulled your network plug - no pings, no response at all.) Well, if you have a stable of several HUNDRED compromised hosts, you can still focus an attack on a system, by only making a couple attempts from each IP until the system log file rolls over. I hadn't thought of that gambit, or that capability. it took them several months to compromise my system. I've severely cut down the number of login attempts permitted, such that I sometimes even lock myself out! I also made the password even harder to guess, essentially gibberish! And, also removed the root account and made it something else. What a pain! They do seem to have given up for the moment.
I'm looking at authentication schemes. Something where, AFTER you give a valid username and password, it then sends you some kind of challenge, and you have to do something non-obvious and send back a response based on the challenge, or you get kicked off.
And passwords can be generated using such phrases or sentences using the initial letters, replacing some words with symbols which have a link in *your* mind, whether they fit someone else's is a different matter. I once used '%' as a symbol for "bicycle". (Think of one rearling up on the rear wheel.)
Of course, in many systems, longer passwords can't be used. In most early unix systems, only the first eight characters actually matter, everything past that is ignored. The password is hashed (not really encrypted) turning it into a 14-character stored field which can't be reversed back to the password. Instead, when you log in, the system uses the last two characters (the salt) to figure out which of 4096 versions of the hashing to use, and applies that to what you type in, and compares that to the stored hashed value.
Later versions use other hashing techniques which can accept much longer significant parts of the password, and in that case the phrase or sentence is the way to go -- though it helps if you work some non-standard punctuation characters into it even so.
In OpenBSD, the limit is significantly larger:
====================================================================== The new password should be at least six characters long and not purely alphabetic. Its total length must be less than _PASSWORD_LEN (currently 128 characters). A mixture of both lower and uppercase letters, numbers, and meta-characters is encouraged. ======================================================================
Note the suggestion that you mix in upper, lower, numeric, and punctuation.
You can be VERY sure that Linux uses ALL the characters. With ssh logins, there are encryption keys that are 1024 characters long, thank God they don't make you type these in. Of course, by making them so long they HAVE to be stored on some computer, that compromises their security.
That depends on which encryption (actually hashing) technique it uses. The original one uses only the first eight characters, and stores the hash as a 13-character long string. (Look at /etc/passwd, /etc/shadow, or wherever your version of linux stores the hashed password. Look at the second ':'-delimited field and count the characters).
The equivalent in OpenBSD is 60 characters long, using the blowfish hashing algorithm.
There are several other hashing algorithms used by various flavors of unix, but I think that all of them will accept and use the old hash algorithm if it finds a matching string in the master password file.
Those are keys -- not passwords -- though if you set up sshd to accept such connections in lieu of the password, it can serve in place of a password. But mostly, that ssh encryption assures that no password goes between systems in the clear, so you can't snoop on it if you have access to the local net.
Two strings -- which have to interact to assure both ends that the system connecting is really the one which you want to have connecting, and that the one which you are trying to connect to is really the one which you think you are connecting to.
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.