Long ago, when you attempted a two factor authentication (account name / password) process with a server, the normal connection procedure would verify for the existence of a given account, and verify the password against that account. If either verification failed, a properly written server based script would tell the user what he was doing wrong - either "Invalid account" or "Invalid password".
Then security experts realised that if you issue an error saying "Invalid account", you were, in effect telling a possible intruder what accounts did not exist on the server in question - enough connection attempts would then tell an intruder what accounts did exist. This is a known hacking technique, called by some security experts "account name mapping". Knowing the existing accounts, the hacker can then try to guess the passwords on those accounts.
Some secure servers, made resistant to mapping, don't issue any error messages, they simply ignore your unsuccessful attempts (non existent account or invalid password) . Make too many unsuccessful attempts, and your IP address gets blackholed.
If you're a person trying to connect, you just keep trying - try another password, or another account name. If your IP address is blocked, you wait a while (5 minutes or so) and try again.
But what if you're not a person connecting interactively, but a person running a script? Like publishing from Blogger by FTP, to a distant host server? That complicates matters.
One of the problems with establishing a connection with a distant server is not knowing if the server in question is there, or is there but not responding, or is there but intentionally ignoring you. The Blogger FTP publishing script has to allow for all of these possibilities. Blogger doesn't want for you (really, they don't) to sit and watch the Spinner Of Death any longer than you want to watch it. They also don't want to come back to you and say
It's a tuning issue. Wait too long, and the bloggers get impatient. Don't wait long enough, and the bloggers get angry. Each distant host server will have different connectivity issues, and the issues will vary by current load, and by network status.
So add the authentication process on top of that, and add some servers that will simply ignore improperly authenticated connections. How is the Blogger FTP Process realistically expected to reliably connect (or not) to all distant host servers? Especially with some problems knowingly tolerated by the operators of the distant host servers?
So the next time that you can't publish your blog to your distant host server, don't just get into the forum and yell
>> Top
Then security experts realised that if you issue an error saying "Invalid account", you were, in effect telling a possible intruder what accounts did not exist on the server in question - enough connection attempts would then tell an intruder what accounts did exist. This is a known hacking technique, called by some security experts "account name mapping". Knowing the existing accounts, the hacker can then try to guess the passwords on those accounts.
Some secure servers, made resistant to mapping, don't issue any error messages, they simply ignore your unsuccessful attempts (non existent account or invalid password) . Make too many unsuccessful attempts, and your IP address gets blackholed.
If you're a person trying to connect, you just keep trying - try another password, or another account name. If your IP address is blocked, you wait a while (5 minutes or so) and try again.
But what if you're not a person connecting interactively, but a person running a script? Like publishing from Blogger by FTP, to a distant host server? That complicates matters.
One of the problems with establishing a connection with a distant server is not knowing if the server in question is there, or is there but not responding, or is there but intentionally ignoring you. The Blogger FTP publishing script has to allow for all of these possibilities. Blogger doesn't want for you (really, they don't) to sit and watch the Spinner Of Death any longer than you want to watch it. They also don't want to come back to you and say
We can't publish today, the other server isn't answering.
It's a tuning issue. Wait too long, and the bloggers get impatient. Don't wait long enough, and the bloggers get angry. Each distant host server will have different connectivity issues, and the issues will vary by current load, and by network status.
So add the authentication process on top of that, and add some servers that will simply ignore improperly authenticated connections. How is the Blogger FTP Process realistically expected to reliably connect (or not) to all distant host servers? Especially with some problems knowingly tolerated by the operators of the distant host servers?
So the next time that you can't publish your blog to your distant host server, don't just get into the forum and yell
Hey everybody, Blogger is hosed again.Do some diagnostic work first. Please.
>> Top
Comments