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.
ATM skimmers were not really in vogue back in 2007, but they sure are now.
Glad you are giving Last Pass a try. I couldn't convince you, but glad GRC did.
Glad you are giving Last Pass a try. I couldn't convince you, but glad GRC did.
but LastPass is evidently designed with the assumption that each web site, network access point, etc., will have only one log-in dialog consisting of a user-name and a password. I don't have any criticism of the user-name and password assumption.
But there are numerous web sites for which there are two or more log-in dialogs. This is really common on merchant web sites, where one account is to "register" as a "shopper" and the other account is for transacting purchases. In most cases, it is up to the user whether they adopt the same user-name and password for each one, but usually they should have different passwords, at least.
For example, PC Tools has one log-in for the account which the customer creates to purchase the software. IIRC, it is also the source for downloading updates to it. But PC Tools does not have a tech-support staff. Instead, the customer needs to register at the "peer support forum" so that they can post messages asking for help, or post replies that offer advice to other users. The top-level domain name is exactly the same for the commerce account and for the support forum. LastPass cannot distinguish them and considers a record that was created for one to be a duplicate of the other, and deletes one of them.
Another example: my e-mail account has 8 sub-accounts (out of 10 allowed). To log-in to use the web mail interface, though, I must go to exactly the same web site page and enter the user-name for the account or sub-account, and the corresponding password. The e-mail client (Thunderbird) handles this all very well, but LastPass cannot, because the log-in dialog page for every e-mail account and sub-account has the same top-level domain name.
FWIW, I've been in communication with them about this problem in particular, and I suppose that they are probably working on it, whether they have adopted any of my suggestions for a solution.
But there are numerous web sites for which there are two or more log-in dialogs. This is really common on merchant web sites, where one account is to "register" as a "shopper" and the other account is for transacting purchases. In most cases, it is up to the user whether they adopt the same user-name and password for each one, but usually they should have different passwords, at least.
For example, PC Tools has one log-in for the account which the customer creates to purchase the software. IIRC, it is also the source for downloading updates to it. But PC Tools does not have a tech-support staff. Instead, the customer needs to register at the "peer support forum" so that they can post messages asking for help, or post replies that offer advice to other users. The top-level domain name is exactly the same for the commerce account and for the support forum. LastPass cannot distinguish them and considers a record that was created for one to be a duplicate of the other, and deletes one of them.
Another example: my e-mail account has 8 sub-accounts (out of 10 allowed). To log-in to use the web mail interface, though, I must go to exactly the same web site page and enter the user-name for the account or sub-account, and the corresponding password. The e-mail client (Thunderbird) handles this all very well, but LastPass cannot, because the log-in dialog page for every e-mail account and sub-account has the same top-level domain name.
FWIW, I've been in communication with them about this problem in particular, and I suppose that they are probably working on it, whether they have adopted any of my suggestions for a solution.
Those sites that tie loginId to Device Id. A few financial sites track the login Id and Device signature to verify a user. User has to provide a sitekey or Device Id to verify the login Id when attempting to login from a different device.
Seems like a good deterrent scheme.
Seems like a good deterrent scheme.
something such as the IP address of the connection to the Internet which the user's computer system or LAN is using?
FWIW, I don't know why, apparently, no one uses the CPU serial number. When Intel introduced the Pentium CPU family, they provided a serial number for each unit and enabled its disclosure by using a specific instruction, by default. An uproar ensued because it would make individual people too easily identified, and Intel started supplying the CPUs with access to the serial number disabled. (I don't know what would be required to enable it if it is disabled.)
However, Intel must have re-enabled it at some time, because Michael wrote an article about a firm that included the CPU serial number in an authentication system which they developed. When I asked their spokesman about that, he said that their programmers had not encountered any problems obtaining the CPU serial number for any computer on which their software had been executed.
So, I suppose that the CPU serial number couldn't be used to authenticate a computer system, whether also the user, unless the browser, or an add-on to it, can disclose the CPU serial number upon request from a web site. Then again, all things considered, maybe we are better off without that data being disclosed to others.
FWIW, I don't know why, apparently, no one uses the CPU serial number. When Intel introduced the Pentium CPU family, they provided a serial number for each unit and enabled its disclosure by using a specific instruction, by default. An uproar ensued because it would make individual people too easily identified, and Intel started supplying the CPUs with access to the serial number disabled. (I don't know what would be required to enable it if it is disabled.)
However, Intel must have re-enabled it at some time, because Michael wrote an article about a firm that included the CPU serial number in an authentication system which they developed. When I asked their spokesman about that, he said that their programmers had not encountered any problems obtaining the CPU serial number for any computer on which their software had been executed.
So, I suppose that the CPU serial number couldn't be used to authenticate a computer system, whether also the user, unless the browser, or an add-on to it, can disclose the CPU serial number upon request from a web site. Then again, all things considered, maybe we are better off without that data being disclosed to others.
How close to not caring about all this are you, putting your faith instead into pen and paper when you have to, and a 357?
I don't konw what they would use it could be cpu id, manufacturer's machine ID or MAC ID.
Either are risky, ie, old cpus that ship to Nigeria where they have lots of kingdoms available if only you could provide your bank account number.
BTW, device means iPhone, Android, iPad, Blackberry, netbook, etc.
Either are risky, ie, old cpus that ship to Nigeria where they have lots of kingdoms available if only you could provide your bank account number.
BTW, device means iPhone, Android, iPad, Blackberry, netbook, etc.
So, let me guess: they can establish a connection to the Internet, then run a browser to access the online banking web site, yes?? Would that be a "dial-up" connection or is it "broadband"?? What are the transmission speeds for public Wi-Fi networks??
My bank, at least, will still use the IP address assigned to the connection by the ISP to determine whether their web site "recognizes" a computer. Which is really not a good idea when the IP address is "dynamic" and not "static".
I do not know whether every smartphone has a unique Machine Address (MAC address). IIRC, the MAC address of the computer (device) that sends a TCP/IP packet is in the packet header. That is what the LAN router uses to decide which computer is the destination for an incoming packet. (Or so I have heard, I am not an expert on this matter.)
My bank, at least, will still use the IP address assigned to the connection by the ISP to determine whether their web site "recognizes" a computer. Which is really not a good idea when the IP address is "dynamic" and not "static".
I do not know whether every smartphone has a unique Machine Address (MAC address). IIRC, the MAC address of the computer (device) that sends a TCP/IP packet is in the packet header. That is what the LAN router uses to decide which computer is the destination for an incoming packet. (Or so I have heard, I am not an expert on this matter.)
The article section regarding Increase the amount of user ID bits states:
"Messing with the number of bits in the user ID instead of the password has another huge advantage. Ready for this, user IDs do not need to be kept secret. .... A cybercriminal would be hard pressed to gather everyone's user ID from sticky notes stuck to monitors."
A cybercriminal intruding from outside of the premises, e.g., only via a network, would be equally hard-pressed to gather everyone's passwords from sticky notes stuck to monitors, too.
The reason that passwords recorded on sticky notes is "against the rules" is that doing so increases insider risk. When credentials are used only to thwart "outsiders", whether they are written on a note that is kept at hand by the user(s) is largely irrelevant -- unless and until the intrusion becomes the physical presence of the "outsider" or an "insider" provides those credentials to them. (I've read and used credentials included in the instructions which were attached to fax machines.)
IIRC, Mr. Herley shows that increasing the possible number of user-IDs significantly beyond the number of user-IDs which are in use has the greatest benefit. That probably would entail increasing the number of bits (or bytes) in the possible user-IDs, thus in all user-IDs, of course.
What credentials boil down to is that whether the user ID can and should be longer and/or more complex, and the password can possibly be shorter, something significant must be kept secret or there is no point in using a "user-name + password" combination to secure anything. Else, it is like having a locked padlock left with the key inserted into it.
"Messing with the number of bits in the user ID instead of the password has another huge advantage. Ready for this, user IDs do not need to be kept secret. .... A cybercriminal would be hard pressed to gather everyone's user ID from sticky notes stuck to monitors."
A cybercriminal intruding from outside of the premises, e.g., only via a network, would be equally hard-pressed to gather everyone's passwords from sticky notes stuck to monitors, too.
The reason that passwords recorded on sticky notes is "against the rules" is that doing so increases insider risk. When credentials are used only to thwart "outsiders", whether they are written on a note that is kept at hand by the user(s) is largely irrelevant -- unless and until the intrusion becomes the physical presence of the "outsider" or an "insider" provides those credentials to them. (I've read and used credentials included in the instructions which were attached to fax machines.)
IIRC, Mr. Herley shows that increasing the possible number of user-IDs significantly beyond the number of user-IDs which are in use has the greatest benefit. That probably would entail increasing the number of bits (or bytes) in the possible user-IDs, thus in all user-IDs, of course.
What credentials boil down to is that whether the user ID can and should be longer and/or more complex, and the password can possibly be shorter, something significant must be kept secret or there is no point in using a "user-name + password" combination to secure anything. Else, it is like having a locked padlock left with the key inserted into it.
I didn't really differentiate between an inside and an outside cybercriminal.
Dr. Herley has not distinguished between the two contexts either. His papers and your articles have been thought-provoking. I've been thinking about "the password problems" since the previous time that we discussed them.
In particular, I kept wondering about the rationale for the customary "rules", especially about changing passwords often. In Dr. Herley's first paper, about the rejection of security advice, that rule was the fundamental objection that users had, since the effort invested to memorize a "strong" password has to be made all over again when it is changed to another one. That becomes an excuse to write them on a note(s) kept near at hand. There is no obvious profit in the exercise for the user, and with regard to outsider risk, changing them often is unlikely to have a deterrent effect.
So that led to considering why user names and passwords were originally adopted to secure access to data, and I realized that insider risk was the first and fundamental justification, well before they were extended to control access to other assets such as networks.
Every accounting system on which I worked as a programmer had a pervasive and abiding concern with regard to internal security. The accountants did not trust the programmers, either. The adoption of user-IDs, passwords, access and activity logging, and other controls are typically integrated into the system design from the outset. Indeed, they were often implemented for the development of the software, too!
By the way, the "bulk guessing" attack with user-IDs is one that I cannot recall hearing of before. It is an interesting concept.
But I wonder how noticeable to the target that it might become as a result of the increase in the use of bandwidth to access the target's web site. Ten million attempted accesses with the same password for random (?) user-IDs don't show up as attacks on any specific accounts. But do that for several passwords without any significant intervals, and it could become a slow-motion DDoS, especially with simultaneous attacks (i.e., each with a different password).
The increased traffic could also be noticeable if the attacks alter the traffic pattern during the course of the day, such as increasing it significantly during periods of time when traffic is ordinarily low.
More things to think about.
In particular, I kept wondering about the rationale for the customary "rules", especially about changing passwords often. In Dr. Herley's first paper, about the rejection of security advice, that rule was the fundamental objection that users had, since the effort invested to memorize a "strong" password has to be made all over again when it is changed to another one. That becomes an excuse to write them on a note(s) kept near at hand. There is no obvious profit in the exercise for the user, and with regard to outsider risk, changing them often is unlikely to have a deterrent effect.
So that led to considering why user names and passwords were originally adopted to secure access to data, and I realized that insider risk was the first and fundamental justification, well before they were extended to control access to other assets such as networks.
Every accounting system on which I worked as a programmer had a pervasive and abiding concern with regard to internal security. The accountants did not trust the programmers, either. The adoption of user-IDs, passwords, access and activity logging, and other controls are typically integrated into the system design from the outset. Indeed, they were often implemented for the development of the software, too!
By the way, the "bulk guessing" attack with user-IDs is one that I cannot recall hearing of before. It is an interesting concept.
But I wonder how noticeable to the target that it might become as a result of the increase in the use of bandwidth to access the target's web site. Ten million attempted accesses with the same password for random (?) user-IDs don't show up as attacks on any specific accounts. But do that for several passwords without any significant intervals, and it could become a slow-motion DDoS, especially with simultaneous attacks (i.e., each with a different password).
The increased traffic could also be noticeable if the attacks alter the traffic pattern during the course of the day, such as increasing it significantly during periods of time when traffic is ordinarily low.
More things to think about.
but only in a sane usage.
there is little to be gained by using user ids as labels for partitions. [ an example of course, GNU/Linux systems are now using UUID for the fstab. This is the file that is used to mount partitions during boot. ]
it really doesn't make sense to use uids for internal hard drive partitions. maybe for removable media like a thumb drive, but not for the internal hard disk.
UUID being Unique User ID.
there is little to be gained by using user ids as labels for partitions. [ an example of course, GNU/Linux systems are now using UUID for the fstab. This is the file that is used to mount partitions during boot. ]
it really doesn't make sense to use uids for internal hard drive partitions. maybe for removable media like a thumb drive, but not for the internal hard disk.
UUID being Unique User ID.
for partitions negate the need to secure access, to directories and files in the respective partitions, by employing user-IDs and/or passwords?
It seems to me that it could, assuming that the user doesn't have any means to also mount and access another partition that is on the same HDD.
It seems to me that it could, assuming that the user doesn't have any means to also mount and access another partition that is on the same HDD.
since the uuid is only a label and a current system will let the user access any partition, even if it isn't mounted.
the security policy would have to explicitly list partitions not to be accessed, and it's far easier to type sda7 than "8bcdc610-a3e9-4829-aa74-25ec9e380bbb"
[ fwiw, sda7 is a sata drive extended partion on one of my disks, and the posted uuid is the uuid for it. ]
and in this case, the partition is automatically mounted at boot, as /usr, so it's a readable but not writable partition.
[ root being only user that can write to it by default ]
the security policy would have to explicitly list partitions not to be accessed, and it's far easier to type sda7 than "8bcdc610-a3e9-4829-aa74-25ec9e380bbb"
[ fwiw, sda7 is a sata drive extended partion on one of my disks, and the posted uuid is the uuid for it. ]
and in this case, the partition is automatically mounted at boot, as /usr, so it's a readable but not writable partition.
[ root being only user that can write to it by default ]
I think the threat vector of man-in-the-middle userid harvesting is not being strongly considered in the "long user id" suggestion.
Taking the perspective if a man-in-the-middle (malware, reverse proxies, etc.) where one is able to gain access to the HTTP/S traffic flow or say, the browser cookies supporting the "remember my user id?" functionality or native browser userid forms remembering, the threat of gathering that long userid increases. Matching that increase against the proposed decrease in password entropy and I think a case can be made that this long user id approach has significant weaknesses as well.
All this builds the case for multi-factor authentication (which I would venture to say hasn't fully matured in its technical implementation yet, but advancements are being made).
I'm starting a series of blog entries with SSO and then building into multi-factor authentication here if anyone is interested in this topic: http://bit.ly/bXJmjW
Taking the perspective if a man-in-the-middle (malware, reverse proxies, etc.) where one is able to gain access to the HTTP/S traffic flow or say, the browser cookies supporting the "remember my user id?" functionality or native browser userid forms remembering, the threat of gathering that long userid increases. Matching that increase against the proposed decrease in password entropy and I think a case can be made that this long user id approach has significant weaknesses as well.
All this builds the case for multi-factor authentication (which I would venture to say hasn't fully matured in its technical implementation yet, but advancements are being made).
I'm starting a series of blog entries with SSO and then building into multi-factor authentication here if anyone is interested in this topic: http://bit.ly/bXJmjW
It seems that this idea is very narrowly focused, to the exclusion of other, some very vulnerable, attack surfaces.
Quote: "Taking the perspective if a man-in-the-middle (malware, reverse proxies, etc.) where one is able to gain access to the HTTP/S traffic flow or say, the browser cookies supporting the "remember my user id?" functionality or native browser userid forms remembering, the threat of gathering that long userid increases. .... "
Gaining access to TCP/IP packets that are encrypted, as they are with SSL/TLS, is not likely to benefit an intruder. Nearly all of the web sites that I frequent use TLS for pages on which a log-in dialog is presented, even if most or all of the other pages on the site are not encrypted. I have heard, though, that under various circumstances, a MITM attack upon SSL/TLS is possible, and countermeasures were being developed, whether they have been deployed yet.
Also, in my observation, when a cookie contains a user-ID or other sensitive data, then it is apparently encrypted. The content of a cookie is supposed to be ASCII characters, but the string can simply be a series of bits which the browser will display as a string of ASCII characters. I've never had a user ID like A^&70x-2@+! but I don't allow web sites to use that kind of cookie anyway.
FWIW, I've adopted LastPass to manage passwords. The LastPass developer claims that their software can import the passwords from any of a long list of browsers and other password managers, because those programs do not encrypt their password data files. So far, I have never retained form data, but I might use LastPass to do that, too.
Of course, no one can guarantee that any data is secure from unauthorized access, change, or erasure, while the computer system and/or network(s) that it uses are currently compromised by malware or by a real-time hacker(s). That is always a risk that we take. As seanferd has already pointed-out, many web site pages on which log-in dialogs are presented are vulnerable to exploits that allow an intruder to bypass the log-in dialog and gain access to servers that host the web site.
Gaining access to TCP/IP packets that are encrypted, as they are with SSL/TLS, is not likely to benefit an intruder. Nearly all of the web sites that I frequent use TLS for pages on which a log-in dialog is presented, even if most or all of the other pages on the site are not encrypted. I have heard, though, that under various circumstances, a MITM attack upon SSL/TLS is possible, and countermeasures were being developed, whether they have been deployed yet.
Also, in my observation, when a cookie contains a user-ID or other sensitive data, then it is apparently encrypted. The content of a cookie is supposed to be ASCII characters, but the string can simply be a series of bits which the browser will display as a string of ASCII characters. I've never had a user ID like A^&70x-2@+! but I don't allow web sites to use that kind of cookie anyway.
FWIW, I've adopted LastPass to manage passwords. The LastPass developer claims that their software can import the passwords from any of a long list of browsers and other password managers, because those programs do not encrypt their password data files. So far, I have never retained form data, but I might use LastPass to do that, too.
Of course, no one can guarantee that any data is secure from unauthorized access, change, or erasure, while the computer system and/or network(s) that it uses are currently compromised by malware or by a real-time hacker(s). That is always a risk that we take. As seanferd has already pointed-out, many web site pages on which log-in dialogs are presented are vulnerable to exploits that allow an intruder to bypass the log-in dialog and gain access to servers that host the web site.
I started using KeePass/KeePasX to manage my passwords. I imported ids and pws from my browsers, manually added sticky noted id/pws.
KeePass generates randow passwords and plays back your id and pw to login.
KeePass generates randow passwords and plays back your id and pw to login.
We are concentrating large organization, but small organization data are equally important. E.g. if cyber-criminals attack on millions of small organizations it will affect the whole country economy... and also reputation sometimes. So, in future we should concentrate both large and small enterprises as they are equally important...
most of the Internet robberies which are effected with the ZeuS Banking Trojan are from the bank accounts of small- to medium-sized businesses. Or, at least, those are the ones which are reported by news organizations and bloggers such as Brian Krebs (http://www.krebsonsecurity.com).
Credit-card and debit-card fraud also take a heavy toll against small merchants as well as large ones, and affect small banks as well as large ones. There are just too many people who are committing identity theft and fraud to effectively investigate and arrest.
Credit-card and debit-card fraud also take a heavy toll against small merchants as well as large ones, and affect small banks as well as large ones. There are just too many people who are committing identity theft and fraud to effectively investigate and arrest.
The key is the combination of username and password. 5 char + 10 char is 15. Increasing strength with longer usernames makes some sense. The other part being that needs the correct combined somethingyouknow + somethingyouknow to authenticate. This got me thinking that for a user, the email name, the name of the home directory and the name used at login prompt should never be the same.
If someone is limited to attacking user accounts or the exploit requires a valid user for the vulnerability that list has to first be created. If the username is kept as a secret but seporate part of the key, getting email names or home/docsettings directory lists won't help. Make all human readable references to the user different from the username used at login prompts. The name list becomes as unpleasent to generate as the passlist of relevant terms. Exploits that require a username don't work.
The weakness is that there are already ways to get a user list once into the first account. Readable passwd, samba/smb and various local utilities make it a crunchy shell with a squishy middle. This only helps as long as all accounts remain unbroken.
Applicability depends on the location I guess. With forums, a secret username means your alias and email can become public without adding to an attack list. The public information, credentials and PIM remain unrelated objects. With base systems, any other local system login negates the benefits.
Just throwing it out there.. thoughts?
If someone is limited to attacking user accounts or the exploit requires a valid user for the vulnerability that list has to first be created. If the username is kept as a secret but seporate part of the key, getting email names or home/docsettings directory lists won't help. Make all human readable references to the user different from the username used at login prompts. The name list becomes as unpleasent to generate as the passlist of relevant terms. Exploits that require a username don't work.
The weakness is that there are already ways to get a user list once into the first account. Readable passwd, samba/smb and various local utilities make it a crunchy shell with a squishy middle. This only helps as long as all accounts remain unbroken.
Applicability depends on the location I guess. With forums, a secret username means your alias and email can become public without adding to an attack list. The public information, credentials and PIM remain unrelated objects. With base systems, any other local system login negates the benefits.
Just throwing it out there.. thoughts?
But I'm still processing what you wrote.
BBL, hopefully, with some semi-intelligent thoughts.
BBL, hopefully, with some semi-intelligent thoughts.
you got a good one there.
I'll need to think about it, but off the top of my head, the NIS authentication for even local machine with a unique login in it.
the NFS share that login makes as your home instead of local files would be a more secure storage area for sensitive information containing files.
have to look at the network authentication systems to see which, if any, could help give that breakdown.
I'll need to think about it, but off the top of my head, the NIS authentication for even local machine with a unique login in it.
the NFS share that login makes as your home instead of local files would be a more secure storage area for sensitive information containing files.
have to look at the network authentication systems to see which, if any, could help give that breakdown.
Quote: ".... This got me thinking that for a user, the email name, the name of the home directory and the name used at login prompt should never be the same."
I agree with you 100%. I've never liked having an e-mail address required as the user-ID for a log-on dialog. Web site developers seem to prefer it because it is implicitly unique, and whether the account exists is easy to verify by sending a message and requiring the person who is "registering" or "opening an account" to respond to that message in some way before they are granted privileges. But just because the prospective user responds does not mean that the e-mail account is used for any other purpose than as a user-id for web sites which require it.
If an attacker knows that an e-mail address is used as the user-ID, then they do not have to randomly generate the string that follows the @ symbol. What they need is a list of as many e-mail "providers", usually ISPs, as they can feasibly use.
Aside from public web sites, though, using an e-mail address for the user-id to log-on to a private network, such as one's employer, could be giving a prospective intruder a significant advantage, since they can probably discover what the string must be following the @ symbol and they can focus upon using likely user-names which precede the @ symbol, before resorting to random "names".
I agree with you 100%. I've never liked having an e-mail address required as the user-ID for a log-on dialog. Web site developers seem to prefer it because it is implicitly unique, and whether the account exists is easy to verify by sending a message and requiring the person who is "registering" or "opening an account" to respond to that message in some way before they are granted privileges. But just because the prospective user responds does not mean that the e-mail account is used for any other purpose than as a user-id for web sites which require it.
If an attacker knows that an e-mail address is used as the user-ID, then they do not have to randomly generate the string that follows the @ symbol. What they need is a list of as many e-mail "providers", usually ISPs, as they can feasibly use.
Aside from public web sites, though, using an e-mail address for the user-id to log-on to a private network, such as one's employer, could be giving a prospective intruder a significant advantage, since they can probably discover what the string must be following the @ symbol and they can focus upon using likely user-names which precede the @ symbol, before resorting to random "names".
to get corporate email addresses.
any publicly traded company has to meet reporting guidelines, part o which is a listing of employees.
so the public list of staff names and the company name and take the first initial and last name for email address and login.
or whole first name and last name.
those are the two most common login name schemes used.
any publicly traded company has to meet reporting guidelines, part o which is a listing of employees.
so the public list of staff names and the company name and take the first initial and last name for email address and login.
or whole first name and last name.
those are the two most common login name schemes used.
must disclose the names of all employees? That could be a list of 20,000+ names for some firms and it changes every day.
AFAIK, in reports to the SEC, corporations must disclose the names of the corporation's officers, which customarily (and by laws, too) include the President, Vice-President(s), Secretary, and Treasurer of the corporation. Law or regulations probably require them to disclose who is in such positions of responsibility as the "CEO" and "CFO" if not also the "CTO". In each arcronymn, the "O" stands for "officer".
AFAIK, in reports to the SEC, corporations must disclose the names of the corporation's officers, which customarily (and by laws, too) include the President, Vice-President(s), Secretary, and Treasurer of the corporation. Law or regulations probably require them to disclose who is in such positions of responsibility as the "CEO" and "CFO" if not also the "CTO". In each arcronymn, the "O" stands for "officer".
Like, asking both a user Id, a password and a "domain name" type Id... even if they're all of 6 chars that'd mean a lot of space cover...
Actually, I'm still looking for a way to set a default domain for Windows logins. When I'm in as local admin, I have to log out and back in as domain admin so that when the user returns, the domain doesn't block or confuse them by showing the machine name instead.
Anyhow, in the case of Windows, your already entering a uname/pword/domain. Thinks like Cisco gateways that tap into MS-LDAP also ask for all three. In the end, I don't know if it provides a third dimension for calculations with any benefit over two though.
My initial thinking would be that your better to look for dual authentication at that point. Unless the domain specifies a seporate area of the same machine (eg. egroupware supporting more than one domain), you may not be adding much to what is still a single authentication login. Granted, somethignyouhave and somethignyouare become complicated where websites are concerned.
Anyhow, in the case of Windows, your already entering a uname/pword/domain. Thinks like Cisco gateways that tap into MS-LDAP also ask for all three. In the end, I don't know if it provides a third dimension for calculations with any benefit over two though.
My initial thinking would be that your better to look for dual authentication at that point. Unless the domain specifies a seporate area of the same machine (eg. egroupware supporting more than one domain), you may not be adding much to what is still a single authentication login. Granted, somethignyouhave and somethignyouare become complicated where websites are concerned.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
