Posts by Alan Doherty 7 publicly visible posts • joined 18 Oct 2007
re: Wrong
By Anonymous Coward
no essentially what they are doing is hi-jacking the browsers default 404 page only
in your scenario {a timeout} no 404 recieved so timout message given to user
if your server has any custom error page it is shown
only the default
<html><head><title>404 Errror</title></head><body><h1>404 Errror</h1><p>
the page was not found</p>
<address><a href="http://servername/">servername</a> apache vxx.x</address></body></html>
page tends to be small enough
guys? its maglev, strong magnets!! {permanent unpowered}
not electromagnets {temporary requiring power}
so many willing to comment without any knowledge
{yes mike i know yers was more of a joke about the other article}
on the other hand silly to spend so much effort /money and not make it look comfortable
both yahoo and blogger have just become openid providers
they do not seem to have any plans to let their users move grom id/password on their own sites to openid
{openid only recieves real support from sites allowing login credentials to be associated with an openid {or even a few} thus giving the users the choice to only have to remember the one set of credentials for all sites they use openid instead of username / passwoed}
more openid providers are not really needed, and yahoo's encoraging of people to use a login with yahoo on their sites runs contrary to the entire point of openid
going by the fact that 90% of my work is cleaning up after a so-colled {and billed} security experts. supposed work
i would guess that the people running the site were employing those of the same calibre
or more likely hosting with a company that ill-secures its servers
the fixed by frontpage page kinda re-enforces that for me. a security expert that can't knock up some html unaided{or at least clean the frontpage crap out after} is hardly much use at spotting a subtily hacked site {malicious code insertion} for their clients
let alone securing or auditing the system/network it runs on
The point of contention is not comcast managing or restricting traffic as it crosses their network {as is their intent and right}
its the method they use to achieve the aim
sending tcp rst packets is not an acceptable way of doing this
{effective yes but not acceptable}
{a tcp rst based method relies on the intermediary performing a man-in-in-the-middle style attack on the connection by forging replies from the server to the client saying 'your request was canceled' and from the cleient to the server saying 'please cancel my request'.
this is obviously unnaceptable
the methods for asking a server to slow its responses and asking a client to do simmilar are already available within the scope of the icmp protocol,
forging rst packets stop dead any transfer,
if the client re-tries again later it is not due to the underlying design of tcp but rather through some re-trying built into the client to try and pre-empt this sort of malicious tampering {or in the case of bit-torrent to allow for transfers broken by one side re-booting to resume later} but the re-tries are not within a resonable or short period of time.
the basic issue is not comcasts attempts to limit the effect of this traffic on available bandwith its the method they are employing envolves feeding both sides eronious data, and doing so by forging the source to be the other party. this DOES set a worrying precedent as by allowing this it also opens the door for them to say return a forged page instead of the website you requested or any other type of forged reply, with you the user being none the wiser.
I see nothig wrong with badwith shaping or traffic limiting, {and there are many ways they can achieve this without resorting to this form of forgery, which is the only issue being debated}
i quote
"By Dom
Posted Thursday 18th October 2007 16:37 GMT
I've yet to see anybody come up with any good reason why passwords need changing on a regular basis. They're either secure or not. The more often people change them the more likely they are to write it down somewhere or pick a weak one."
err. obviously you change your passwords to offset the possibility of brute force trial and error succeeding.
simply put if your password never changes a brute force attack will succeed regardless of the time it takes between each attempt.
if you change it regularilly trying every possible combination sequentially will likely fail as by the time they get near the correct passowrd the current one may be one they tried x amount of time ago thus will never try again.
obviously the time between changing passwords depends on the time allowed between successive attempts, for most of my systems 3 unsucssessfull events allows no more to be attempted for an hour then 2 then 4 etc. with an e-mail dispached to user with details of who to contact for recovery and the ip involved in the attempt {so they can just add it to the blocked/remove it from the allowed} list if its not themselves
thus brute force would take a long time to get through any reasonable number of attempts
for web based logins 3 failed {no time limit between} attempts causes a capcha to be involved for all subsequent attempts {with the same e-mail to user} for the same reason to help foil brute force.
BTW reg folks how about like most of these fora, allowing openid instead of us now having another id/password to have to keep track of as its so much easier than having to keep track of all these id's passwords for sites still using older methods to track users, or is it because using older methods allows you to compile our e-mails to a list for later spamming^H^H^H^H^H marketing purposes
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
