< PREV | NEXT > | INDEX | SITEMAP | GOOGLE | LINKS | UPDATES | BLOG | EMAIL | $Donate? | HOME

[11.0] Contemporary Cryptology

v2.4.0 / chapter 11 of 13 / 01 sep 16 / greg goebel

* Cryptologic techniques such as block ciphers and public-key cryptosystems are now in common use on the internet, and new ciphers are being introduced to ensure even greater security. This chapter discusses the current state of cryptologic technology.


[11.1] MESSAGE AUTHENTICATION & DIGITAL SIGNATURES
[11.2] PHIL ZIMMERMANN AND PGP
[11.3] INTERNET CRYPTOGRAPHY: SSL & IPSEC
[11.4] GNUPG / ELLIPTIC-CURVE CIPHERS / AES
[11.5] DIGITAL STEGANOGRAPHY
[11.6] FOOTNOTE: RKE SYSTEMS, SMART CARDS, & PASSWORDS

[11.1] MESSAGE AUTHENTICATION & DIGITAL SIGNATURES

* The Diffie-Hellman algorithm and public-key cryptography were big steps forward in providing security for the emerging internet, but a few other pieces were required as well. One of the internet's many security problems is the fact that forging an email message is very easy. For example, a professor at a university was the target of a malicious prank in which a message containing racist comments was broadcast using his address, causing the professor a great deal of trouble. With public-key cryptography, anyone can use Bob's public key to send him a message, and if the return email of the address of the message has been faked, Bob can be easily fooled into accepting a forgery.

This means that one of the important elements of a useful cryptosystem is "message authentication", or ensuring that Bob can receive a message from Alice and actually be certain it is from Alice. Related to the concept of message authentication are the other concepts of "data integrity", or ensuring that the data in the message has not been tampered with, or corrupted by a transmission error; and "non-repudiation", or ensuring that if Alice sends a contract to Bob, she can't later claim that it was a fabrication and disown it.

Diffie and Hellman devised an elegant little trick that allows public key cryptography to authenticate a message. This trick is based on the fact that RSA, and apparently other public key ciphers, has an interesting symmetry. Normally, in RSA, a message is encrypted with a public key and can only be decrypted with the corresponding private key. Anyone can encrypt a message with the public key, but only one person can decrypt it using the secret private key. The flow of the encryption is "many to one".

It turns out that the reverse is also true: a message can be encrypted with a private key, and can only be decrypted with the corresponding public key. This sort of "inside-out encryption", to give it a name, might seem silly, since then anybody can use the public key to read the message: the flow of the encryption is "one to many". Inside-out encryption provides no security, but the symmetry also holds in that the public key can only decrypt messages encrypted with the secret private key. This means that Alice can perform inside-out encryption using her private key on a message and send it to Bob. Bob then uses her public key to decrypt the message. Since Alice's public key will only decrypt a message that was encrypted with her unknown private key, as long as Bob is certain he has Alice's proper public key, he is just as certain that the message came from Alice.

Encrypting with a private key is more formally known as "signing", and decrypting with a public key is more formally known as "verifying". RSA can of course be used for this kind of authentication, but in the early 1990s NIST also approved a standard "Digital Signature Algorithm (DSA)". DSA can't be used, at least not very practically, for encryption as such, and instead of generating a readable plaintext, it simply provides a YES or NO on whether the message is valid or not.

* One thing to remember is that anyone can read an inside-out encrypted message. All they have to do is get Alice's public key. When this is a problem, the solution is simple: perform inside-out encryption on a message that's encrypted to begin with. Even if someone intercepts Alice's message and opens it up using her public key, all they'll get is a message they can't read. In detail:

The first decryption guarantees that Alice sent the message, the second gives the actual contents of the message.

However, this approach leads to another problem: performing two levels of public key encryption is very time-consuming. As noted, for this reason public key cryptography is generally only used to encipher a key for a block-ciphered message. Similarly, in practice, instead of using this inside-out encryption scheme to validate entire messages, Bob can create a short "fingerprint" of the message called a "hash", or sometimes a "message digest", characteristic of the message, and send the hash to Alice separately using inside-out encryption.

A "hash" is a relatively short string of bits, usually 160 bits long, that results from running the full message through a "hashing" algorithm. Such hashing algorithms are designed to produce a value that is unique for each different message run through the algorithm, or in other words the probability of two different messages resulting in the same hash must be extremely low. Furthermore, even a single minor change in the message must result in a distinctively different hash. Of course, hashes are one-way: there's no way to reconstruct the original message from the hash, any more than a sausage can be turned back into a pig.

There are a number of hash functions used in cryptology, with names like "RIPEMD-160", "MD5 (Message Digest, and "SHA (Secure Hash Algorithm)". SHA is something of an industry standard, having been through several iterations, including "SHA-1", "SHA-2", and the current rethought version, "SHA-3" AKA "Keccak".

A hash can be sent by itself, but of course there's no way to validate who it came from if it is. To authenticate his message, Bob first makes a hash of it using one of these functions, performs inside-out encryption on the hash with his private key, and then sends the encrypted hash on to Alice. This encrypted hash is actually formally known as a "message authentication code (MAC)".

When Alice receives the MAC, she decodes it with Bob's public key. After separately decrypting Bob's full message, she runs the plaintext through the same hashing function used by Bob, and compares the hash generated with the hash she has received. If they match, Alice knows the message was sent by Bob and has not been tampered with.

* There is one more problem, a big one, with Alice using inside-out encryption to establish a digital signature for her messages to Bob. It implies that Bob really does have Alice's public key. Suppose Eve manages to insinuate herself as a secret "middleman" into correspondence between Bob and Alice, intercepting messages from both and then passing them on. Eve can feed her public key to both Bob and Alice, decrypt their messages, then re-encrypt them with Bob's or Alice's public keys as required and pass them on without being detected.

This means that there must be a way of guaranteeing that public keys belong who they are supposed to belong to, or in more formal terms to "validate" the public keys. Organizations known as "certification authorities (CA)" have been established to validate public keys. This service could be provided by a non-profit, commercial, or even governmental organization. The certification authority does not have private keys and so cannot read communications from those it certifies.

Certification is established using "digital certificates" or "certs", which consist of a public key, data on the owner of the public key, an expiration date on the certification, and one or more digital signatures associated with the certification authority. There are a number of different digital certificate specifications, such as the "X.509" standard format, devised by the International Telecommunications Union (ITU). Public key cryptography users can submit their certs to a public database known as a "certification server", allowing them to trade public keys with some degree of security, or a certification authority can provide a "public key infrastructure (PKI)" system, with additional levels of security to ensure that the public keys are valid.

BACK_TO_TOP

[11.2] PHIL ZIMMERMANN AND PGP

* Block ciphers and RSA provided the tools needed for security on the internet, but it wasn't until the early 1990s that they became a technology accessible to all, through the work of a crypto hack named Phil Zimmermann. In the late 1980s, Zimmermann came up with a cryptographic software package named "Pretty Good Privacy (PGP)" that he wanted to make available to the masses on the internet.

PGP incorporated the key exchange capabilities of RSA with the powerful encryption capabilities of modern block ciphers. As noted earlier, RSA is too computation-intensive to be useful for enciphering long messages and is also relatively weak, and so it is normally only used to send a block cipher key used to encipher the body of the message. Zimmermann decided to use RSA to encipher a randomly-generated one-time "session key", and encipher the body of the message using the session key with a block cipher, by default the IDEA cipher, though alternative ciphers could be used. PGP took care of all the details.

PGP also offered several other convenient features. For example, it could be used to generate the values for a public key and a private key. The user simply wiggled the mouse around, and RSA used the motions as a random seed to help generate large prime number values highly likely to be unique. Another feature provided by PGP was message authentication, using the Diffie-Hellman technique. PGP could use X.509 digital signatures, but it had its own format for digital signatures as well.

* Zimmermann was ready to go with PGP in 1991, but he was confronted with two legal obstacles. First, the RSA algorithm was patented and controlled by RSA Data Security Incorporated. Second, in 1991 the US Senate had passed an omnibus anti-crime bill, with a clause essentially banning encryption schemes that the government could not crack. This clause had been dropped after protests by civil liberties groups and businesses, including RSA Data Security, but nobody felt that the issue had gone away.

Zimmermann was an activist and looked forward to this sort of confrontation as an exercise in principles. In 1991 he had a friend post PGP to an internet message board site, and after a slow start it began to take off. As PGP caught on, Zimmermann began to attract controversy. He had been hoping to obtain a free license for RSA from RSA Data Security, but the company turned him down and began patent infringement actions against him. RSA Data Security officials branded PGP "Pretty Good Piracy". More significantly, in early 1993, the US government began to investigate him on charges of illegally exporting a "munition", which was how the government classified encryption software.

The legal quarrel went on for over three years. The government abandoned the case against Zimmermann in 1996, out of recognition that the cat was out of the bag and the case against Zimmermann was so controversial that putting him on trial would have been a fiasco, with little likelihood of obtaining a conviction. Zimmermann then came to an understanding with RSA Data Systems over the licensing of RSA. His legal troubles were over. He sold PGP to a company named Network Associates, which he also became affiliated with, but PGP still remains freeware for individual users on the internet, at "www.pgpi.com".

BACK_TO_TOP

[11.3] INTERNET CRYPTOGRAPHY: SSL & IPSEC

* The pioneers of public-key cryptography like Whitfield Diffie have been proven right, even conservative, in the use of cryptographic technologies on the internet. For one particularly important example, most people who surf the internet to make online purchases have used cryptography to provide their credit-card numbers to vendors, using the "Secure Sockets Layer (SSL)" protocol. Pages protected by SSL are designated with an "https" prefix instead of the conventional "http" prefix.

SSL was invented by Netscape in 1994. It was adopted by the internet Engineering Task Force's Transport Layer Security (TLS) committee as the basis for a standard in 1996, and the slightly mildly modified variant of SSL that was released by the committee is known by the committee's acronym, "TLS". However, the acronym "SSL" is used in this document. Incidentally, Microsoft tried to push a competing security scheme designated "Private Communication Technology (PCT)", but it didn't catch on. Microsoft ended up adopting SSL.

SSL works more or less transparently to the user, and uses both public-key and symmetric ciphers. Supposed Alice wants to make a purchase from an online vendor and needs to give the vendor her credit-card number. After establishing the vendor's identity using a digital certificate, her web browser will download the vendor's public key and use it to encrypt a secret symmetrical key produced automatically at (more or less) random by the Web browser. The Web browser will pass the encrypted secret key to the vendor, and this secret key will be used to encrypt the session. Incidentally, web browsers set up a table of certs from prominent business concerns when they are installed.

Actually, several secret keys are exchanged, but a detailed discussion of the complexities is a bit beyond the scope of this document. Incidentally, the SSL protocol doesn't try to validate who Alice really is, at least not by default, since obtaining valid digital certificates for typical online customers is not very practical at present. In some critical transactions, a digital certificate may be requested of the purchaser.

A range of ciphers, with options for different key lengths, are available on web browsers to support SSL. Even with short keys, the security provided by the cipher is adequate for most purposes. The amount of horsepower required is expensive enough to ensure that nobody would bother to do this to crack credit-card transactions -- they could be using the computing power to make more money by legitimate means. However, web browsers are very vulnerable to attack by malicious software, "malware", that exploits browser design errors.

* Another invisible use of cryptography on the internet is in "virtual private networks (VPNs)". As the name implies, a VPN is a private network that can only be accessed by a specified group of users, but still operates on the public internet. Online security is maintained by IPSec technologies, giving it effective or "virtual" privacy.

VPNs are usually implemented using a scheme different from SSL, known as "Internet Protocol Security (IPSec)" protocols, though the general idea is the same: use public keys to transfer symmetric keys, and then conduct the session using a symmetric cipher. One of the major differences of IPSec from SSL is that SSL is designed to perform secure transactions between a web server and a web user or client, while IPSec performs "peer-to-peer" transactions between multiple, more or less equivalent and effectively similar, nodes on a network.

Popular "wi-fi" wireless networks are protected against intrusion by similar schemes, the most popular being "Wi-Fi Protected Access (WPA)", which led to the refined "WPA2". Under WPA, each computer to be hooked into a network has to be configured with the desired protocol along with a key. Password schemes are also available to restrict access to a wi-fi network except to users who have been approved.

BACK_TO_TOP

[11.4] GNUPG / ELLIPTIC-CURVE CIPHERS / AES

* The widespread use of cryptographic techniques and the availability of ever-increasing computing horsepower has led to greater pressure to come up with new and improved encryption systems.

The GNU open-software foundation has developed a "replacement" for PGP known as "GNU Privacy Guard (GNUPG)" is not only publicly available for free, but also does not use either the IDEA block cipher or the RSA algorithm, ensuring freedom from intellectual-property challenges. The first release of GNUPG was in 1999; the current version can be obtained from "www.gnupg.org".

* Since RSA is computation-intensive, it is slow and cumbersome for use on handheld computing devices with limited computing horsepower. New public-key cryptography software based on a class of one-way operations known as "elliptic curve" functions has been developed, where an elliptic curve function is of the form:

   Y^2  +  k1 * X * Y  +  k2 * Y   =  X^3  +  k3 * X^2  +  k4 * X  +  k5

-- where "k1" through "k5" are constant values. For elliptic curve cryptography (ECC), this general form of an elliptic curve function is simplified and modified to:

   Y^2 MOD P  =  (X^3  +  k1 * X  +  k2) MOD P

Without getting into details, this is another algorithm for generating cryptographic keys that are difficult to backtrack, and it can be used to generate schemes along the lines of Diffie-Hellman key exchange and RSA. ECC has two advantages over RSA:

* One of the most significant innovations in contemporary cryptography is the development of a replacement for DES. DES was a worldwide standard for encryption for over two decades, but by the end of the century it was clearly running out of steam. New techniques for cracking ciphers were developed, such as "differential cryptanalysis". This is a technique where slightly different plaintexts are enciphered and then the ciphertexts are compared. Differential cryptanalysis can reduce the length of a brute-force search to crack a DES message by a factor of over a thousand.

In 1999, a group of volunteers running a volunteer network of 100,000 personal computers over the internet managed to crack a DES-encrypted message in less than a day. The network was controlled by a software system that assigned each of the PCs a block of possible keys to check, with a PC reporting back after the check to indicate if a match had been found. DES users began to use "triple DES", which involved encrypting a message with DES three times, using 56-bit keys. In principle, triple DES uses three 56-bit keys, but in practice some implementations use only two 56-bit keys, with the same key used for the first and third cycles of encryption.

Well before this, in 1997, NIST realized that DES was close to outliving its usefulness and began an evaluation to select a new cipher, the "Advanced Encryption Standard (AES)". Five finalists were selected and examined for weaknesses. All these candidates were regarded as similar in capability and acceptable, but the winner was a block cipher named "Rijndael", pronounced roughly as "raindoll",

Rijndael was developed by two Belgian cryptographers, Vincent Rijmen and Joan Daemen (a guy, by the way), and was derived from an earlier block cipher named "Square". Rijndael can use blocks and keys with a length of 128, 192, or 256 bits, arranged in any combination for a total of nine possible arrangements of key and block size. The cipher can be easily extended to blocks or keys with lengths in larger multiples of 32 bits. Interestingly, Rijmen and Daemen have made little or no money directly off the adoption of their cipher as a standard. However, the prestige and publicity associated with the award was considerable, and AES is now a big business, with commercial users appreciating the security it offers.

* It should be noted that, though AES with a 256-bit key is seen as satisfactory for commercial and many government purposes, it is not seen as good enough for the most secure government entities, for example the president of the United States. While a "smartphone" using AES with 256-bit keys is highly secure, its not secure enough for the president, who instead carries a specialized ultra-secure smartphone. The problem is not AES, which can do the job, it's the smartphone; commercial smartphones are known to suffer from operating system "holes" that can be exploited by hackers.

The presidential smartphone uses a highly secure voice scrambling scheme known as the "Secure Communications Interoperability Protocol (SCIP)". SCIP is not extremely robust, but distribution of SCIP phones is tightly controlled. For data messages, it uses the NSA "Type 1 Suite B" algorithm, whose details are secret. The presidential smartphone is designed to access the "Secret Internet Protocol Network (SIPRNet)", a top-security network limited to a few hundred thousand people; it can also access the "Nonclassified Internet Protocol Network (NIPRNet)", the government "sensitive but unclassified" network, as well as public networks. Incidentally, by law all presidential calls have to be logged, and all email messages stored and available under subpoena.

BACK_TO_TOP

[11.5] DIGITAL STEGANOGRAPHY

* While the internet has led to aggressive development of the new ciphers, it has also led to a revival of the ancient art of steganography, or hiding data.

Audio and image files tend to be large, and so they make convenient hosts for hidden data. Audio files consist of sequences of digital sound samples that give the value of the audio waveform taken at successive short intervals. For example, standard CD-quality audio consists of 16-bit samples taken at a rate of 44,100 times a second. Data can be hidden in the least significant bit of each sound sample of an audio file. The modification amounts to no more than adding a very slight amount of noise to the file, so slight that nobody could tell the difference between the original and modified files on listening to them (though fanatical audiophiles would no doubt claim they could).

Similarly, a typical image file consists of a grid of color dots, or "pixels", with the color of each pixel defined by three 8-bit values, giving the levels of red, green, and blue in the color. Data can be hidden in the least-significant bit of each of these values, and if the image is a color photograph or other image without large uniform blocks of color, the hidden data cannot be detected simply by looking at the image.

The advantage of steganography is that messages can be distributed without the authorities being aware that they are being sent. There is no reason the data could not be encrypted as well before being hidden. A number of steganography packages are now available for popular use.

Of course, there is a limitation to digital steganography in that "lossy" data compression schemes, which throw away components of the audio or image data to permit a more compact file, cannot be used since they are almost certain to throw away the hidden data. Lossy audio compression schemes such as MP3 or WMA, and lossy image compression schemes such as JPEG, are not appropriate for steganography; non-lossy WAV audio files or PNG image files are much better suited to the job.

It is suspected that criminals and international terrorist organizations find steganography using image files a particularly useful way to communicate secret information. One of the problems with any internet communications from a terrorist's point of view is that they are generally from a specific sender to a specific recipient, allowing security organizations to trace links in the terrorist organization. This problem can be avoided by including secret information in pornographic images, which are then uploaded to a pornographic web site, preferably one with a large amount of traffic. This allows the recipients to hide their pickup of the message in a flood of other traffic to the website.

New digital steganography techniques continue to be developed. One scheme is based on "voice internet protocol", the scheme in which phone conversations are digitized and then sent as sets of packets over the internet. Since conversations have moments of silence, some of the packets will be empty, with these packets being shorter than packets containing voice data. The empty packets can be used to discreetly transfer data. It is possible to transfer data at rates of up to two kilobits a second by this means, adequate for handling text data, and the trick is difficult to detect.

BACK_TO_TOP

[11.6] FOOTNOTE: RKE SYSTEMS, SMART CARDS, & PASSWORDS

* Cryptographic systems are also in widespread use outside of the internet, in the form of "remote key entry (RKE)" systems, sometimes also known as "remote keyless entry" systems. RKE systems have been around for decades in the form of garage-door openers, but the technology has been refined and is now in more widespread use, particularly in the form of RKE systems for high-end cars.

The old garage-door openers are still around, but they provide convenience, not security. The remote and receiver units could be set to unique 8-bit codes using mechanical switches, but that was mainly to eliminate interference between neighbors who both had remotes. Modern automotive RKE systems use a much longer code sequence that changes between uses. If a keychain RKE unit always sent the same or a predictable access code, a potential intruder could simply record its transmission using a radio scanner and play it back later to gain access.

Cheap integrated circuits are now available that provide improved security by generating binary code sequences of 40 bits or so. The simplest such security scheme is the "rolling code" algorithm, basically a form of pseudo-random number generator, which is used with one-way RKE units that can send a code but cannot pick up an acknowledgement from the receiver.

In the rolling code scheme, both the RKE unit the receiver are set to an initial code seed and "rolling algorithm". Every time the key sends an access code to the receiver, both update the code identically according to the rolling algorithm. The initial code seed ensures that the rolling code sequences are effectively unique to a particular RKE system, and the sequences are designed so that it is difficult to backtrack through the values and find the seed. Since the receiver will not always pick up the RKE unit's radio signal, the receiver can "look ahead" 256 codes and still unlock the automobile.

This leads to a problem if the number of unreceived RKE transactions exceeds 256, or somewhat more plausibly the RKE unit is lost or broken. For this reason, automobiles with RKE systems have a "reset" capability. The owner gets in the car using the old-fashioned mechanical key, follows the reset initialization procedure -- say, turning the ignition on and off eight times in less than ten seconds -- and then pushes the button on the RKE unit. The receiver then syncs up to the RKE unit.

Two-way systems offer better security at higher cost. The RKE unit transmits an access code; the receiver reads the code and replies; the RKE unit acknowledges in turn; and the receiver then unlocks the doors. This means that both the RKE unit and the receiver can increment their rolling codes in step, eliminating the need for look-ahead. Incidentally, many RKE units can perform multiple functions, such as unlocking the doors or the trunk. This is done by sending a function code along with the security code.

* Another cryptographic technology now catching on in the USA -- it's well-established elsewhere -- is the "smart card". Due to inertia of banks and retailers, Americans held on to the old magnetic-strip or "magstripe" credit and debit cards, though their security was minimal, the only real protection available being a "personal identification number (PIN)" that the user would provide on use of the card. Card data could be easily copied using a "card skimmer" reading device, with scammers ingenious enough to even attach camouflaged skimmers to the front of gas pumps or automatic teller machines.

A smart card has the same form-factor as a traditional credit / debit card, but it contains a processor and nonvolatile memory. It does not have a battery, however; the processor is powered when the card is accessed by a reader, either through an 8-pin electrical contact that also provides data in and data out, or through an induction antenna that also supports close-range or "near-field" data communications. Some smart cards have both interfaces to allow them to be used by different readers.

A user initializes the smart card with personal data before use, with the personal data encrypted to make it difficult to read back out again for creating a copy of the card. There's an elaborate set of security protocols for the smart card, the most significant being that a smart card provides a signature value with each transaction. Each smart card provides a unique series of signatures distinctive to that card; using public-key cryptography, a reader can validate the signature, but cannot determine how the signature is constructed. Even if a scammer records a transaction, its signature will not allow it to be used for a second transaction.

The magstrip card held on in the USA simply because vendors had invested in magstrip card readers, and didn't want to go through the -- admittedly considerable -- trouble of converting to smart-card readers. The US charge-card companies forced the issue in 2015, by telling vendors that they would have to eat future rip-offs from magstrip cards, giving them a financial incentive to upgrade. The upgrading is currently in progress, with the expectation that it will take several years to generally complete.

Online transactions generally do not interrogate a smart card; if a user has set up an online account with a charge-card number, it's not convenient for all concerned to insist on smart-card validation for every purchase. In that case, the user stores the charge-card number and validation codes in the user account, and the system is no more secure than the old magstrip cards. However, charge-card software has become ever more intelligent and able to detect when an unusual purchase is made via an online account -- with the user sent an email to ask for validation of the purchase.

* One last item related to popular use of cryptography is the pervasive computer password, used to authenticate entry to online accounts. There was an inclination in the past to push users to create very elaborate passwords, consisting of unpredictable patterns of letters and digits -- but that's fading out since such passwords were difficult to remember, meaning users had a tendency to either forget them, resulting is wasted time establishing a new password, or write them down, making the passwords insecure. Besides, when hackers do get into accounts, it's rarely because they were able to guess the password; it's because they stole the passwords through some inside job or using key-logging malware.

Even a brute-force search is easily defeated by a reasonably designed password. Login systems now use "login throttling", ensuring that if a login fails, the login system waits a few seconds before asking the user to try again. That slows a brute-force search down to a crawl. A second level of defense, not much more complicated than the first, is to recognize large numbers of consecutive attempts to log in, obviously indicating someone trying to break in, and take appropriate security measures.

Suppose we created a 12-character password using upper and lower case letters plus numeric digits; that would mean a brute-force search would have to test for 62^12 == 3.2E21 possibilities. Try to crunch through all of them at a rate throttled to once a second, it will take far longer than the age of the Universe.

Now suppose we have a password created from four words out of a list of 250 words arranged in different orders; then we have about 250^4 == 3.9E9 possibilities. Obviously, the first password is much stronger, but it would still take over 120 years to try all the possibilities for the second password, and the login system would get wise after only a relatively small number of attempts. The stronger password is like putting ten thousand locks on a door when ten is neurotic, and people usually just try to get in through the back door anyway.

To be sure, people shouldn't use insecure passwords. One trick that hackers actually can make good use of is to accumulate a few thousand common and predictable passwords and run through the list, which doesn't take too much effort. The military has long known not to give secret projects codenames that have any relationship to the specifics of the project, and similarly users shouldn't come up with passwords that have anything visibly to do with themselves or the account being logged into. It is also unwise to extract passwords from popular tunes or the like that are easily guessed; users are better off leveraging off something known mostly to themselves and unfamiliar to the general public, or nonsensical-sounding phrases: "greenboatsix".

Selectively mixing in a few substitutions of numbers for letters -- "1" for "i", "2" for "z", and so on -- and selectively applying imaginative spellings to password elements helps, too. If we have any worry about the possibility of a password being second-guessed, we can tack a short security code onto it: for example, "wotzupd0k" might be guessed, but "wotzupd0k-z23" wouldn't. A hacker can't get a "fingerhold" into a password; if one character is wrong, the password doesn't work, and the hacker has no way of knowing if only one character's wrong, or if they all are. Users should also have unique and relatively tough passwords for critical sites, such as bank or stock broker accounts, and not re-use the same password created for casual accounts where there's nothing more important to steal than, say, an email address.

We don't really need to bust our brains to come up with a password like "Jm0q845xxiN4" and then jump through hoops to make sure we don't forget it. We can do just as well with, say, "yagotabjok1n" or "work1nreverse" or "raz0rblastr", something not easy to guess. We can even have some fun with it.

Of course, we tend to accumulate passwords in quantity and there's no way to avoid writing them down. If we keep a file of passwords on a personal computer, that means that anyone stealing or hacking into the computer can get at all the passwords. Not a worry; free encryption software such as GNUPG is easy to get, and we can encrypt the password file to prevent snoops from reading it if they steal a PC or smartphone. All we have to do is remember one password, to allow us to decrypt the password file. "Password management" applications are available to make the process "user friendly".

Passwords are nonetheless seen as not very secure, and so the push has been towards "dual authentication", backing a password up with an alternate identification scheme. Smartphones now often feature fingerprint readers to validate transactions; facial recognition is also increasingly being used, since it only needs a camera -- common on smartphones and PCs -- instead of a specialized fingerpint sensor. Such "biometric" ID schemes are in their early days, but are becoming more widely used.

BACK_TO_TOP
< PREV | NEXT > | INDEX | SITEMAP | GOOGLE | LINKS | UPDATES | BLOG | EMAIL | $Donate? | HOME