back to article My bleak tech reality: You can't trust anyone or anything, anymore

Virtually everything we work with on a day-to-day basis is built by someone else. Avoiding insanity requires trusting those who designed, developed and manufactured the instruments of our daily existence. All these other industries we rely on have evolved codes of conduct, regulations, and ultimately laws to ensure minimum …

COMMENTS

This topic is closed for new posts.

Page:

    1. Trevor_Pott Gold badge

      Re: Simple technique to increase cypher strength

      The problem is that brute forcing a password is only actually a requirement for a very small number of passwords in any given list of hashes. Our techniques for cracking password hashes and encryption have evolved so far beyond brute force that mere entropy is not longer a workable measure of password difficulty. Instead, randomness is becoming highly critical; passwords cannot be allowed to match any known pattern.

      1. btrower

        Re: Simple technique to increase cypher strength

        @Trevor_Pott

        Re: "any given list of hashes"

        If I understand you correctly, I agree with this on its own. If it is a known hash algorithm and it is unsalted, like I said in an earlier comment, you effectively have no security at all for most passwords. This technique does not substitute for the rest of the security chain, it just enhances it. That enhancement should be true even against rainbow tables because it increases the length of the password. If you force it all the way to maximum feasibility such that a very powerful machine on the other end is required to spend several minutes determining the entire key, in theory you could use a larger machine to lock out any sufficiently smaller attacker even if they know the nominal key.

        In a realistic scenario, this just ensures that some of the bits, by virtue of never having been stored and never even known by the original key holder, *require* guessing those bits. If it were, for instance, 21 bits missing, requiring on average a million guesses even when you hold the key it would increase the size required of the rainbow table by orders of magnitude. There comes a point beyond which rainbow tables and similar techniques are not practical.

        It is exceedingly difficult to uniformly raise the barriers against a well armed attacker. At the point that you have multiple levels of salts, multiple levels of encryption, etc, this, barring certain types of theoretically efficient attacks, adds bits of strength essentially for free (well, at the cost of back-end CPU cycles). As far as I can tell, there is no way around this type of hardening (assuming non-trivial encryption) because it is essentially an absolutely secure one time pad.

        1. Trevor_Pott Gold badge

          Re: Simple technique to increase cypher strength

          Dan Goodin at Ars Technica has a series of articles on cracking passwords that you really should read. Some of what you say is true. Some of what you say is...out of date. I'd have agreed with you a few years ago, before Hashcat, modern pattern matching, anti-salt techniques and GPU + ASIC mini-supers.

          1. btrower

            Re: Simple technique to increase cypher strength

            I am not certain if we are talking about the same thing. I took a look at some of Dan's articles and tried to find 'anti-salt' techniques. The only reference I could find spoke of attacking the salt by brute force and they only used 4 and 5 byte salts. In an earlier post on this article I mention *megabyte* key values and that includes salts as well. It is true that weak salts are weak, just as weak passwords are weak. However, that does not speak to the strength of strong passwords and competent salts and related techniques.

            What you refer to leads to something that points to the value of the technique I describe. A current variant of hashcat is able to brute force ~2^33 hashes per second on a modern HD7970 GPU. To reduce that effectively to two per second, you add 32 random bits prior to hashing. The addition of 6 6 bit characters will require an additional 2^36 guesses to get a password.

            You could use the base64 characters: b64[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/". Any random function to choose a character from the above will do. Choose six random characters such as:

            13 47 22 60 36 20 = N v W 8 k U

            Add the above to your password and even a fairly large cracking setup will take some time just to crack an unsalted md5 hash of a password.

            Client enters a password into your system, say 'password123'. Your server system generates a random addition as per the above, say 'NvW8kU' and adds it to the password. The password becomes 'NvW8kUpassword123' and that is what you hash. In the case of md5, md5('NvW8kUpassword123')=8f4bb28e2d7e5df5e1b971fbce3007cc. When the client enters in their password ('password123'), the server guesses, like any attacker would have to guess, the first six characters to match against the stored hash.

            In practice, the above would also be coupled with a random salt. Here is a common password that is already found in the rainbow tables at http://crackstation.net/, but salted with a 128 bit salt:

            82730f07b0953fc7555f15bca138f0c6

            Even though the above is an md5 hash of a known password, it is not likely to be guessed any time soon without the salt.

            Here is a vanilla md5 hash of a strong password formed only from letters and numbers:

            d4fffc0f9b56cf324e13534c73228e06

            It is a ten character password, plus the additional six characters as described above. Here is, according to the protocol above, the first six characters of that password: tTQGVj. It would take the computation of approximately 2^59 trials to get the balance of the password from that hash, even though there are only 24 bits of password left.

            The perception that passwords are in danger is a real one. If sites store passwords as vanilla hashes and allow weak passwords then stealing the file of hashes is equivalent to stealing the passwords. Once passwords are in your possession, any that are common to other systems are thereby compromised. My technique will increase the security of your hash file, but it cannot protect against passwords that are already compromised.

            To be honest, as a user I am not fond of systems with stringent password requirements. However, in the absence of additional tokens for security, the only way to ensure security of your system is to enforce a password policy that makes it difficult to use insecure passwords.

            Suggestions: Enforce long passwords > 16 characters. Arbitrarily disallow a random half of the character set. Disallow anything similar to a dictionary word (dictionary word being any known string). This will not protect you against a person re-using their password from your site on another site with less security, but it will protect you against someone reusing a password from a weak site on your site.

            1. Trevor_Pott Gold badge

              Re: Simple technique to increase cypher strength

              In practice, the above would also be coupled with a random salt.

              Except, in reality virtually nobody seems to salt their passwords hashes.

              As for salt cracking, there are at least three good methods I know of:

              1) Crack 2 (or more) passwords by brute force. Find what's the same and take that as salt. Attack rest of hashes.

              2) Sign up for the service and use your known password to attack the hash to determine salt.

              3) Find an e-mail address associated with a password hash that you already know the password to (because you cracked that user's password on another site and we all reuse passwords.) Use the known password to attack the hash and determine salt.

              These are just the ones I know about and I am not a security expert.

              Now, you're correct in that huge key sizes and large character values with password requirements that force the password to be something humans can't remember stands a chance of surviving even a trained hashcat operator with a 50-GPU mini-super sporting 12 ASICs for fun. (Which I am seeing more and more of on the cracking scene these days.)

              That said: A) nobody uses those in reality. B) It still doesn't protect you against US.gov. And again, there are supposedly salt attacks out there I haven't heard of - I'm not cool enough to be in those password cracking clubs, you see - so I wouldn't be so sure about the security of hiding behind large numbers.

              1. btrower

                Re: Simple technique to increase cypher strength

                @Trevor_Pott

                I don't want to make overmuch of the ability to defend against attack because your notion that systems are vulnerable is entirely correct. I would not want readers to infer that password protected systems are secure. They are not secure at all in the current environment. My only point was that adding these extra bits would *help* to harden a system at a very small cost to the defender. It is a very cheap upgrade and in the case of a very powerful defender it could significantly increase the resources required of an attacker.

                You make some excellent points and as salts are currently employed in many systems they *are* vulnerable to such techniques. In fact, systems are vulnerable to many other things as well.

                If salts are properly employed, you can't get to them in the ways you describe. In fact, there should be no simple pathway to the salts. Note the plural there. Cracking the single salt used on your password should have no effect on the rest of the file. In the case of most of the PHP systems I have seen, the weaknesses you describe are real enough.

                One of the things you mention I also mentioned as a vulnerability against which it is impossible to defend. If a password is stored on a compromised system and is also used on your system, then the password can be obviously be used on your system. It is hard to see how a system that accepts credentials can be defended against someone who holds the credentials.

                Although somewhat out of scope for this discussion, let me mention in passing the technique used to defend against this that I employed on a banking system: Users required both their password and possession of a unique, copy protected writeable key. The only practical way to gain possession of the key was to physically steal the key and that key only allowed access to the single account for which it was issued. Communications were encrypted using a proprietary technique provided by a third party. This was back in the day before secure time services were available. To create a barrier against replays, the client system used an additional key provided from the last secure session. Even if the key was somehow copied and the password was compromised, the account would lock the moment the unsynched key was presented. It was not bullet-proof, but with hundreds of users it protected a billion dollar banking system for years until it was retired. It was never breached.

                Although criticisms of cyphers speak to reducing a 128 bit key to effectively a 100 bit key, in practice such a lowering is not fatal because although the wall is radically reduced it is still very high. Attack on such a system is likely to look elsewhere rather than brute force attacks on keys.

                It is exceedingly difficult to defend against a well armed attacker, that much is certain. That is why the technique I suggested is a nice one to add to your toolkit. It can increase the power required of the attacker. Although the equipment you describe would annihilate a 56-bit DES key, it still cannot overcome keys even on the order of 256 bits (much smaller than I recommend for a system you need to be secure). If a network of 10^9 of the systems you describe is capable of brute forcing 10^50 keys a second it would still be unable to brute-force a 256 bit key. Using a technique such as I describe can extend the key easily by 20 or 30 bits or more, making it significantly more difficult to brute force a password.

                The weakness of password protected systems comes back to the human being in charge of assigning and caring for the password. In practice, the majority of passwords are trivial to crack because the mnemonics necessary for human beings to remember passwords create a formula that greatly reduces the effective key space. The cure for this is to ultimately require possession of both a reasonably strong password and some sort of secondary key.

                Good passwords are both easier to create and harder to create than most people think. For the purposes of cracking, the effective bit strength of a password like That!saLLIs4yFo!k5 is significantly lower than (prior to my revealing it here) WLHcgW0sHzo1Popy -- that last is a reasonably true* 90+ bits and (until this note) not at all likely to show up in even the largest set of rainbow tables.

                I am not unaffected by this discussion. Although I am well aware of the weakness of current systems, I confess that I am a little taken by surprise at the change in the balance between attackers and defenders. I expected this to happen, but last I looked, what was a theoretical vulnerability has become a practical vulnerability. Although I was aware of the breaches of large bodies of passwords, I did not realize the extent to which heuristics derived from the exposed passwords had been incorporated into working code.

                My concern has been largely theoretical and directed toward the frustrating intractability of randomness. I actually registered a domain name back in 2001 for the sole purpose of providing reliable third-party randomness as a service. Although still, I think, a long way off, I anticipate that defense against sophisticated techniques of attack against weak random sources can only be warded off by very strong random sources and strong random sources are more difficult to obtain than you would think.

                1. Trevor_Pott Gold badge

                  Re: Simple technique to increase cypher strength

                  I think the idea of a crypto system that relies on randomness and ever-increasingly large primes is fundamentally flawed. It's flawed because the system simply relies on entropy to be safe. "It's harder to brute" means nothing when humans are not nearly so different as they think. There are seven billion of us; there are an incredible number of us who chose the same "unguessable" password, or password patterns.

                  So while some of the techniques you mention do certainly raise the barrier to entry for the crackers, fundementally we need a chance in how we approach crypto. What that approach is, I honestly can't say. I'm not a crypto genius. We need a revolution that is to crypto what general relativity was to newtonian physics. That takes an Einstein. Someone who can think so far out of the box they redefine said box and it's interactions with the universe.

                  Until then, the bad guys will continue to get better and we will continue to be even more vulnerable. Thus my call for "trustworthy by design." Don't assume that ANYONE is trustworthy when you design your application; including yourself or whomever is going to run the application.

                  Do not rely on cryptography alone to secure data.

                  Establish and maintain data custody at all points where the only person(s) with access are those who the creator of said data authorized explicitly. Any hole that a "bad guy" can slip through, a "good guy gone bad" can get through even more easily.

                  1. Charles 9

                    Re: Simple technique to increase cypher strength

                    "Establish and maintain data custody at all points where the only person(s) with access are those who the creator of said data authorized explicitly. Any hole that a "bad guy" can slip through, a "good guy gone bad" can get through even more easily."

                    Which goes to a fundamental and probably intractable problem with data security. In order to be useable, SOMEONE has to have access to the data. As long as someone has access to the data, someone can impersonate them. Given enough resources, Mallory can be indistinguishable from Alice no matter the level of security you apply. Even physical security isn't foolproof: stolen devices and rubber hoses come to mind.

  1. Robert Helpmann??
    Childcatcher

    2nd Factor?

    There are 2 factor authentication alternatives to the described in the article, especially for corporate and government customers. For example, a common access card setup would force users to have the token, but does not by iteslf change the length of the password needed to access a system.

    The current trend for consumers is to push everything onto the smart phone, which is arguably a flaw in implementation... or perhaps a strength. Either way, as Mr Pott rightly noted, it represents security that users will find onerous. Because of this, there should be no real push to use these except for the most important of sites and transactions. While I would find mandatory use of 2FA an expectation for my banking site, I would be less impressed to require it for FaceBook, where I presume everything is public knowledge. Yes, the account is more vulnerable to being hijacked by this logic. So what? How does that compare to keeping my medical records secure.

    Adequate security depends on the data and function being protected, which is where I think a lot of sites go off the rails when setting up requirements of their customers. Sure, give them the option for something more, but unless it is really easy to use, the expectation should be "password" as the default. There always will be a balance between expectations and implementation.

  2. Anonymous Coward
    Anonymous Coward

    the off-line solution

    I have one password file (itself password protected), and it lives on my Psion Revo, which always comes with me, and which is not online.

    I back up the Revo to an old PC, also offline, and backups of that PC go to a second location.

    I change all my passwords every couple of years.

    I know it's not perfect but I'll take it over trusting online technology.

    When that day comes that we wake up and half the world's computers just say "zero" - an act of terrorism that could bring down entire societies - and that day may very well be coming, thanks to the Cloud, and the lack of thought in our technology that the article mentions - us 'Luddites' might just have a small chance. (And if so, we'll try to buy all the baked beans, then head for the hills.)

    1. Trevor_Pott Gold badge

      Re: the off-line solution

      How's that any different from two-factor authentication in terms of time required to execute? All the while being even less secure? As discussed in the article, 30 seconds-ish per login mounts up...

    2. Charles 9

      Re: the off-line solution

      When THAT day comes, not even your Revo will be safe because the act of terrorism will come through the AIR: think an EMP from an airborne atomic/nuclear explosion. Not even offline devices will be wholly safe from them.

      Plus there's always the risk of you getting mugged and the mugger nicking off your Revo WHILE you were using it (meaning the master password isn't needed, and they can nick everything else off before it has a chance to lock itself).

  3. ecofeco Silver badge
    Pirate

    EULA

    That's how we got here.

    "We don't care if our software breaks your PC and looses your data. Tough shit for you. Oh, and you don't own this either, like a say a book."

  4. bag o' spanners
    Devil

    I'm terminally paranoid about my passwords, because I value my privacy. So I don't store useful pws on a web enabled machine, and certainly not on a US based cloud.. The few that have real value sit safely in my noggin, and are seared into my neuronet by mnemonics that take absurdity to the limit.

    I've seen how lax security is on the wider web, so I don't have much faith in organisations who are barely one sniff away from being hacked. I'd include most public sector organisations and large banks in that particular Venn circle.

    If your clients are desperate to be cloudy, then they should be made fully aware of the risks involved, and the true cost of rock-solid security. Cheapskating on thin ice usually ends in tears, but it doesn't seem to deter the cheapskates.

  5. Allan George Dyer
    Boffin

    Anyone for PKI?

    FTW

  6. Tree
    WTF?

    I trust Gurgle and after that Bong (Cold mail, Dead mail, or InLOOK, or whatever)

    The above huge companies must be trusted not to track you or store your private secrets, right?

  7. Adam 1

    "easy to remember (and thus easy to crack) passwords"

    You could staple a horse battery to the amount of incorrect in the above quote.

    An easy to remember password doesn't need to be easy to crack. And I have seen plenty of "good" passwords which would take minutes to crack.

  8. Anonymous Coward
    Anonymous Coward

    Excellent article Trevor

    ...which has stimulated some very interesting discussion.

    Thanks!

  9. All names Taken
    Paris Hilton

    So? What's new?

    And I suppose we should add to the list:

    banks

    pension companies

    investors

    politicians

    police (ok, I accept perped up bobbies are rare but they exist)

    civil servants (heard any of that morality diatribe of late? Wonder why?)

    The above is not exhaustive nor is it meant to be. I just got disinterested with the way it was going and general negativity as it seemed to be becoming.

    Maybe the only angle is: trust those organisations you have formal trust agreements with but expect some in those organisations to be more than lackadaisical (or less if that makes better sense no?)

  10. Jim 59

    Don't say password, say passphrase

    A phrase is much harder to crack, and much easier to remember. Regarding password storage, I would never, ever put my password database on the cloud or give it to anyone else. Lastpass ? No thanks.

  11. Brangdon

    DropBox?

    What's wrong with using an open-source offline password manager (such as KeePass) with the password database protected with a long pass-phrase, plus a file synchronisation service (such as DropBox) to replicate it across all the devices you need it on?

    You can verify that KeePass never talks to the network, and DropBox never sees unencrypted passwords. The worst that DropBox can do is give your encrypted database to the Feds, but if you have used a long enough pass-phrase they won't be able to break it. One long pass-phrase is easier to remember than dozens of shorter ones.

    1. jkilgore
      Stop

      Re: DropBox?

      Careful with passphrases. Some issues are

      -Re-using known phrases (even partially) from books, politicians and so on is very insecure, as they can and will be iterated through by the government and the porkstars. For 15k Euro you can get a 32 Core machine with 128Gbyte RAM these days. This machine can already try all phrases out of all popular books in a matter of minutes.

      - Effective Entropy: You only get about 0.1 to 0.3 bit of "entropy" per character of your passphrase, if your opponent is some major government or a criminal top gun coder from Google or the like. It's easy to see why if you consider the English language: It has about 1 million words. That means you get at max about 20 bit per word. Those 20 bits are dramatically worn down by the fact that some words are much more likely than others (e.g. "tank" is much more likely than "haberdasher"). Then there is grammar, which further reduces the bits left: An easy-to-remember passphrase is more or less grammatically correct. So they don't have to iterate through "must can have like green", but only through sentences like "likes to eat green mice".

      So your passphrase should be very, very long and strange.

      More like "when I wander through the forest, looking at my marble shoes and singing a nice tune, I always think about unicorns farting yellow farts. This makes me love my creator, the glorious flying spahettimonster and his father, the yellow squirrel. We and the whole world descend from the yellow squirrel".

      -Don't use anything as a passphrase which can be derived from your person. The government will certainly pull all the data about you in order to build prospective passphrases. So if you are a hairdresser by profession, never use hairdresser words/expressions in your passphrase. Certainly don't use names of your relatives, friends, colleagues, birthday and so on.

      In short, an MD5 derived from a file full of your own gibberish (made by you hacking 500 times randomly on the keyboard) is probably much more secure and easy to use. Write it down on a piece of paper and carry that somewhere at your body. Don't write anything else on that piece of paper. Eat the paper when in danger of being apprehended. There's even special paper for that purpose. Have a copy of that in an airtight bottle buried in the ground at a place only you know. Cola bottles are excellent for that purpose. Can also be used for securely storing encrypted USB sticks.

    2. Charles 9

      Re: DropBox?

      That's actually the exact technique I use. I also don't put the key in the Public folder but instead put it in a dedicated directory which I sync using tools like DropSync, so the actual existence of the database isn't known to all and sundry. And since KeePass has an Android client, I can still access stuff from my mobile if the need arises.

  12. hugo tyson
    Coat

    7-layered...

    Just: love the extension to the ISO 7-layer model. For years in pub talk, we have used the extensions "Layer 8 - Political" and "Layer 9 - Financial" to explain otherwise incomprehensible phenomena, I mean when less-capable implementations win, when laws intended to do one thing rather outlaw everything else, and so on. Government and big business madness in general.....

  13. jkilgore
    Stop

    Commercial Password Security Issues/Insanity

    Major, stupid problems of password security are:

    -Password hashes are not stored in a dedicated system. A single SQL injection in a web shop will open the entire database. That's because the commercial world is full of lazy thinking and lazy people.

    -Passwords can often be brute-forced, as the "checking rate" is not properly controlled. In the Banking world, they lock your PIN after three failed attempts and that makes four-decimal PINs quite secure. Why can't we have something like this or Exponentially Growing Timeouts in the average commercial system ? Yeah, because the commercial world is full of lazy and corrupt thinking. Security is not a "selling point".

    -Highly insecure "password unlocking" features such as "mother's maiden name" and similar insane nonsense. Apparently they got all the big idiots from Obama to the Alaskan whackjob by exploiting that.

    If the commercial world used a dedicated, open-source "password/user" store/Linux distro on a dedicated machine, everything would be much more secure. The FOSS world could focus on getting that single system properly done and stripped down to the basic functionality. Instead everybody does a half-baked system in PHP and stores the hashes along with the application tables. Commercial thinking, again.

  14. Philip Lewis
    Thumb Up

    Obligatory XKCD reference

    http://xkcd.com/936/

    That being said, this was an exellent article and a most excellent discussion thus far. It seems articles, and importantly discussions, like this have become a rarity on The Register, and that is rather more than unfortunate.

  15. Pseu Donyme

    Exceptionally worthy article, quality discussion.

  16. Jin

    Why not try to expand the password memory capcity?

    At the bottom of all these headaches is a simple fact that humans cannot firmly remember any more than 5 passwords on average so long as we stick to numbers and texts. But it is not impossible to expand the password memory capacity. One such proposition can be found at

    http://mneme.blog.eonet.jp/default/files/expanded_password_system.pdf

    1. Charles 9

      Re: Why not try to expand the password memory capcity?

      Why not? For the same reason you can't make something foolproof: eventually the world will produce a better fool. While it's not impossible to expand the human memory capacity to an extent, there are usually limitations that are not well known to the system designers. What if one has a bad memory for faces? For images? For spelling?

  17. Trevor_Pott Gold badge

    For those who feel I am too paranoid

    Please, read this.

    1. btrower

      Re: For those who feel I am too paranoid

      @Trevor_Pott:

      Excellent comment.

      If anything, Schneier is soft-pedaling the danger. The U.S. government is a monstrous adversary already. It is (illegally by any sensible definition) killing people by remote control. It needs significantly less ability to interfere with people, not more. The best way to ensure the continued well being of thee and me is to push wealth and power down closer to the people. The State and Corporations should live in mortal fear of citizens pulling the plug. We should punish non-human entities by dissolution when they transgress. North Americans have been putting up with increasingly outrageous threats by the FBI every time they watch a video. We need to put an aversion to threatening citizens deep into the DNA of the State. Even asking for what they want should result in their destruction and replacement as an organization.

      1. Charles 9

        Re: For those who feel I am too paranoid

        But if you replace the government, what do you replace it WITH? Ever heard of the phrase out of the frying pan and into the fire? ANY government made by man will eventually be corrupted by the necessary human element. The only other type of government where the human element is minimized is the rule of absolute law: where the law dictates terms with no exceptions. We're not comfortable with that, either, because we're aware of the concept of mitigating circumstances.

  18. SDoradus
    Black Helicopters

    The PDF you link to (by David Cole) showing how contentious is the citizen vs immigrant rights debate is a wonderful bit of lawyering. Spot the straw man:

    "... in regulating immigration, "Congress regularly makes rules that would be unacceptable if applied to citizens." Yet fifty years earlier, the Court had stated that the Due Process Clause does not "acknowledge any distinction between citizens and resident aliens."

    The due process clause of the US Constitution covers "persons", not just natural persons but also legal persons (like corporations), who can benefit from constitutional guarantees. However, the constitution can't cover everyone in the world.

    In particular, due process benefits persons who are citizens or residents or US corporations, more than strangers within the gates - people not bound by US Law. That's why courts can declare 'due process" might well discriminate against NON-resident aliens. The rules for regulating immigration are applied to non-citizens and persons not YET resident.

  19. Miek
    Linux

    "This means that in the real world the system-local password manager is completely useless. If I am going to generate some uncrackable, randomly generated password string and store it in my password manager, then I need to get at that password from any device I use. This means I need a centrally accessible password store. Once more, this bifurcates my options." -- Use Keepassx. Place your Keepassx DB onto a cloud storage platform, such as, Dropbox. Then install Keepassx and dropbox on your phone and other computers. You then have a "local" password database that is shared over cloud infrastructure.

    1. Trevor_Pott Gold badge

      So they go to Dropbox, get the file, crack the encryption and pull out all my passwords. This helps me how?

      The key to that encryption (the master password) still has to be something a human can remember, which means it is vulnerable to a yottabyte datacenter run by evil men.

      1. Charles 9

        Perhaps, but it's easier for a human to remember ONE big password than 100 of them, so the master password can be as long and complicated as their memory can dare it. Which starts putting a strain on the yottabyte datacenter, which still has two intractable physical limitations: limited time and limited resources. And there are some things even a quantum computer can't readily speed up (such as lattice- or error-correcting-code-based encryption).

Page:

This topic is closed for new posts.

Other stories you might like