Discussion on:
View:
Show:
Several researchers think so. They have some good arguments. See what they have to say.
I was always under the impression that if potential hackers didn't even know the format that user IDs took then that was yet another good barrier, before they even got to thinking about trying to hack the passwords. That is why all of the workstations on my little school network have the "Do not display last user name" policy enabled and I entreat staff not to logon in front of the students (shouldersurfing - I like that term ). Certainly increasing the complexity of the user ID seems a better way to go for increasing security rather than expecting Joe Public to make a more complex password. At least unti bio-scanning takes over everywhere.
The one thing I learned from this paper was that having a userID format for all employees is not a good thing.
I agree that the format of both should be hard to guess.
In the articl;e is the example of a bank account.
Strange thing here is in a smaller country the number of digits (of the ID) larger than in a larger country which makes the smaller country more safe. It's still just digits as well as the PIN (in both countries the same number [too few]) of digits.
For brute force techniques too little protection.
Password (later called PW) systems could make it more complex by allowing a greater variety in both the ID and the PW.
The dilemma remains that the systems that are hard to crack by definition become user unfriendly. The users need protection against themselves and be educated (or even forced) to make their credentials as hard as possible to become public.
In the articl;e is the example of a bank account.
Strange thing here is in a smaller country the number of digits (of the ID) larger than in a larger country which makes the smaller country more safe. It's still just digits as well as the PIN (in both countries the same number [too few]) of digits.
For brute force techniques too little protection.
Password (later called PW) systems could make it more complex by allowing a greater variety in both the ID and the PW.
The dilemma remains that the systems that are hard to crack by definition become user unfriendly. The users need protection against themselves and be educated (or even forced) to make their credentials as hard as possible to become public.
Many corporations use uniform usernames that are easy to figure out. Then it is just a matter of getting an employee list.
something you know and something you have.. it matters not your password policy when they need a crypto card or other form of authentication device..
How many web sites use that approach? Until some kind of standard is set up, you would need a different second factor for every web site.
Thanks.
Bulk-guessing wasn't on my radar either, but I can see it should be.
Terrifying consequences by the way; cybercrime is about making money - and if you get 10 bank accounts broken open as one job, that's money in the bank so to speak.
A sure-fire get-rich-quick scheme (even if it just looks that way to the fevered eyes of the easily tempted) is guaranteed to increase cybercrime worldwide, and it always spreads and diversifies, and then things get even worse.
Bulk-guessing wasn't on my radar either, but I can see it should be.
Terrifying consequences by the way; cybercrime is about making money - and if you get 10 bank accounts broken open as one job, that's money in the bank so to speak.
A sure-fire get-rich-quick scheme (even if it just looks that way to the fevered eyes of the easily tempted) is guaranteed to increase cybercrime worldwide, and it always spreads and diversifies, and then things get even worse.
It is some interesting stuff. Dr. Herley has another paper that I am working on and it's pretty cool as well.
Good article. I like the idea of increasing the length of userid and password to increase security. The argument against longer passwords being difficult to remember.
The other problem is some web sites limit the length and/or characters of userids and passwords. The second paper you reference also explains why literary and movie characters are generally blocked as userids.
The other problem is some web sites limit the length and/or characters of userids and passwords. The second paper you reference also explains why literary and movie characters are generally blocked as userids.
All I really know for sure is that we need to do something, otherwise there will be no one trusting web sites, specifically online financial institutions.
You have ever put anything out here that could be read and dismissed in a blink.
This is another that needs to be mulled.
I can tell you I'm about to make an immediate change on account of my initial understanding.
_______
Change effected and confirmed by the institution.
This is another that needs to be mulled.
I can tell you I'm about to make an immediate change on account of my initial understanding.
_______
Change effected and confirmed by the institution.
As long as all other things are secure. But I'm almost inclined to think that credential strength is almost being discussed in a vacuum in this case. I'd have to read more to find out, but I will explain my thinking using an example quoted in the article.
" ...locks an account for 24 hours after three attempts..."
But will the system do this? A lot of ATMs are notoriously insecure. So are a lot of website login procedures. They can be gamed in a number of ways, and code seems to be fixed infrequently or not at all.
Actually, I'd wager that some banks do have very good login back ends, probably a lot better than their ATMs have.
I agree entirely that this is a good approach to login credential creation. But it hardly matters in an environment where login can be bypassed entirely, or heaps of credentials can be slurped up right out of a server across a network.
But again, these concepts seem to be narrowly focused, and aren't considering factors beyond the credentials themselves, which is fine. Better credentials will help protect against the type of attacks mentioned.
" ...locks an account for 24 hours after three attempts..."
But will the system do this? A lot of ATMs are notoriously insecure. So are a lot of website login procedures. They can be gamed in a number of ways, and code seems to be fixed infrequently or not at all.
Actually, I'd wager that some banks do have very good login back ends, probably a lot better than their ATMs have.
I agree entirely that this is a good approach to login credential creation. But it hardly matters in an environment where login can be bypassed entirely, or heaps of credentials can be slurped up right out of a server across a network.
But again, these concepts seem to be narrowly focused, and aren't considering factors beyond the credentials themselves, which is fine. Better credentials will help protect against the type of attacks mentioned.
Someone is going to have to kill me now, for everyone's safety. What if I fell into the wrong hands?
Well, those would be some rather disappointed hands, actually.
Well, those would be some rather disappointed hands, actually.
I tried to find out about that, but as you suggest there is precious little information about what happens to credentials at the data center.
If you have "just" a few thousand login IDs, then bulk-guessing will not be guaranteed success, since a 6 character password has a uniqueness ranking in the millions (a million even with just digits).
Barring stupidity (123456, f.ex.)
Barring stupidity (123456, f.ex.)
That's why the researchers say using a simple password and a lock out policy is sufficient as well.
Forget the passwords - I'm not endorsing anything more complex. I am merely trying to point out that some criminals will just walk right around the entire authentication process, steal heaps of credentials, then use them until someone catches on. All this using well-known, un-patched vulnerabilities. And probably lesser known vulnerabilities as well.
The credentials concept put forth here is, disregarding all else, sensible to me. But good credentials are of no help in a bad system.
Diebold.
Diebold Diebold and some more Diebold. And TJMaxx.
The credentials concept put forth here is, disregarding all else, sensible to me. But good credentials are of no help in a bad system.
Diebold.
Diebold Diebold and some more Diebold. And TJMaxx.
For a while I've been wondering how long it would take for you guys to get around to analyzing not only the use (whether futility) of passwords, but also the function of user identification (AKA user name). 
Perhaps the original frame of reference was "account + userID" or "account + password", before it became "user-name + password". Note that in the first two, the userID and the password have the same role, and for "user name + password", the user-name is ordinarily employed, whether directly or indirectly, to identify an "account" record(s).
In the "account + userID" case, which persons can access the account data and which are authorized to effect and/or to record transactions for that account might well be known, but their userIDs are secret. Since access and activity to the account can be logged by userID, each user has an incentive to keep their ID secret.
In the "account + password" case, the account name or number is probably shared or even public information, but the password is secret. Accounts can have multiple passwords, with one unique password for each person qua "user" who is authorized to access the data of, and perhaps to effect and/or record transactions for, the account. Ordinarily, each time that a user accesses the account, a log is kept of their activity. Accordingly, each user has an incentive to keep their password secret, whether also to accept that it should be "strong".
Which is to say, account names or numbers, userIDs, and passwords predate their use in the context of the Internet. They were adopted for internal security, as part of a system of control to prevent and/or to detect malfeasance and embezzlement, among other possibilities, by employees and agents of businesses or of other organizations.
Succinctly, they have been, and still are, used in the mitigation of insider risk. Perhaps that context is the one in which they are the most effective. It is also the context in which the rules for creating, securing, and changing, passwords have been created. In particular, changing a password often is desirable because an "insider" who has acquired it and found a use for it is likely to use it repeatedly, whether often, unless and until they are caught (which could be over the course of a long period of time).
We know that adopting "user-name + password" to deter unauthorized access by "outside" intruders can be effective, but it also has weaknesses. The vulnerability of passwords to phishing depends upon the vulnerability of the user, and their vulnerability to illicit keystroke-logging depends upon the vulnerability of the system to malware installation. Of course, both phishing and keystroke-logging typically obtain user-names as well as passwords.
In both contexts in which passwords have been adopted, users often consider "strong" passwords inconvenient and/or simply infeasible. That lessens their incentive to keep them secure, and to create them when they are allowed to create their own password(s).
Mr. Herley is correct in asserting that a 6-digit PIN is adequate for a password, if and only if the system in which it is used does not permit enough unsuccessful attempts for a brute force attack to eventually succeed, whether by "locking out" access to the system when such an attack is detected. Geometrically increasing the amount of time before another attempt is permitted after each invalid password has been entered is a particularly elegant solution. Although, an actual customer who cannot recall their password correctly will probably not appreciate that approach.
Mr. Herley also presents a sound argument for a bank (or other organization) to keep the list of its actual user-names very secure. However, I do not agree that a user-name should be regarded as something which the user can publicize, disclose, or otherwise treat in an unsecure manner, because it should become another barrier to unauthorized access to the account. As already noted, the user-name either directly or indirectly identifies the "account" for which the password must be entered.
Although Mr. Herley mentions "over the shoulder" spying he does not discuss "ATM skimmers". The thieves install a counterfeit front to the actual front of an ATM, and it intercepts and reads the data from the user's ATM card, and records the PIN and any other data which they enter via the keypad. (I haven't heard of one which will steal deposits of cash and/or checks, though that might have been done.)
The web sites at which I've "registered" or "opened an account" either (1) require that a valid e-mail address, for an account to which the user has access, be employed as the user-ID, or (2) permit the user to compose and adopt whatever "user-name" that the user chooses. In the first case, an e-mail address is implicitly unique among all others. Many web sites send an e-mail message to the e-mail address specified by the user, who must respond to it in a designated way to "authenticate" their registration or creation of the account. In the second case, the user might be limited to letters and digits for the user-name, whether also for the password.
Regardless, simply keeping track of all "user-name + password" combinations that I've adopted has been a chore! (Currently, I am implementing LastPass to manage them.)
The bank(s) to which Mr. Herley refers in his article either (1) assign a unique user-name for each customer, (2) assign a unique number that corresponds to each specific bank account instead of a user-name, or (3) adopt a unique "universal identifier" such as the US Social Security Number for each person who is authorized to access the account.
Since the bank with which I do business does not assign a user-name for access to the account via the Internet, I have chosen to adopt one which consists of both upper-case and lower-case letters, digits and special characters. In other words, the user-name is a "strong password" and I treat it as such. The "password" itself is relatively strong, and I also use two-factor authentication. If the bank doesn't "recognize" the IP address that I am currently using (it changes every day), then they require me to answer a "security question". That challenge is made after I have entered the user-name, of course.
Unfortunately, none of this defeats the use of the ZeuS banking spyware "trojan", but I'm such a small fish in such a large pond that I cannot imagine that they would waste a money mule to steal my money. I'm much more concerned about "insider risk", though.
Perhaps the original frame of reference was "account + userID" or "account + password", before it became "user-name + password". Note that in the first two, the userID and the password have the same role, and for "user name + password", the user-name is ordinarily employed, whether directly or indirectly, to identify an "account" record(s).
In the "account + userID" case, which persons can access the account data and which are authorized to effect and/or to record transactions for that account might well be known, but their userIDs are secret. Since access and activity to the account can be logged by userID, each user has an incentive to keep their ID secret.
In the "account + password" case, the account name or number is probably shared or even public information, but the password is secret. Accounts can have multiple passwords, with one unique password for each person qua "user" who is authorized to access the data of, and perhaps to effect and/or record transactions for, the account. Ordinarily, each time that a user accesses the account, a log is kept of their activity. Accordingly, each user has an incentive to keep their password secret, whether also to accept that it should be "strong".
Which is to say, account names or numbers, userIDs, and passwords predate their use in the context of the Internet. They were adopted for internal security, as part of a system of control to prevent and/or to detect malfeasance and embezzlement, among other possibilities, by employees and agents of businesses or of other organizations.
Succinctly, they have been, and still are, used in the mitigation of insider risk. Perhaps that context is the one in which they are the most effective. It is also the context in which the rules for creating, securing, and changing, passwords have been created. In particular, changing a password often is desirable because an "insider" who has acquired it and found a use for it is likely to use it repeatedly, whether often, unless and until they are caught (which could be over the course of a long period of time).
We know that adopting "user-name + password" to deter unauthorized access by "outside" intruders can be effective, but it also has weaknesses. The vulnerability of passwords to phishing depends upon the vulnerability of the user, and their vulnerability to illicit keystroke-logging depends upon the vulnerability of the system to malware installation. Of course, both phishing and keystroke-logging typically obtain user-names as well as passwords.
In both contexts in which passwords have been adopted, users often consider "strong" passwords inconvenient and/or simply infeasible. That lessens their incentive to keep them secure, and to create them when they are allowed to create their own password(s).
Mr. Herley is correct in asserting that a 6-digit PIN is adequate for a password, if and only if the system in which it is used does not permit enough unsuccessful attempts for a brute force attack to eventually succeed, whether by "locking out" access to the system when such an attack is detected. Geometrically increasing the amount of time before another attempt is permitted after each invalid password has been entered is a particularly elegant solution. Although, an actual customer who cannot recall their password correctly will probably not appreciate that approach.
Mr. Herley also presents a sound argument for a bank (or other organization) to keep the list of its actual user-names very secure. However, I do not agree that a user-name should be regarded as something which the user can publicize, disclose, or otherwise treat in an unsecure manner, because it should become another barrier to unauthorized access to the account. As already noted, the user-name either directly or indirectly identifies the "account" for which the password must be entered.
Although Mr. Herley mentions "over the shoulder" spying he does not discuss "ATM skimmers". The thieves install a counterfeit front to the actual front of an ATM, and it intercepts and reads the data from the user's ATM card, and records the PIN and any other data which they enter via the keypad. (I haven't heard of one which will steal deposits of cash and/or checks, though that might have been done.)
The web sites at which I've "registered" or "opened an account" either (1) require that a valid e-mail address, for an account to which the user has access, be employed as the user-ID, or (2) permit the user to compose and adopt whatever "user-name" that the user chooses. In the first case, an e-mail address is implicitly unique among all others. Many web sites send an e-mail message to the e-mail address specified by the user, who must respond to it in a designated way to "authenticate" their registration or creation of the account. In the second case, the user might be limited to letters and digits for the user-name, whether also for the password.
Regardless, simply keeping track of all "user-name + password" combinations that I've adopted has been a chore! (Currently, I am implementing LastPass to manage them.)
The bank(s) to which Mr. Herley refers in his article either (1) assign a unique user-name for each customer, (2) assign a unique number that corresponds to each specific bank account instead of a user-name, or (3) adopt a unique "universal identifier" such as the US Social Security Number for each person who is authorized to access the account.
Since the bank with which I do business does not assign a user-name for access to the account via the Internet, I have chosen to adopt one which consists of both upper-case and lower-case letters, digits and special characters. In other words, the user-name is a "strong password" and I treat it as such. The "password" itself is relatively strong, and I also use two-factor authentication. If the bank doesn't "recognize" the IP address that I am currently using (it changes every day), then they require me to answer a "security question". That challenge is made after I have entered the user-name, of course.
Unfortunately, none of this defeats the use of the ZeuS banking spyware "trojan", but I'm such a small fish in such a large pond that I cannot imagine that they would waste a money mule to steal my money. I'm much more concerned about "insider risk", though.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
