Is fourteen characters long password really weak?

Question

I've tried to sign in to Samsung Cyber Service Center¹. Since I'm from Poland, at first I tried Polish version of that service. I have entered a password, that has:

• 6 numbers in total (in three groups of two numbers each),
• 6 lowercase characters,
• 3 uppercase characters,
• 1 special characer,

in following order: NNccccccNNCCC#.

I was smashed with an error message saying, that I can't continue, because... my password is too weak.

For verification, I went to English version of that sign-up form and after staring for two minutes directly at Password must be at least 8 characters error message, I finally understood, what they really mean. Password must contain at least eight characters in one row, on which my password fails, because it has only six and three characters in one row,(in each of two characters groups).

I'd like to know, how should I treat situatons like this? Is really my example password too weak (and I should consider not using passwords like that anymore) or are these first signs of Samsung Paranoia^TM (or some kind of bug on their site) and I should change password only this time, to match their crazyness.

¹ _{To see mentioned sign-in form, you have to go Cyber Service Center, click - Registration and then Sign Up Now.}

Answer 1

Is a password of the format

NNccccccNNCCC#

weak?

Well, let's do some math two ways:

• Assume it's purely randomly generated (not likely if it has a pattern), and assuming there are 32 choices for the trailing symbol (also unlikely; most passwords choose from a much smaller subset).

  • 10^2 * 26^6 * 10^2 * 26^3 * 32 ~= 1.7E18 ~= 2^61
  • If the site hashes with a single round of MD5 (not unlikely), a modern machine performing an offline attack with oclHashcat will exhaustively search this total keyspace in about 7 months.
  • A cracking group of 7 people each with one of those machines, in about one month.
  • A well funded adversary will spend more time on the paperwork, even if the paperwork is just "push the button".
• Assume it's purely randomly generated except for the 6 character string, which is a word or string that appears in a common cracking dictionary+ruleset of 200,000 possibilities, and assuming there are 32 choices for the trailing symbol (also unlikely; most passwords choose from a much smaller subset).
  • 10^2 * 200000 * 10^2 * 26^3 * 32 ~= 1.1E15 ~= 2^50
  • If the site hashes with a single round of MD5 (not unlikely), a modern machine performing an offline attack with oclHashcat will exhaustively search this total keyspace in about 0.004 months, i.e. less than 3 hours.
  • If the site hashes with a single round of SHA-256, a modern machine performing an offline attack with oclHashcat will exhaustively search this total keyspace in about 0.035 months.
  • If the site hashes with a thousand rounds of SHA-1 without additional overhead (possible, I suppose), a modern machine performing an offline attack with oclHashcat will exhaustively search this total keyspace in about 14 months.
    • Unless they upgrade their GPU's during that year, in which case it goes down further.
    • If you wait for, say, 3 years, then based on Moore's Law and House's Corrollary, the exhaustive search time would be only 3 and a half months.
    • If you wait for, say, 6 years, then based on Moore's Law and House's Corrollary, the exhaustive search time would be about three weeks.

So, what amount of time does a given level of adversary need to spend on an offline attack for you to consider your password "not weak"? Only you can decide that, but here's the math to help.

• That one machine with 8 GPU's in January 2015:
  • MD5 one round: 2.5E17 tries/30 days (2^58)
  • SHA-1 one round: 7.8E16 tries/30 days (2^56)
  • SHA-256 one round: 3.2E16 tries/30 days (2^55)
  • SHA-512 one round: 1.2E16 tries/30 days (2^53)
  • WPA/WPA2: 3E12 tries/30 days (2^41)

Answer 2

Your password pattern looks fine for me. Personally I prefer even more complex passphrases.

I was not able to reproduce your error.

Your scheme (NNccccccNNCCC#) contains only 14 characters, but you wrote that you entered 16.

Their JS test routine (see here) has no problem with neither a 14 character password of your scheme (NNccccccNNCCC#) nor a 16 character one with two added numbers at the end (NNccccccNNCCC#NN).

This is in a minimal running version:

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Script-Type" content="text/javascript" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script type="text/javascript">
$(document).ready(function(){
        var email = "bla@example.org";
        var password = "12abcdefg34HIJ$56";

        if(password.length < 8){
            alert("PWD_VARIFY_MSG");
            return;
        }

        var chk_num = password.search(/[0-9]/g);
        var chk_eng = password.search(/[a-z]/ig);

        if(chk_num < 0 || chk_eng < 0){
            alert("PWD_VARIFY_NUM_ALPHA_MIX_CHECK");
            return false;
        }

        if(/(\w)\1\1\1/.test(password)){
            alert("PWD_VARIFY_SAME_CHAR_4TIMES_CHECK");
            return false;
        }

        if(password.search(email)>-1){
            alert("PWD_VARIFY_EMAIL_SAME_CHECK");
            return false;
        }
});
</script>
<body>

</body>
</html>

So you do not need 8 characters in a row.

Maybe the problem is your special character. Some may be filtered server side to avoid SQL injection (...). It could even be that the password is too long and this gets only checked server side.