I'm not sure why I'm wasting my breath. GLBSE operator and the beneficiaries of the the stolen ASICMINER shares, with the exception of Jatarul who sold back to me, could care less about what I have to say.
I've chosen to take a break, probably a permanent distancing, from this forum because of this incident. I do not believe in the 'finders keepers' mentality and dislike those that support instantaneous transfers over fraud controls and will happily benefit from fraud. Nefario, who had the opportunity to make this right for 30 BTC, other beneficiaries, including a forum staff member who specifically benefited by ~160 shares and then offered me 0.64 BTC as a consolation (grr) has left me feeling that this is just not the place for me to hang out in.
With that said I wanted to clarify some of my comments, clear up some fallacies and offer a very serious warning.
I specifically told nedbert9 that GLBSE is not vulnerable to session hijacking attacks, so I don't know why he stated that it was. GLBSE resets the session ID after login which prevents session fixation.
We need to be clear on terms to understand my point and Nefario's statement. Nefario is right that Session Fixation was not the method used - I can't comment if Session Fixation is not possible with GLBSE. This is my mistake to describe what happened to my GLBSE account as a result of Session Fixation.
However, I was a victim of a session hijack. Session Fixation describes a specific attack scenario, while session hijack can be considered a more vague term for any compromise of an authenticated session.
My apologies to Nefario for continuing to use the Session Fixation term. Still, I stand by my belief that my session was hijacked (and that it was facilitated by freenode's web interface)
I maintain that Nefario's management of the client-side environment for the GLBSE web app is a security risk. This led to my GLBSE session being hijacked.
Dutchbrat and Smiguel's experience points out the same client side behavior that allowed for my session to be hijacked.
GLBSE can claim no responsibility for lax control of sessions on the client side, but any honest assessment of session management for security sensitive sites will point to the same conclusion.
Taken from
http://stackoverflow.com/questions/805895/how-come-closing-a-tab-doesnt-close-a-session-cookiePoint (a convenient excuse if attempting to deny responsibility for security)
"The session cookie is per-process not per window. So even if you selected New Window you'd still get the same session id. This behavior makes sense. You wouldn't want a user to re-sign in each time they opened a new window while browsing your site."
Counter point
"In such circumstances, the tab closing isn't the main issue. It's controlling the expiration of the session more actively. You'll want to implement some sort of activity timeout on the client in JS that automatically logs out after no user activity. You'll find this type of behavior on most banking sites"
Going further than the counter point is my personal feeling that if a site that consists of a single browser tab experience (no popups) and that site dev isn't using JS to invalidate the authenticated session when the DOM (page) object for the site is closed the site dev is horribly negligent and just doesn't give a shit about what happens on the client side.
I've asked Nefario to answer the counter point in the GLBSE 2.0 testing thread. Why doesn't Nefario take client session management more seriously?
DiabloD3's comment about enabling 2FA for each and every GLBSE activity is very good advice. By 2FA design, even if your session is hijacked the attacker will not have the 2FA auth code to take any action within your account. Here's the scary part. GLBSE's 2FA measures might be buggy. Take a look at this quote.
Even if you,after you totaly CLOSE Internet Explorer or Firefox, (I don't use Chrome, so can't test it) go to GLBSE your session is still active/logged in.
Actually, after you restart your computer, it is still logged in..
I have 2FA activated, but only have to fill in the auth-key when I use a 'new' computer..
I emphasize *might* be buggy. It is not for me to say.
Finally.
Ok. this then qualifies as a major security hazard. We need to advice any shareholder to only run GLBSE as a dedicated user then. Otherwise cross-application hacking is possible. Especially since 2FA doesn't protect you from your shares being dumped to the market!
Yes, don't trust GLBSE or any other site that takes a "use at your own risk" attitude. This is especially pertinent for the anonymity loving Bitcoin related sites. Isolate your web session with GLBSE as much as possible. Use unique email address, unique and strong password, enable 2FA for every action and open GLBSE in it's own full browser process - not a tab - and terminate that process when done.
