Ah, that's your problem. Use a separator when merging your username and password. Now the combination spells out goo|berville, goob|erville or whatever and we're back to the same strength as two separate fields.
Number of possible username (length: U) / password (length: P) combinations over an alphabet of size X: X^(U+P) Number of possible passwords (length: U+P) over the same alphabet: X^(U+P) ... In general the lengths aren't known, but this generalizes to unknown lengths.
That's a vague answer, can't you come up with the exact math for both cases?Is this about best-case or worst-case? Yes, best-case the user name is unknown and totally different. Worst-case, especially with recent versions, both are equal.This is about security. If you can't prove a security scheme it's unlikely to be secure.Weren't we talking about the user / pass account? You keep changing stories... Yes, a password of size 10 with 26 different chars has 26^10 possibilities. What's your point? You've still not shown that using two fields is better than using one combined field.True, my bad. If passwords were guaranteed to be strong and unique using just the password would be fine. Unfortunately that can't be guaranteed.
How much more time and why?Got a reference for that? Display name defaults to user name, so user name can NOT be considered a secret.Are you asking me to prove you're wrong instead of you proving you're right?That'd make account recovery a bit hard. But in some systems a single password (without username) is indeed used, think WPA for example.
Security depends on total entropy, not on the number of fields.
They could as well be trying every combination of user/pass with total size <= 10 and they'd be finding your pass / word account too, wouldn't they? The effort would be equal.