Forgot your password?
typodupeerror
Security

Honeywords — Honeypot Passwords 110

Posted by Soulskill
from the oh-bother dept.
CowboyRobot writes "Businesses should seed their password databases with fake passwords and then monitor all login attempts for use of those credentials to detect if hackers have stolen stored user information. That's the thinking behind the 'honeywords' concept first proposed this month in 'Honeywords: Making Password-Cracking Detectable (PDF),' a paper written by Ari Juels, chief scientist at security firm RSA, and MIT professor Ronald L. Rivest (the 'R' in 'RSA'). Honeywords aren't meant to serve as a replacement for good password security practices. But as numerous breaches continue to demonstrate, regardless of the security that businesses have put in place, they often fail to detect when users' passwords have been compromised."
This discussion has been archived. No new comments can be posted.

Honeywords — Honeypot Passwords

Comments Filter:
  • by Nadaka (224565) on Wednesday May 08, 2013 @04:20PM (#43668441)

    It really is.

    • by marcosdumay (620877) <marcosdumay&gmail,com> on Wednesday May 08, 2013 @04:31PM (#43668553) Homepage Journal

      It's an interesting and intriguing idea, yeah. But I still didn't settle on "good".

      How is an attacker supposed to get such passwords? He certainly can't phish them or get them in transit or while in memory. We are protecting against the password database leaking, but then, it's a set of salted hashes, so it's useless for the attacker... Unless it's something so easy to crack that you can be sure that it'll get cracked, but then, you are probably receiving several login attempts with those passwords already.

      • by djmurdoch (306849) on Wednesday May 08, 2013 @04:42PM (#43668669)

        It's exactly intended to detect theft of your password database. If you salt in a known way, then it's inconvenient for the attacker, but it's still possible to brute force it. And if there's a bug in whatever hashing scheme you used, it might be easy.

        Wouldn't you like to know when someone has done that?

        • I think you are far more likely to screw up this scheme than password hashing + salting.

          The idea may be good, but more complicated and more complicated = more buggy = less secure.

          • by djmurdoch (306849)

            Yes, but even if you don't screw up the hashing, brute force attacks are possible. This approach discourages those, because an attacker won't know which of the broken passwords is safe to use without being immediately detected.

      • by hairyfeet (841228)
        Nice to see I'm not the only one scratching my head trying to figure out WHY you would want to do this instead of...you know,actually doing it smart by using salted hashes? I mean correct me if I'm wrong but I thought the whole point was to make it so even if they got it they couldn't use it because it would take too long to decrypt, so how exactly would these "honeywords" work, unless you suspect somebody on the inside is stealing from you in which case i think you have bigger problems.
        • things is most salted password tables I saw in open-sources products (no reason to believe that proprietary is different) looked likes this :
          TABLE PASSWORD

          INTEGER user_id,
          CHAR VARYING salt,
          CHARACTER VARYING hash,
          CHARACTER VARYING algorithm

          If the attacker get your database, your still screwed.
          • by LordLimecat (1103839) on Wednesday May 08, 2013 @05:45PM (#43669309)

            Salts and hashing algorithms arent supposed to be secret. The only requirement for the salt is that it be unique, and the only requirement for the hashing algo is that it be secure.

            • by Anonymous Coward

              yup

              I use SHA 512 for both the hashed password and salt, and the salt is generated by creating a very large string with multiple secure random calls.

              If an attacker managed to get the hashed password and the salt AND the appropriate model file(not everything is stored in my database), it would be near impossible to crack even the simplest of passwords. At least not by the time his great great great great great great granchild is at least 100 years old.

        • Re: (Score:3, Insightful)

          by eddy (18759)

          You'd do it because salted passwords are falling to increasing GPU power. It's a brand new world.

          • Doesn't mean you SHOULDN'T use a good KDF like scrypt [wikipedia.org] of course, but remember that these "honey accounts" can give you more information. If your data is stolen you want to know about it as soon as possible for all sorts of reasons. If someone breaks in and steals your super-safe account database, you still have a problem you want to detect and fix; the break-in itself. This can be one more layer in that protection.

          • Actually good secure salting password algorithms (e.g. not plain SHA1) can't fit in to a GPU.
            They chew too much memory to create one hash that a GPU can't provide but a CPU can provide easily.
            Its one of their features.

          • by hairyfeet (841228)

            Citation please? Because the only failures i have heard of is those using already depreciated crypto like DES or SHA, have yet to hear of anybody breaking into 512bit AES, in fact last I heard that the length of time required to brute force a 512bit AES using an 8 digit password of the usual numbers, characters, and symbols and properly hashed was on the order of longer than the sun will survive, were talking tens of billions of years.

            Throwing more hardware at it only gets you to a certain point, after th

        • by Cormacus (976625) on Wednesday May 08, 2013 @05:39PM (#43669259) Homepage
          I think the point is that this method doesn't actually prevent any of the breaches that best practices (salting, using a strong hash alg, etc) protect against; rather it provides early warning that your best practices failed. If any one of your honeypot passwords get used, immediately shut everything down ala Madagascar then find and fix the hole the hackers used.
        • I think this is an excellent idea. I've been using versions of this for years and it's come in useful.

          This is an early warning system in case things go wrong. And things do go wrong even when competent and paying attention to best practices.
          • by rickb928 (945187) on Wednesday May 08, 2013 @07:10PM (#43670223) Homepage Journal

            I've done this for more than a decade. I first heard about this in database development, seeding the subscription table, for instance, with fake subscribers to both test that delivery was made ( I and my address was one of the fakes) and to catch thieves using the list. Virtually every mailing list I've handled has had trap users in it. Every mail server I've built has had traps in it both to verify spam and catch the thieves.

            This is virtually BAU for me and my fellow admins on servers that we maintain. Trap users and such are very handy. I usually have a few users with no shell or anything on the server(s) just to catch this, and log analyzers that watch and report.

            And I expect we'll get pwned again some day. It used to be script kiddies pretending to be ninjas haxrs, but nowadays it's mostly random attackers that hate me, or generic botnet and compromisers by the tens of thousands. Sometimes I would rather not run a mail server.

            Fortunately, the last few times we've had trouble, I was able to trace back close to the offenders. The university network guys were marginally interested, but the ISP in the southeastern US took action. I don't expect them to do that again, so I just watch and wait.

            But trap users, seeding honeywords, very good ideas.

        • I mean correct me if I'm wrong but

          You are wrong. Good security is characterized by defense in depth. Adding another layer of defense is usually better than just trying to strengthen an existing layer. Of course you should use salted passwords. That is good practice, but there are a number of ways that it could fail.

          unless you suspect somebody on the inside is stealing from you in which case i think you have bigger problems.

          Really? What is a "bigger problem" than the cost of the lawsuits, lost customers, and PR disaster that would result from an insider stealing your customers' sensitive data?

        • I can tell you two reasons to do it. Often, the billing company manages the password list. The top billing companies including Paypal, CCBill, etc. do not use strong hashes by default. Instead, they use DES, which was secure in 1972. Hundreds of thousands of sites use a third party security package like Strongbox to provide password security for those passwords which are generated by the biller(s). Strongbox or a similar third party solution can use "honeywords" to detect breaches even if they can't con
          • So, the idea is that programmers that aren't comeptent enough to choose a good authentication library will implement that and discover they are not competent?

            If you are going to change your authentication routines, why would you just put an alarm instead of making them secure?

            • Apparently I completely failed to communicate the points.

              First, most often, the programmers choosing the algorithm are NOT employed by the owner of the site. The owner of the site wants to protect themselves from dumb decisions made by the billing company. Most sites use a third party biller such as Paypal, CCBill, Zombaio, etc. If you run geektutorials.com, billing through Paypal, you have no control over what algorithm Paypal uses to store your passwords*. You do, however, want to be notified when your
              • But if an atacker gets your PayPal password by breaching PayPal's database, he'll use it to long into PayPal's site, not yours, and it is PayPal that must impement the fix, not you. Of course, the person that wants the fix isn't the same that wrote the flaw, the problem is that the person with the capacity of actualy creating the fix is the same person that created the flaw (and sometimes doesn't want it exposed).

                Your second scenario is useful. If your code stop being updated, you get an alarm. The problem

                • No, Marcospothead, read it again (either post). When you pay for a web site, Paypal or some other biller accepts your $5 so that you can access geektutorials.com or whatever. Paypal or CCBill or whichever biller creates your password for geektutorials.com. That has nothing whatsoever to do with your PayPal password.
                  • BTW you may be familiar with it from when you log in to GirlsGoneWild.com or whatever. Have you ever noticed the "protected by Strongbox" message on any of the sites you visit late at night? Maybe you also noticed that yur credit card statement doesn't show the charge as being from "GirlsGoneWild.com", but from some billing company. The billing company creates and hashes your GGW.com password. The owners of GGW.com use Strongbox to watch over the passwords that are managed by Paypal or whichever billin
        • This is like a fire alarm in a dorm. Everyone knows the buildings made out of cinder block, but you just don't know what could happen... and fire alarms are cheap so why the hell not?

          • It's probably more like a fire alarm in a concrete building that goes out every time someones fires a match or smoke a cigarrete.

      • by Nemyst (1383049)
        It is a good idea. It takes very little effort, it's compatible with every possible backend, and it's an additional warning for when things go awry. Remember, you never plan for things to go wrong.
      • by kasperd (592156)

        Unless it's something so easy to crack that you can be sure that it'll get cracked, but then, you are probably receiving several login attempts with those passwords already.

        You could use a difficult to guess, but plausibly looking username like for example trillyps658. Then combine that with an easy to guess password like for example password12345. The username would be stored in plaintext in the database, the password would be salted and hashed like the rest of the database, but could be one of the first t

        • In that case, what you are detecting is really that the usernames are leaked and not the passwords.

          That's why I'm not sure about it. The article got me thinking about how unused usernames could leak. At most sites they are simply public data, but even if not published outright this is way more likely to lead to false positives than a real security breach detection. And false positives make people lenient.

          Besides, as I said, it does not detect the most likely situations where your passwords may leak.

    • by TiggertheMad (556308) on Wednesday May 08, 2013 @05:16PM (#43669039) Homepage Journal
      Ok, for those who didn't RTFA, or don't know anything about security, you have a list of users and encrypted passwords in a DB. They log on and their password is checked against the DB. The problem is how do you know if someone has stolen your DB so they can crack it offline? (Offline brute force attacks are much more effective since they are thousands of times faster) So the author proposes that you give each user several possible passwords in the DB, only one of which is the correct one. If other passwords are used to logon, a danger alarm goes off, and you know someone has stolen your DB.

      There are several problems with this idea. To make it work, you have to have a second DB listing all the passwords, and some sort of marker indicating which ones are real and which are fakes. You can't put this in the main DB, because then the hackers would have stolen this info too, and can tell which passwords are real. So you have a second, more secure system for this. Aside from the problems in maintaining a separate parallel system, one might ask the question, "why isn't your primary DB as secure as the secondary DB?". If attackers can breach your main defenses how do you know they cannot breach your backup network? What happens if your secondary system goes down?

      More insidious, there is the recursive security problem. The point of doing this is for the assurance that your password DB is secure. How will you know if an attacker has gained access to your secondary password DB? Well, that would require a third password DB.......
      • by gamanimatron (1327245) on Wednesday May 08, 2013 @06:08PM (#43669587) Journal
        Some responses (informed by the actual paper [mit.edu]):

        The second DB doesn't have any of the the password hashes, it just knows which one is correct. It's a single table of (userid, hashid) where hashid is just some small integer.

        The idea seems to be that the second system can be a smaller, less complicated single-function server, easier to harden and could be running a different OS/Webserver/DB stack. You could (by sacrificing real-time validation) even have the second system entirely firewalled off and unreachable to an attacker, just polling the login servers to validate the sessions at some small interval.

        If the second system goes down, one approach would be to just accept any of the passwords until it comes back up. Then check the logs of what happened while it was offline and act accordingly (invalidate sessions, raise alarms, whatever).

        Overall, I like the idea tremendously. It seems like it's not quite all there yet, but we're probably going to start implementing some variant of it immediately.
        • The idea seems to be that the second system can be a smaller, less complicated single-function server, easier to harden and could be running a different OS/Webserver/DB stack. You could (by sacrificing real-time validation) even have the second system entirely firewalled off and unreachable to an attacker, just polling the login servers to validate the sessions at some small interval.

          And how are you going to implement password resets in any sort of timely fashion on this magic one-way ultra-secure box? I can pretty much respond to any answer you will give me with either a) won't scale or b) new security vulnerability.

          • *shrug*

            In my hypothetical offline-validator scenario, it doesn't have to scale because it's not running at transaction time. Go ahead and reset the password, generate a bunch of new fake hashes and store the index of the "real" one in the same log that will be picked up for validation later on. With asymmetric encryption, the log could be stolen outright and be of no use at all to an attacker.

            That said, I'd probably lean towards an online validator just so I could stick attackers in a honeypot and k
      • by Patman64 (1622643)

        To make it work, you have to have a second DB listing all the passwords, and some sort of marker indicating which ones are real and which are fakes. You can't put this in the main DB, because then the hackers would have stolen this info too, and can tell which passwords are real. So you have a second, more secure system for this. Aside from the problems in maintaining a separate parallel system, one might ask the question, "why isn't your primary DB as secure as the secondary DB?". If attackers can breach your main defenses how do you know they cannot breach your backup network? What happens if your secondary system goes down?

        You don't necessarily need a second DB. Just make which-one-is-the-right-one be a function of some other data, like the username.

      • by Tom (822)

        Yeah, like all great ideas, it needs polishing.

        I wouldn't put the real/fake distinction into the database at all. I would put it into the code. For example, a simple noise function (pseudo-random, but deterministic) using a never-changing part of the user data such as the ID as input determines which of the n passwords is the valid one.

        But frankly, the fact that a single user has more then one password at all would be a dead-giveway that there's some kind of trap to any skilled attacker. If you're not inter

    • by mwvdlee (775178)

      So now hackers must compromise the login tracking database as well, before deciding on which passwords to use?

  • This is new news? I implemented this same thing 4 years ago and it's hard to imagine nobody else has considered it.

  • by Anonymous Coward

    I'm actually a bit annoyed right now: I've been working on this concept for about a month now. I guess I should be honored by the "great minds think alike" thing, but damnit, I wanted to finally get my name out there.

    It's a good start and part of the technique I've been working with... great way to catch exfiltrations in progress, but we could go a bit further. Patches to critical services like SSH could be developed that would accept lists of common bruteforced passwords and automatically block and alert,

    • I'm actually a bit annoyed right now: I've been working on this concept for about a month now. I guess I should be honored by the "great minds think alike" thing, but damnit, I wanted to finally get my name out there.

      It's a good start and part of the technique I've been working with... great way to catch exfiltrations in progress, but we could go a bit further. Patches to critical services like SSH could be developed that would accept lists of common bruteforced passwords and automatically block and alert, or even pass the connecting client over to a honeypot.

      I've been doing this for years via fail2ban; just doing blacklisting, not honeynet redirecting, but still...

      One thing I used to have set up was a redirect to a secondary firewall table for hosts entering the wrong passwords; the secondary firewall table had redirects to a dummy server that was configured with a completely fake network and service topography... so if someone started attacking using an IP, the information they gleaned would be completely misleading without actually providing an active honeypo

    • by Cenan (1892902)

      As opposed to just straight up monitoring if someone is pilfering with your shit?
      C'mon now, are you suggesting this as a fix for the flawed philosophy that a user account can have any sort of privileges against a database that stores user information? There are certain methods within certain processes that might need those kinds of privileges, but the problem only arises when you equate a user and a process, and assign permissions to them from the same set.

      Looking at a finer grain than [yes|no] assignment o

  • If I make a copy of the password database and place it on my machine then how will an alarm reach the admins?
    • by zindorsky (710179) <zindorsky@gmail.com> on Wednesday May 08, 2013 @04:29PM (#43668537)

      When you use one of the fake ID and passwords to try to log in. That will set off an alarm in the system that someone has stolen the database. Think about it - it's really quite clever.

      • by rsborg (111459)

        When you use one of the fake ID and passwords to try to log in. That will set off an alarm in the system that someone has stolen the database. Think about it - it's really quite clever.

        Isn't this kind of like ISP-based spam detection - when you create a list of honeypot email addresses that no one would ever email on purpose - anyone who sends to those email addresses are likely a spammer, and should be added to the spam sender blacklist.

      • To be clear, this isn't a Fake ID and Password. I was thrown for a moment too, since honeyaccounts are already used.

        Problem #1 with a honey account is that you have to have many many many accounts to increase your odds of the attacker happening to try one of your accounts and logging in with it. Ideally you would have as many fake accounts as real ones to increase the odds of them testing a honey account early on instead of them potentially accessing dozens of accounts (which ones?) before triggering an a

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      There are a couple of ways:

      1) You attempt to log in to a service using the honeyword. This trips routines in the code that recognize the account as a honeypot account and not something real, which throws alerts. This seems to be the method being suggested in the paper, though I've only glanced at it so far.

      2) A better way that I don't see mentioned: using an IDS. Set up custom rules at host and network layers to look for the occurrence of a given set of 'honeyword' strings and their encrypted variants. Chan

    • An adversary who steals a file of hashed pass-words and inverts the hash function cannot tell if he has found the password or a honeyword.

      Nevermind it was in the second link. Basically the attacker gets a 1 in 3 chance on each login of tripping alarm when logging in. Stronger passwords would stand out from the honeywords though if the honeywords are weak passwords. If honeywords are strong passwords then weak passwords would stand out.

      • by N1AK (864906)
        Should be reasonably easy to handle. Put the real password through a password rating system and then generate alternative passwords with similar rankings.
    • The alarm will reach them when you try to use the fake passwords to access their servers.

    • If I make a copy of the password database and place it on my machine then how will an alarm reach the admins?

      It won't, if all you do with the passwords is keep them on your own machine.

      But if you try to use of the passwords to access the machine you took them from, that's when you risk alerting the admins.

    • If I make a copy of the password database and place it on my machine then how will an alarm reach the admins?

      I'll answer the "How does this work?" part, as your comment has nothing to do with the information provided.

      If you have a copy of the password db, good for you. If you crack the accounts and try to use an elevated account to access something, and that elevated account is a dummy account, alarm bells will go off everywhere. That's how this works. And everyone should be doing it.

      Back in the day, I did something "similar" where I created a bunch of "default" accounts using common usernames and passwords, an

    • I think this is the scenario: 1) Honeywords (userid/password pairs) are seeded into an organization passwd file. 2) Bad guy acquire the passwd file (the "how" doesn't matter). 3) Bad guys use offline resources to decrypt the stolen passwd file. 4) Bad guys attempt to access the organization's systems/applications using the now decrypted userid/password pair aka the honeyword 5) The use of the honeyword (exact userid with the exacted seeded password) set of alert. 6) The Org can deny access and perhaps do o
  • A better name?

    Power Words! As in, Power Word Stun, Power Word Kill, etc.

    See also http://www.d20srd.org/srd/spells/powerWordStun.htm [d20srd.org]

  • They should also create fake user accounts, with fake social security numbers, fake credit card numbers etc etc. Then the thieves would waste so much of time pursuing these fake data and eventually give up not being able to tell a really dumb user with a dumb password and a fake account with a dumb password.

    But it is not new. I have done something similar. But my lips are sealed about that project.

  • by xxxJonBoyxxx (565205) on Wednesday May 08, 2013 @04:32PM (#43668575)

    When you "seed your authentication databases with fake passwords", you've really just added a bunch of accounts with the same username/password across multiple systems. A smarter (less invasive) approach might be to compare actual hack attempts against existing or recent lists of known usernames; if they're close, that's a tip-off that someone knows more about your authentication store than he or she should.

    • Re: (Score:2, Interesting)

      by Anonymous Coward

      When you "seed your authentication databases with fake passwords", you've really just added a bunch of accounts with the same username/password across multiple systems.

      Not necessarily. The username/password combinations don't have to be the same, and they can be trapped higher up the chain in the code that processes authentication requests so that they can't actually be used to gain access to systems. Better yet, they can be used to redirect attackers to higher interaction honeypots where their nefarious de

      • >> username/password combinations don't have to be the same

        If you've implemented SSO on even groups of systems, they will be the same. :)

        >> can be trapped higher up the chain in the code that processes authentication requests so that they can't actually be used to gain access to systems

        To do that, you need to set a "fake" flag on the credentials, and bad guys can use that to filter out the fake creds from the store.

        >> these act to dissuade attackers in the same way as "sting operations" ac

        • by rsborg (111459)

          To do that, you need to set a "fake" flag on the credentials, and bad guys can use that to filter out the fake creds from the store.

          Clearly the "fake cred" would never be a flag in the users table (or even in the same database/system). For example, it could be a process that scans your logfiles and alerts based on username.

          If someone has pwnd your system and can rewrite logs you have a *much* bigger problem than stolen passwords.

          • >> Clearly the "fake cred" would never be a flag in the users table (or even in the same database/system). For example, it could be a process that scans your logfiles and alerts based on username.

            That's my point. If you're already doing this, you don't need to inject fake credentials into your databases to detect unusually accurate snooping.

            • by rsborg (111459)

              >> Clearly the "fake cred" would never be a flag in the users table (or even in the same database/system). For example, it could be a process that scans your logfiles and alerts based on username.

              That's my point. If you're already doing this, you don't need to inject fake credentials into your databases to detect unusually accurate snooping.

              We're not on the same page.

              How would you know if a login using a valid credential set is legitmate or from a stolen password? Answer: you don't. However, if you have fake users in your system that *no one* would ever login with, then you can know your system credentials have been compromised.

              And this is to detect if your password db has been stolen, not "snooping". Using this method to uncover snooping would never find your fake credentials unless you constantly test those fakes.

        • The "fake" flag, as you put it can be stored on a separate server and since it is storing such a small, tiny fraction of your user data (a map of usernames to an integer indicating the correct hash to look for) it can be much more tightly restricted.

    • The whole purpose of this system is to detect "actual hack attempts". No one is going to brute force a good password directly on the service, they're going to get a leaked/stolen copy of the password database and try to crack the passwords locally. With this system, the attacker doesn't know which hash is the one that will actually grant access. You could have 100 hashes for each user; enter the correct password and access is granted, enter a random password and access is denied, enter a password that ge

  • A better idea would be to seed the honey pot passwords to phishing attempts while waiting for the host to close them down.

  • Honeytoken (Score:5, Interesting)

    by ZouPrime (460611) on Wednesday May 08, 2013 @05:16PM (#43669043)

    Isn't this just a special case of a honeytoken?

    http://en.wikipedia.org/wiki/Honeytoken

    • by Sloppy (14984)

      Ugh. I hate that idea. It's based on presumption that people have HTML email reading turned on. I wouldn't trigger your canary while snooping through your emails, not because I'm clever or anything, but just because I wouldn't think to turn HTML on. Worse, if I did think to turn on HTML email, I would also have to enable external images, yet another non-default in most IMAP clients.

  • How about a monster whopping database full of salted hashed fake accounts with a tiny percentage of viable logins that notify you when they have been used.

    There.
    • Well, the paper does acknowledge that approach:

      "Sometimes administrators set up fake user accounts (\honeypot accounts"), so that an alarm can be raised when an adversary who has solved for a password for such an account by inverting a hash from a stolen password le then attempts to login. Since there is really no such legitimate user, the adversary's attempt is reliably detected when this occurs."

      The only reason why this approach may not work according to the paper is:

      "However, the adversary may be

  • by Anonymous Coward

    why not have fake logins? Then you don't need a separate list. If someone tries to login with the fake login, then you know there's a problem. A fake login with view-only permissions. True, they might not pick the fake logins...

    But then, what if you had more fake logins than real logins? Then you'd have a better chance they'd pick the fake login.

    Obviously there's some number which balances performance to security that is a sweet spot.

  • This is a good measure for high tech solutions, but why not also take it further. create new honeywords... put them on post it notes under people's keyboards etc...
  • From TFA:
    "The researchers acknowledge that attackers might subvert their system by launching a denial-of-service attack against a honeychecker server. In such an event, they recommend using a failsafe: if a honeychecker server becomes unavailable, temporarily allow honeywords to become valid logins."

    Letting everybody in seems like a weird way to failsafe;-)

    • Well no, it doesn't let everyone in. If you have chosen your honey words carefully, they should be about as secure as the original password was. It would just mean that more than one password could theoretically be used to log in with, and you couldn't use them to detect a breach of your password database for that time. This clearly weakens security a bit, but not by much, and maintains availability of the service (presumably temporarily)

      • Sorry replying to myself - I didn't think that through very clearly - you are right.

        There are only two reasons to mount a denial of service attack against the honey word server. One is pure denial of service to prevent anyone logging in. The other would be if they had already offline compromised the password database and wanted to exploit it.

        I guess you could take a specific DOS on your honey word server as an indication that your password database may have been compromised.

        • by ls671 (1122017)

          Yep, I do not want to troll/bash but just reading that paragraph in TFA made me doubt about the seriousness of those researchers.

          Could be a mistake in TFA or a researcher wrongly cited I don't know...

  • by Tom (822)

    This is one of those small ideas that are so simple and seem so obvious that upon reading them your first thought is "why didn't I think of that?".

As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"

Working...