Re: Solving password problems one at a time, Re: The password-reset paradox
On 05/09/09 07:33, Jerry Leichter wrote: I had a discussion with a guy at a company that was proposing to create secure credit cards by embedding a chip in the card and replacing some number of digits with an LCD display. The card would generate a unique card number for you when needed. They actually had the technology working - the card was pretty much indistinguishable from any other. (Of course, how rugged it would be in typical environments is another question - but they claimed they had a solution.) Deloitte staff trial Visa card with built in OTP generator for IT access control http://www.finextra.com/fullstory.asp?id=20019 -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
On May 8, 2009, at 3:39 PM, Ian G wrote: The difficulty with client certs is that I need them to also work on my laptop. And my other laptop. And my phone. So, how do I get hold of them when I'm on the road? Good point. The difficulty with my passwords is that I have so many that are so long that I can only manage them on my laptop, and have to carry my laptop with me ... We can imagine all sorts of techie solutions to this, but it does appear that we are in a bit of a grey zone with auth at the moment, and the full solution might take a while to emerge. Try them all? This is part of a broader UI issue. I had a discussion with a guy at a company that was proposing to create secure credit cards by embedding a chip in the card and replacing some number of digits with an LCD display. The card would generate a unique card number for you when needed. They actually had the technology working - the card was pretty much indistinguishable from any other. (Of course, how rugged it would be in typical environments is another question - but they claimed they had a solution.) I pointed out that my wife knows one of her CC numbers by heart. The regularly quotes it, both on phone calls and to web forms. The card itself is buried in a thick wallet, which is buried in her pocketbook, which is somewhere in the house - likely not near the phone or the computer. Hell, one of the nice things about on-line shopping is that I can do it in my bathrobe - except that I *don't* know my CC by heart, so in fact I tend to put off buying until later when I have my wallet with me. (This does save me money) When I'm in a store, I'm used to having to have my CC with me, because I always had to have the wallet with money anyway. At home, it's a whole different story. In any case, merchants are trying to make the in-store experience as simple as possible, pushing for things like RFID credit cards and even fingerprint recognition. So many people would see these safer cards as a big step backwards in usability. Why would they want such a thing? The card companies are trying to sell safety, but in the US, where your liability is at most $50 if your CC number is stolen (and where in practice it's $0), the only cost you as an individual bear is the inconvenience of replacing a card. Because replacements for security problems have gotten so common, the CC companies have streamlined the process. It's really no big deal. I've had CC numbers stolen a couple of times (by means unknown); recently, two of my CC's were replaced by the companies based on some information known only to them. In every case, the process was very quick and painless. Hell, these days even on-line continuing charges often update to the new number automatically (though I've learned to keep track of those and check). The person arguing for this claimed that CC companies could offer a discount for users of the secure cards. But if you look at actual loss rates - how much could you offer? (I'd guess it's about the same as Discover offers: About a 1.5% rebate on most purchases. Not enough to let Discover steal customers from Visa and MC. Given all the other charges - and the absurdly high interest rates - on cards, anything like this gets lost in the noise.) Security that depends on people changing their habits in a way that is inconvenient to them ... won't happen (unless you're in an environment where you can *force* such changes). -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
On 05/09/09 07:33, Jerry Leichter wrote: On May 8, 2009, at 3:39 PM, Ian G wrote: The difficulty with client certs is that I need them to also work on my laptop. And my other laptop. And my phone. So, how do I get hold of them when I'm on the road? Good point. The difficulty with my passwords is that I have so many that are so long that I can only manage them on my laptop, and have to carry my laptop with me ... We can imagine all sorts of techie solutions to this, but it does appear that we are in a bit of a grey zone with auth at the moment, and the full solution might take a while to emerge. Try them all? This is part of a broader UI issue. I had a discussion with a guy at a company that was proposing to create secure credit cards by embedding a chip in the card and replacing some number of digits with an LCD display. The card would generate a unique card number for you when needed. They actually had the technology working - the card was pretty much indistinguishable from any other. (Of course, how rugged it would be in typical environments is another question - but they claimed they had a solution.) I pointed out that my wife knows one of her CC numbers by heart. The regularly quotes it, both on phone calls and to web forms. The card itself is buried in a thick wallet, which is buried in her pocketbook, which is somewhere in the house - likely not near the phone or the computer. Hell, one of the nice things about on-line shopping is that I can do it in my bathrobe - except that I *don't* know my CC by heart, so in fact I tend to put off buying until later when I have my wallet with me. (This does save me money) When I'm in a store, I'm used to having to have my CC with me, because I always had to have the wallet with money anyway. At home, it's a whole different story. In any case, merchants are trying to make the in-store experience as simple as possible, pushing for things like RFID credit cards and even fingerprint recognition. So many people would see these safer cards as a big step backwards in usability. Why would they want such a thing? The card companies are trying to sell safety, but in the US, where your liability is at most $50 if your CC number is stolen (and where in practice it's $0), the only cost you as an individual bear is the inconvenience of replacing a card. Because replacements for security problems have gotten so common, the CC companies have streamlined the process. It's really no big deal. I've had CC numbers stolen a couple of times (by means unknown); recently, two of my CC's were replaced by the companies based on some information known only to them. In every case, the process was very quick and painless. Hell, these days even on-line continuing charges often update to the new number automatically (though I've learned to keep track of those and check). The person arguing for this claimed that CC companies could offer a discount for users of the secure cards. But if you look at actual loss rates - how much could you offer? (I'd guess it's about the same as Discover offers: About a 1.5% rebate on most purchases. Not enough to let Discover steal customers from Visa and MC. Given all the other charges - and the absurdly high interest rates - on cards, anything like this gets lost in the noise.) Security that depends on people changing their habits in a way that is inconvenient to them ... won't happen (unless you're in an environment where you can *force* such changes). -- Jerry at least the initial introduction of one-time-account number displays had a problem because they couldn't meet the flexing specification (like cards in mens wallet and getting sat on). note that there has been big push to signature debit (similar interchange fees and fraud as signature credit) with 15 times the fraud of PIN-debit (which has significantly lower interchange fees compared to signature debit) reference http://www.digitaltransactions.net/newsstory.cfm?newsid=73 mentioned in this post from 2006 http://www.garlic.com/~lynn/2006e.html#21 there has been some articles about unsafe cards being a profit item for financial institutions ... since they charge merchants a significantly higher interchange fee. there have been references that there can be as much as a order of magnitude difference in fees between unsafer transaction fees and safer transaction... with unsafe transaction fees contributing significantly to reports that payment fees have represented as much as 40% of bottom line for US consumer financial institutions (an order of magnitude reduction would be a big hit). part of thread on this subject in this mailing list from two years ago http://www.garlic.com/~lynn/aadsm27.htm#31 http://www.garlic.com/~lynn/aadsm27.htm#32 http://www.garlic.com/~lynn/aadsm27.htm#33 http://www.garlic.com/~lynn/aadsm27.htm#34 http://www.garlic.com/~lynn/aadsm27.htm#35 http://www.garlic.com/~lynn/aadsm27.htm#37 http://www.garlic.com/~lynn/aadsm27.htm#38
Re: Solving password problems one at a time, Re: The password-reset paradox
Ben Laurie b...@links.org writes: Incidentally, the reason we don't use EKE (and many other useful schemes) is not because they don't solve our problems, its because the rights holders won't let us use them. That's not the reason, TLS-SRP isn't that annoyingly encumbered, and even the totally unencumbered TLS-PSK doesn't get used by anyone. I was told a reason for the lack of use of strong password protocols from one browser vendor that was so stunningly stupid that I had trouble beliving that it was for real, ask me in private mail if you want the details. In any case though it's not patent issues that are leading to non-use. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
Steven M. Bellovin wrote: We've become prisoners of dogma here. In 1979, Bob Morris and Ken Thompson showed that passwords were guessable. In 1979, that was really novel. There was a lot of good work done in the next 15 years on that problem -- Spaf's empirical observations, Klein's '90 paper on improving password security, Lamport's algorithm that gave rise to S/Key, my and Mike Merritt's EKE, many others. Guess what -- we're not living in that world now. We have shadow password files on Unix systems; we have Kerberos; we have SecurID; we have SSL which rules out the network attacks and eavesdropping that EKE was intended to counter; etc. We also have web-based systems whose failure modes are not nearly the same. Why do we think that the solutions are the same? There was a marvelous paper at Hotsec '07 that I resent simply because the authors got there before me; I had (somewhat after them) come to the same conclusions: the defenses we've built up against password failure since '79 don't the problems of today's world. We have to recognize the new problems before we can solve them. (I *think* that the paper is at http://www.usenix.org/events/hotsec07/tech/full_papers/florencio/florencio.pdf but I'm on an airplane now and can't check... That's a pretty annoying paper. Firstly, I don't care about the average rate of account compromise for sites that host my stuff, I only care about _my_ account. This means that I cannot, despite their claim, write down my long, secret user ID because if anyone ever sees it, I'm sunk because of the short password they are advocating. Secondly, they claim that user IDs are in practice secret, on the basis that if they weren't, then sites would be experiencing massive DoS attacks. To prove this claim, they cite a case where SSNs are used as user IDs. Now, if there's one thing we know, it's that SSNs aren't even a little bit secret. Therefore the reason there is no widepsread DoS is because no-one wants to mount the attack. Thirdly, they really need to learn when to use apostrophes! Incidentally, the reason we don't use EKE (and many other useful schemes) is not because they don't solve our problems, its because the rights holders won't let us use them. But usability is *the* problem, with server and client penetration a close second. On this we agree. We do have any number of decent cryptographic schemes that would complete solve phishing. All we have to do is figure out: a) How to show the user that he is actually using the scheme and is not being phished. b) Get it rolled out everywhere. I am not holding my breath, though perhaps '09 is the year for action? -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
On Sat, 21 Feb 2009 11:33:32 -0800 Ed Gerck edge...@nma.com wrote: I submit that the most important password problem is not that someone may find it written somewhere. The most important password problem is that people forget it. So, writing it down and taking the easy precaution of not keeping next to the computer solves the most important problem with not even a comparably significant downside. Up to a point. The most important password problem is very much context-dependent. I'm not going to forget the unlock password to my laptop, because I use it many times/day. I regularly forget my login password to the CS department's servers because I use it so rarely -- as best I can tell, I haven't used it in at least 15 months, because I use public key authentication for most functions. They've installed some new service that will require it, though, so I suppose I need to learn it. However -- if you're talking about garden-variety web passwords, you're probably correct. For your last sentence, see my next response... Having automatic, secure, and self-managed password recovery and password reset (in case the password cannot be recovered) apps are also part of this solution. Define automatic and secure. Self-managed is context-dependent. It's true for generic web authentication; it most certainly is not for more serious ones. The generic recovery/reset mechanisms have their own security issues -- how secure is the back-up authentication systems? In most cases, the answer is much less secure than the base mechanism. I see the second most important problem in passwords to be that they usually have low entropy -- ie, passwords are usually easily guessable or easy to find in a quick search. So -- why does that matter? We've become prisoners of dogma here. In 1979, Bob Morris and Ken Thompson showed that passwords were guessable. In 1979, that was really novel. There was a lot of good work done in the next 15 years on that problem -- Spaf's empirical observations, Klein's '90 paper on improving password security, Lamport's algorithm that gave rise to S/Key, my and Mike Merritt's EKE, many others. Guess what -- we're not living in that world now. We have shadow password files on Unix systems; we have Kerberos; we have SecurID; we have SSL which rules out the network attacks and eavesdropping that EKE was intended to counter; etc. We also have web-based systems whose failure modes are not nearly the same. Why do we think that the solutions are the same? There was a marvelous paper at Hotsec '07 that I resent simply because the authors got there before me; I had (somewhat after them) come to the same conclusions: the defenses we've built up against password failure since '79 don't the problems of today's world. We have to recognize the new problems before we can solve them. (I *think* that the paper is at http://www.usenix.org/events/hotsec07/tech/full_papers/florencio/florencio.pdf but I'm on an airplane now and can't check... The next two important problems in passwords are absence of mutual authentication (anti-phishing) Personally, I think this is the biggest problem when it comes to phishing attacks. and absence of two-factor authentication. What problem does two-factor solve? I agree that it's helpful, but until we know the threat we can't solve it. To solve these three problems, at the same time, we have been experimenting since 2000 with a scheme where the Username/Password login is divided in two phases. In different applications in several countries over nine years, this has been tested with many hundreds of thousands of users and further improved. (you can also test it if you want). It has just recently been applied for TLS SMTP authentication where both the email address and the user's common name are also authenticated (as with X.509/PKI but without the certificates). This is how it works, both for the UI and the engine behind it. (UI in use since 2000, for web access control and authorization) After you enter a usercode in the first screen, you are presented with a second screen to enter your password. The usercode is a mnemonic 6-character code such as HB75RC (randomly generated, you receive from the server upon registration). Your password is freely choosen by you upon registration.That second screen also has something that you and the correct server know but that you did not disclose in the first screen -- we can use a simple three-letter combination ABC, for example. You use this to visually authenticate the server above the SSL layer. A rogue server would not know this combination, which allays spoofing considerations -- if you do not see the correct three-letter combination, do not enter your password. As Peter Gutmann has pointed out, that has succeeded only because it hasn't been seriously attacked. Research results show that users are very easily fooled by changes to the server. In the scenario you cite, all it
Re: Solving password problems one at a time, Re: The password-reset paradox
silky wrote: On Sun, Feb 22, 2009 at 6:33 AM, Ed Gerck edge...@nma.com wrote: (UI in use since 2000, for web access control and authorization) After you enter a usercode in the first screen, you are presented with a second screen to enter your password. The usercode is a mnemonic 6-character code such as HB75RC (randomly generated, you receive from the server upon registration). Your password is freely choosen by you upon registration.That second screen also has something that you and the correct server know but that you did not disclose in the first screen -- we can use a simple three-letter combination ABC, for example. You use this to visually authenticate the server above the SSL layer. A rogue server would not know this combination, which allays spoofing considerations -- if you do not see the correct three-letter combination, do not enter your password. Well, this is an old plan and useless. Because any rogue server can just submit the 'usercode' to the real server, and get the three letters. Common implementations of this use pictures (cats dogs family user-uploaded, whatever). Thanks for the comment. The BofA SiteKey attack you mention does not work for the web access scheme I mentioned because the usercode is private and random with a very large search space, and is always sent after SSL starts (hence, remains private). The attacker has a /negligible/ probability of success in our case, contrary to a case where the user sends the email address to get the three letters -- which is trivial to bypass. http://nma.com/papers/zsentryid-web.pdf (UI in use since 2008, TLS SMTP, aka SMTPS, authentication). The SMTP Username is your email address, while the SMTP Password is obtained by the user writing in sequence the usercode and the password. With TLS SMTP, encryption is on from the start (implict SSL), so that neither the Username or the Password are ever sent in the clear. I have no idea what you're referring to here. It doesn't seem to make sense in the context of the rest of your email. Are you saying your system is useless given SSL? (Aside from the fact that it's useless anyway ...) I'm referring to SMTP authentication with implicit SSL. The same usercode|password combination is used here as well, but the usercode is prepended to the password while the username is the email address. In this case, there is no anti-phishing needed. (UI 2008 version, web access control) Same as the TLS SMTP case, where a three-letter combination is provided for user anti-spoofing verification after the username (email address) is entered. In trust terms, the user does not trust the server with anything but the email address (which is public information) until the server has shown that it can be trusted (to that extent) by replying with the expected three-letter combination. Wrong again, see above. This case has the same BofA SiteKey vulnerability. However, if that is bothersome, the scheme can also send a timed nonce to a cell phone, which is unknown to the attacker. This is explained elsewhere in http://nma.com/papers/zsentryid-web.pdf (there are different solutions for different threat models) In all cases, because the usercode is not controlled by the user and is random, it adds a known and independently generated amount of entropy to the Password. Disregarding all of the above, consider that it may not be random, and given that you can generate them on signup there is the potential to know or learn the RNG a given site is using. If the threat model is that you can learn or know the RNG a given site is using then the answer is to use a hardware RNG. With a six-character (to be within the mnemonic range) usercode, usability considerations (no letter case, no symbols, overload 0 with O, 1 with I, for example), will reduce the entropy that can be added to (say) 35 bits. Considering that the average poor, short password chosen by users has between 20 and 40 bits of entropy, the end result is expected to have from 55 to 75 bits of entropy, which is quite strong. Doesn't really matter given it prevents nothing. Sites may as well just ask for two passwords. The point is that two passwords would still not have an entropy value that you can trust, as it all would depend on user input. This can be made larger by, for example, refusing to accept passwords that are less than 8 characters long, by and adding more characters to the usercode alphabet and/or usercode (a 7-character code can still be mnemonic and human friendly). The fourth problem, and the last important password problem that would still remain, is the vulnerability of password lists themselves, that could be downloaded and cracked given enough time, outside the access protections of online login (three-strikes and you're out). This is also solved in our scheme by using implicit passwords from a digital certificate calculation. There are no username and password lists to
Re: Solving password problems one at a time, Re: The password-reset paradox
James A. Donald wrote: No one is going to check for the correct three letter combination, because it is not part of the work flow, so they will always forget to do it. Humans tend to notice patterns. We easily notice mispelngs. Your experience may be different but we found out in testing that three-letters can be made large enough to become a visually noticeable pattern. Reversing the point, the fact that a user can ignore the three-letters is useful if the user forgets them. The last thing users want is one more hassle. The idea is to give users a way to allay spoofing concerns, if they so want and are motivated to, or learn to be motivated. Mark Twain's cat was afraid of the cold stove. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
On Tue, Feb 24, 2009 at 8:30 AM, Ed Gerck edge...@nma.com wrote: [snip] Thanks for the comment. The BofA SiteKey attack you mention does not work for the web access scheme I mentioned because the usercode is private and random with a very large search space, and is always sent after SSL starts (hence, remains private). This is meaningless. What attack is the 'usercode' trying to prevent? You said it's trying to authorise the site to the user. It doesn't do this, because a 3rd party site can take the usercode and send it to the 'real' site. [snip] I'm referring to SMTP authentication with implicit SSL. The same usercode|password combination is used here as well, but the usercode is prepended to the password while the username is the email address. In this case, there is no anti-phishing needed. Eh? This still doesn't make any particular amount of sense. [snip] This case has the same BofA SiteKey vulnerability. However, if that is bothersome, the scheme can also send a timed nonce to a cell phone, which is unknown to the attacker. This is explained elsewhere in http://nma.com/papers/zsentryid-web.pdf Anything you do can be simulated by an evil site. Sending a key to a phone is a good idea, but still, in the end, useless, because the evil site can simulate it by passing whatever requested the user did to that site. [snip] If the threat model is that you can learn or know the RNG a given site is using then the answer is to use a hardware RNG. No, it isn't. The point is that two passwords would still not have an entropy value that you can trust, as it all would depend on user input. *shrug* make one of them autogenerated. Doesn't matter. You're just adding complexity for no real benefit. That data is just a key that is the same for /all/ users. It is not user-specific. its knowledge does not provide information to attack any account. Well I'm sorry but you don't understand your own system then. Obviously it must have information to 'attack' a given account, because you used it to generate something. The function you used did something, so you can repeat it if you have all the inputs. Sorry if it wasn't clear. Please have a second reading. Indeed. Cheers, Ed Gerck -- noon silky http://www.boxofgoodfeelings.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
silky wrote: On Tue, Feb 24, 2009 at 8:30 AM, Ed Gerck edge...@nma.com wrote: [snip] Thanks for the comment. The BofA SiteKey attack you mention does not work for the web access scheme I mentioned because the usercode is private and random with a very large search space, and is always sent after SSL starts (hence, remains private). This is meaningless. What attack is the 'usercode' trying to prevent? You said it's trying to authorise the site to the user. It doesn't do this, because a 3rd party site can take the usercode and send it to the 'real' site. What usercode? The point you are missing is that there are 2^35 private usercodes and you have no idea which one matches the email address that you want to sent your phishing email to. The other points, including the TLS SMTP login I mentioned, might be clearer with an example. I'll be happy to provide you with a test account. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
On Tue, Feb 24, 2009 at 12:23 PM, Ed Gerck edge...@nma.com wrote: [snip] What usercode? The point you are missing is that there are 2^35 private usercodes and you have no idea which one matches the email address that you want to sent your phishing email to. What you're missing is that it doesn't matter. The user enters the usercode! So they enter it into the phishing site which passes the call along. -- noon silky http://www.boxofgoodfeelings.com/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
RE: Solving password problems one at a time, Re: The password-reset paradox
On February 21, 2009 14:34, Ed Gerck wrote: In a business, one must write down the passwords and one must have a duplicate copy of it, with further backup, where management can access it. This is SOP. This is done not just in case the proverbial truck hits the employee, or fire strikes the building, or for the disgruntled cases, but because people do forget and a company cannot be at the same time responsible to the shareholders for its daily operations and not be responsible for the passwords that pretty much define how those daily operations are run. The idea that people should not write their passwords is thus silly from the security viewpoint of assuring availability and also for another reason. Users cannot be trusted to follow instructions. So, if one's security depends on their users following instructions, then something is wrong from the start. Most organizations I interact with have an SOP that nobody should ever know another's password. The only passwords that are safe stored are those for encryption or the top level admin. You take on a degree of legal responsibility if you have the ability to logon as another user. Since the admin can easily change a user's password, what would be the necessity for this risk? All password changes should be audited. Respectfully, Dave Kleiman - http://www.ComputerForensicExaminer.com 4371 Northlake Blvd #314 Palm Beach Gardens, FL 33410 561.310.8801 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Solving password problems one at a time, Re: The password-reset paradox
On Sun, Feb 22, 2009 at 6:33 AM, Ed Gerck edge...@nma.com wrote: List, In a business, one must write down the passwords and one must have a duplicate copy of it, with further backup, where management can access it. This is SOP. This is done not just in case the proverbial truck hits the employee, or fire strikes the building, or for the disgruntled cases, but because people do forget and a company cannot be at the same time responsible to the shareholders for its daily operations and not be responsible for the passwords that pretty much define how those daily operations are run. The idea that people should not write their passwords is thus silly from the security viewpoint of assuring availability and also for another reason. Users cannot be trusted to follow instructions. So, if one's security depends on their users following instructions, then something is wrong from the start. Solving password problems one at a time. I submit that the most important password problem is not that someone may find it written somewhere. The most important password problem is that people forget it. So, writing it down and taking the easy precaution of not keeping next to the computer solves the most important problem with not even a comparably significant downside. Having automatic, secure, and self-managed password recovery and password reset (in case the password cannot be recovered) apps are also part of this solution. I see the second most important problem in passwords to be that they usually have low entropy -- ie, passwords are usually easily guessable or easy to find in a quick search. The next two important problems in passwords are absence of mutual authentication (anti-phishing) and absence of two-factor authentication. To solve these three problems, at the same time, we have been experimenting since 2000 with a scheme where the Username/Password login is divided in two phases. In different applications in several countries over nine years, this has been tested with many hundreds of thousands of users and further improved. (you can also test it if you want). It has just recently been applied for TLS SMTP authentication where both the email address and the user's common name are also authenticated (as with X.509/PKI but without the certificates). This is how it works, both for the UI and the engine behind it. (UI in use since 2000, for web access control and authorization) After you enter a usercode in the first screen, you are presented with a second screen to enter your password. The usercode is a mnemonic 6-character code such as HB75RC (randomly generated, you receive from the server upon registration). Your password is freely choosen by you upon registration.That second screen also has something that you and the correct server know but that you did not disclose in the first screen -- we can use a simple three-letter combination ABC, for example. You use this to visually authenticate the server above the SSL layer. A rogue server would not know this combination, which allays spoofing considerations -- if you do not see the correct three-letter combination, do not enter your password. Well, this is an old plan and useless. Because any rogue server can just submit the 'usercode' to the real server, and get the three letters. Common implementations of this use pictures (cats dogs family user-uploaded, whatever). And FWIW, renaming password to usercode doesn't make it more secure. (UI in use since 2008, TLS SMTP, aka SMTPS, authentication). The SMTP Username is your email address, while the SMTP Password is obtained by the user writing in sequence the usercode and the password. With TLS SMTP, encryption is on from the start (implict SSL), so that neither the Username or the Password are ever sent in the clear. I have no idea what you're referring to here. It doesn't seem to make sense in the context of the rest of your email. Are you saying your system is useless given SSL? (Aside from the fact that it's useless anyway ...) (UI 2008 version, web access control) Same as the TLS SMTP case, where a three-letter combination is provided for user anti-spoofing verification after the username (email address) is entered. In trust terms, the user does not trust the server with anything but the email address (which is public information) until the server has shown that it can be trusted (to that extent) by replying with the expected three-letter combination. Wrong again, see above. In all cases, because the usercode is not controlled by the user and is random, it adds a known and independently generated amount of entropy to the Password. Disregarding all of the above, consider that it may not be random, and given that you can generate them on signup there is the potential to know or learn the RNG a given site is using. With a six-character (to be within the mnemonic range) usercode, usability considerations (no letter case, no symbols,
