Security

User IDs and passwords: Equally important for access security

Is it time to think differently about web-site login credentials? Three researchers believe so and provide thought-provoking reasons why. Michael Kassner considers their results.

Is it time to think differently about web-site login credentials? Three researchers believe so and provide thought-provoking reasons why.

---------------------------------------------------------------------------------------

A few months ago, I met Dr. Cormac Herley, principal researcher at Microsoft. After a few interesting conversations, I penned an article: "Are users right in rejecting security advice." My goal was to present Dr. Herley's arguments as to why users should reject security practices that are costly and ineffective.

I stumbled on another paper that Dr. Herley co-authored with Dr. Dinei Florencio a fellow Microsoft researcher and Dr. Baris Coskun, a research assistant at Polytechnic University. I was hoping this paper would be as provocative as the previous one, and it was.

"Do Strong Web Passwords Accomplish Anything?" attempts to explain what is wrong with current methodology regarding web-site user IDs and passwords. I'd like to present their case. See if it resonates with you.

Principal threats

First and foremost, outright theft of web-site login credentials, especially those for financial institutions is serious. To that end, the paper considers the following to be the principal methods of stealing web-site access information:

  • Phishing
  • Keylogging
  • Special knowledge or access attacks (employ known information about user, shoulder surfing, or gain access to computer)
  • Brute-force attack on an individual account
  • Bulk-guessing attack on all accounts at the site

Current best practices

Then to make sure everyone is on the same page, the paper mentions what is currently considered appropriate password administration:

  • Choose strong passwords
  • Change passwords frequently
  • Never write passwords down

Not working

The researchers feel this advice is out-of-date. Password "best practices" will not protect your login credentials from phishing, keylogging, or special-knowledge attacks. I suspect most would agree, but what about brute-force and bulk-guessing attacks?

Brute-force attacks

The authors feel guessing and brute-force attacks are ineffective. That's because system administrators block access after a specific number of failed-login attempts. They offer the following example as proof of how well it works:

"If a bank allows only six-digits PINs (a relatively weak password) and locks an account for 24 hours after three attempts, an attacker could search 3 x 365 x 10=1e6 or 1% of the key-space in 10 years. Further, the ratio of unsuccessful to successful logins would be huge and easily detected."

That's probably true, but what about web sites without a lock-out policy?

Bulk-guessing attacks

I must confess, bulk-guessing attacks were never on my radar. They should have been, as they work. The following example from the paper explains the concept behind bulk-guessing attacks:

"Suppose a bank has 10 million online user accounts. If the bank allows six-digit PINs, each PIN will on average be used by 10 different users. Instead of searching all possible passwords for a given user ID, an attacker can search all possible user ID's for a given password. 10 million attempts will yield 10 successful logins using this strategy."

The authors also suggest that this approach is a lot stealthier:

"When attacking the password space of a single user ID it is very difficult for the attacker to conceal the attempts among the user's actual logins. In dispersing the attack across the whole user-ID space however the picture changes: the 10 million trials will amount to only one unsuccessful login per account."

To some, ten successful attacks seem trivial when there are 10 million members. That is unless you are one of the ten.

Credentials

Next, the researchers wanted to determine how much digital information is required for each user ID/password combination. It could become a significant amount if multiplied by 10 million as in the above example:

"The bank in the example has 10 million online users, and each uses a 20-bit password (a six-digit PIN). The bank has simple user ID's. Customers are assigned consecutive seven-digit numbers. This is approximately 23 bits. To gain entry to a member's account, the attacker must enter 43 bits. We'll call the 43-bit user-ID password pair the bank's credential.

So the credential search space that the bulk-guessing attacker lives in is 243. There are approximately 223 valid accounts, so the attacker can expect to break in to one account per 220 attempts."

The researchers found increasing the number of bits used to create individual credentials to be an effective deterrent against bulk-guessing attacks. The research team offers the following mathematical relationships as proof.

  • Bu: Is the size of the user ID in bits
  • Bp: Is the size of the password in bits
  • N: Variable representing the number of members

The following expression represents the total credential space that a bulk-guessing attacker would have to search:

2Bu+Bp

The next equation represents the number of attempts required per successful break-in:

(2Bu+Bp)/N

From the second expression, one can see that increasing the size of the user ID or password exponentially increases the number of attempts required to get a match.

Increase the amount of user ID bits

Increasing the number of password bits is not recommended. The researchers have already explained how increasing password size does not reduce the risk from phishing, keylogging, or special-knowledge attacks. Besides, users have enough trouble remembering simple passwords. So why not increase the size of the user ID instead? Doing so will obtain the same results.

Messing with the number of bits in the user ID instead of the password has another huge advantage. Ready for this, user ID's do not need to be kept secret. The user ID can be displayed for everyone to see. A cybercriminal would be hard pressed to gather everyone's user ID from sticky notes stuck to monitors.

The research team does have one concern: that of attackers being able to get complete lists from the institution's database. The researchers make the assumption (a logical one, but still an assumption) that user ID lists are heavily guarded. If a list ever became public, that establishment could be held hostage under the threat of a Denial of Service attack using the list of user IDs and bad passwords.

Paper's conclusions

In conclusion, the research team offers two solutions, one for large institutions and one for small institutions:

  • Large institutions: Use short, simple passwords with longer user IDs. Doing so reduces the chance of a successful login-credential attack, and makes it easier for the user.
  • Small institutions: Cybercriminals would not want to go through all the effort of a bulk-guessing attack with so few users. That said, the paper concludes simple, short passwords will work as long as there is an unsuccessful-login lockout policy in place.

Final thoughts

I now have a different viewpoint about user-login credentials, having read both papers. The concept is interesting, yet some will find the research controversial. Also, it seems Dr. Herley isn't done yet. In a recent email he mentioned another paper that he coauthored:

"The new paper explains a way to figure out which passwords are too popular across a large population. We think forbidding the ones that become too popular is a better approach than forcing users to comply with password-complexity requirements."

So, please stay in touch.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

54 comments
Neon Samurai
Neon Samurai

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?

akshatvithalani
akshatvithalani

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...

jfbauer
jfbauer

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

Jaqui
Jaqui

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.

Ocie3
Ocie3

The article section regarding [b]Increase the amount of user ID bits[/b] states: [i]"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."[/i] A cybercriminal intruding from outside of the premises, [i]e.g.,[/i] only [i]via[/i] a network, would be equally hard-pressed to gather everyone's [b]passwords[/b] from sticky notes stuck to monitors, too. The reason that passwords recorded on sticky notes is "against the rules" is that doing so [i]increases insider risk[/i]. 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.

Ocie3
Ocie3

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 [i]qua[/i] "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 [i]insider risk[/i]. 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" [i]intruders[/i] 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, [i]if and only if[/i] 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 [i]via[/i] 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 [i]bank(s)[/i] to which Mr. Herley refers in his article either (1) [b]assign[/b] 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 [i]via[/i] 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 [i]my[/i] money. I'm much more concerned about "insider risk", though.

seanferd
seanferd

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.

santeewelding
santeewelding

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 [i]can[/i] tell you I'm about to make an immediate change on account of my initial understanding. _______ Change effected and confirmed by the institution.

Orodreth
Orodreth

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.

Michael Kassner
Michael Kassner

Several researchers think so. They have some good arguments. See what they have to say.

AnsuGisalas
AnsuGisalas

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...

Ocie3
Ocie3

Quote: [i]".... 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] 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".

Jaqui
Jaqui

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.

seanferd
seanferd

But I'm still processing what you wrote. BBL, hopefully, with some semi-intelligent thoughts. :D

Michael Kassner
Michael Kassner

I mentioned what Dr. Herley suggested for large and small enterprises.

Ocie3
Ocie3

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.

Ocie3
Ocie3

Quote: [i]"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. .... "[/i] 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.

seanferd
seanferd

It seems that this idea is very narrowly focused, to the exclusion of other, some very vulnerable, attack surfaces.

Ocie3
Ocie3

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.

Michael Kassner
Michael Kassner

I didn't really differentiate between an inside and an outside cybercriminal.

Michael Kassner
Michael Kassner

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.

AnsuGisalas
AnsuGisalas

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.)

Michael Kassner
Michael Kassner

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.

santeewelding
santeewelding

For your own good. Keep it close to your vest.

Michael Kassner
Michael Kassner

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.

AnsuGisalas
AnsuGisalas

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.

elrico-fantastica
elrico-fantastica

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..

jc@dshs
jc@dshs

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.

Neon Samurai
Neon Samurai

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.

Jaqui
Jaqui

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.

Orodreth
Orodreth

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.

Jaqui
Jaqui

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 ]

Ocie3
Ocie3

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 [i]outsider risk,[/i] 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 [i]insider risk[/i] 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 [b]"bulk guessing" attack[/b] 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]i.e.,[/i] 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. :-)

Ocie3
Ocie3

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.

seanferd
seanferd

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.

Michael Kassner
Michael Kassner

That's why the researchers say using a simple password and a lock out policy is sufficient as well.

seanferd
seanferd

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.

boxfiddler
boxfiddler

'fair'. The only thing I know of that's fair is death.

Michael Kassner
Michael Kassner

It is some interesting stuff. Dr. Herley has another paper that I am working on and it's pretty cool as well.

Michael Kassner
Michael Kassner

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.

klaasvanbe
klaasvanbe

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.

Michael Kassner
Michael Kassner

The one thing I learned from this paper was that having a userID format for all employees is not a good thing.

Ocie3
Ocie3

must disclose the names of [i]all[/i] 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 [i]officers[/i], 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". :-)

Ocie3
Ocie3

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.)

Orodreth
Orodreth

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.

santeewelding
santeewelding

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?

Ocie3
Ocie3

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.

Orodreth
Orodreth

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.

Michael Kassner
Michael Kassner

Many corporations use uniform usernames that are easy to figure out. Then it is just a matter of getting an employee list.