DDoS'able logins - who'd a thunk it?
Seems to me that having a login system that is _SO_ inefficient, and SO reliant on a single "provider", that a 30 second timeout on a login token is sufficient [under the right conditions] to create RACE conditions and other 'token expiration' related problems, that maybe... JUST maybe... the entire design needs to be COMPLETELY re-thought.
All eggs: one basket. Yeah, THAT isn't a recipe for FAIL !!!
It's COMPLETELY DDoS'able, as it only took "everyone flushing at once" (more or less) to cause the system to 'overflow' heh heh heh. Must've been REALLY fun in the basement bathrooms.
MSDN has a somewhat 'paranoid' security model as well, one that expires a download link after about 4 hours. This means that very very large files over moderate connection speeds CAN NOT COMPLETE DOWNLOADING. When Micro-shaft's IIS servers did NOT follow the RFC's (a couple of years back), you couldn't even pick up where you left off - it was 'start from the beginning again' every time. Fortunately, they fixed that last part, eventually... [making it usable again with proper browser plugins or through-the-hoop jumping].
NOW they're "at it again" with their "all eggs, one basket" approach to logins, and unrealistically short timeout periods on the tokens, not allowing for very busy networks, slow connections, or DDoS attacks.
Wheeeee.
this reminds me of a computer back in the late 70's that had an old-style 12" floppy drive connected to a serial terminal (access via serial and control chars on a shared serial line at 1200 baud). A grad student wrote an application in BASIC that allowed you to store things on it [inefficiently]. But, if the mini-computer had more than a handful of users on, when you tried to retrieve your stored files, you'd get buffer overruns and lost data. Often it was COMPLETELY unusable. I re-wrote a new version in assembly language that had proper buffering [and an actual file system on the disk]. I'd ask the drive for ONLY a track at a time (not 'flood me with all at once'), which fit nicely into the mini-computer's serial buffer, and no data was lost, even if the system was THRASHING because of too many users.
Anyway...