They are expiring, just not in the way we thought it was going to work, god this title is so misleading. Once you use it, it expires, otherwise you got 27~ minutes to punch it in.
They are expiring, just not in the way we thought it was going to work, god this title is so misleading. Once you use it, it expires, otherwise you got 27~ minutes to punch it in.
Just called the POL help center this morning, and even though the lady said she couldn't help me with support of the tokens function, she said they it could be a temporary thing until they get most (if not all tokens) rolled out by the end of this month.
So maybe its just until everyone gets used to it/gets it setup for the first time. Then maybe they'll change it. Just an optimistic thought.
I like your "STEAL THE HQ" image btw :3
I put the big one I made in the crafting section ^O^/
http://img4.imageshack.us/img4/9165/...synthinyou.jpg
The assumption that the algorithm will not repeat a password is the flaw in your theory. The RSA card implementations can produce the same code before iterating through all the codes. This is to prevent brute force attacks such as yours from counting on the fact that the algorithm will repeat during a set interval. This alone will increase the duration from 4 months to any given amount of time that is determinant on the collision distribution and seed complexity.
At any given 27 minute interval your chances are basically reset based on strength of the hash function and its ability to not have concentrated collisions in a certain small range(another topic altogether). If there is a lockout duration, it pretty much means that your chance of bruteforcing probability wise has to do with the total number of attempts breaking the culmulative probability of trying so many times. And that is still not definitive but a chance.
Furthermore, it is easy to programmatically identify bruteforce attempts. The proxy argument about just using another proxy is poor. There are not an indefinite number of proxies available and the number of proxies available diminishes at a much faster rate than simple programmatic IP banning process for excessive bruteforce attacking.
Because there is the Square-Enix Username and password. Your theory also only applies to people that are compromised via keylogger and not change their account security at any given point through a long duration. Business logic for the hackers must also be played in. With Long brute force investment to hack accounts with variable unverifiable payload, is it worth it to break in to random unknown account which could potentially be a mule or a poor character?
I suspect it's generically a 30-minute token. Minus the time between the initial button-press and when you link that specific token to the SE account.
for instance:
12:00 - press button, recieve number
12:00-12:03 - fill out webpage form with number recieved, SE account info, etc.
12:03 - press "submit". The form will take that number you entered and consider it valid at *this* exact time, not 3 minutes prior.
I wonder, if you waited 29 minutes to submit your key to the SE synchronization page, would your later numbers only be valid for 1 minute intervals? Since they'd be rolling off the end of the algorithm.
Under normal circumstances, a wormhole can only be maintained for slightly more than 38 minutes.[38] Extending the wormhole duration beyond this requires tremendous amounts of power, such as that provided by a nearby black hole,[39][40], energy beings,[41] or advanced technologies.[3][42]
http://en.wikipedia.org/wiki/Stargate_(device)
WE HAVE OUR ANSWER! :-þ
There is no need to contact SE on this, it is working as expected.
Same deal goes for my place of employment, and if it's good enough for my company, I'm more than confident it is sufficient for a mmorpg.
My token is almost exactly the same as the ffxi one, made by the same vendor even. Each code lasts around 30 mins and a new code is generated every 30 seconds.
The security is still there, even if a code is valid for 30 or so minutes. The brute force arguments that I've read in this thread isn't a valid argument. Not only is there a limit on attempts, but the time required to break the key is much larger than the <30 minutes you have before the key changes.
Can you try this again but use an "old" code? Like, fudge it until it locks out, then use a code generated at the 13 minute mark in the lockout period when it unlocks.
I'm curious to know if it's constantly generating the codesets or if it only starts reading and accepting during non-lockout periods...if the latter then this is pretty damnedably safe from anything short of someone cracking the seed algorithm.
the token has NO WAY of knowing if the account is locked out. it just keeps using a function to generate numbers based off the internal clock. period. you can lock out your account. you can delete the account. SE can close their servers. alien overlords could descend upon the earth wiping out all human life in preparation for terraforming the planet into something habitable for their powerful, space faring race. and the token will continue to generate numbers. will the server accept numbers that would have been generated in a lockout period? who knows. maybe, maybe not. that's an implementation question, but the token will keep generating them regardless of what fate befalls your account or the human race.
hahahahahhaah
I think he meant the server that matches the code from the token to whatever it has to match, not so much the token itself. Something server side has to be generating the same set of codes as the token right?
i highly doubt that the server is constantly generating the codes and logging them through a sliding window. figure 50,000 accounts every 40 seconds and that's a lot of chugging. instead, when you login, it generates F(T), F(T-30), F(T-60), etc. and sees if any of the elements of that list match the key you submitted.
not to sure about this time out amount. i just tested, and i could only use a password once, even within a 30 second period.
Reminds me of
http://badblue.com/temp/080410-st-opening-shot.jpg
A badly garbled distress call was just received.
http://badblue.com/temp/090216-st-spock-sensor.jpg
Captain, computer scanning recognized the location ZZ9 Plural Z Alpha ... then we lost the signal...
http://badblue.com/temp/090216-st-starfield.jpg
Our sensors show this entire region has been destroyed.
http://badblue.com/temp/090216-st-kirk.jpg
That's. Incredible.
http://img21.imageshack.us/img21/165...sabledship.jpg
The signal appears to be coming from a small object of unknown origin, made up of high density polyethylene and thermoplastic carbonate groups.
http://badblue.com/temp/090216-st-spock.jpg
Readings are difficult due to subspace interference, but the object has taken heavy damage and remains functional. It may be related to the Twentieth-Century phenomenon known as "RMT-PWNER".
http://badblue.com/temp/090216-st-kirk-alert.jpg
RMT? Not that. It might. Be. Hostile to. Us.
http://badblue.com/temp/090216-st-sp...or-serious.jpg
Sir... sensors indicate the device is generating random numbers at a geometrically increasing frequency.
http://badblue.com/temp/090216-st-sulu.jpg
Captain! The number refresh rate has increased to maximum!
http://badblue.com/temp/090216-st-battle-stations.jpg
Number stream has resolved to a visual data transmission.
http://badblue.com/temp/090216-st-decker3.jpg
MY ACCOUNT THEY HACKED MY ACCOUNT I HAD NINURTA'S SASH TOO
http://badblue.com/temp/090216-st-kirk-2.jpg
Did you call the. Help. Desk or a. GM?
--
The SEA page says passwords are supposed to no longer work after 30 seconds, so this is not working as planned.
Also it would take a lot longer to brute force it. Like someone already mentioned you get locked out for 10 min after 5 incorrect codes.