Topic: ASICMINER: Entering the Future of ASIC Mining by Inventing It - page 1332. (Read 3917029 times)

+1

Actually, zefir, merely what you have said is comforting. ty

And fits what I was expecting. The board members acting as a 'half-way house' where credibility/sincerity can be established without doing a full-monty to the entire public.

And, I hope, helping to smooth out or suggest clarification of statements before they are released to the unwashed mob who might misinterpret text presented in good faith.

Hi VeeMiner,

the additional information board members received so far does not exceed what is available here in the forums - at least nothing that would give you an informational advantage over non-board members. To give you a better idea, here is what has been provided so far:

1) a detailed explanation on the relation between ASICMINER and Bitfountain shares and how dividends will be distributed. This is basically a confirmation on what was already written in the IPO posts.
2) an introduction of the people behind Bitfountain, including full names, contact information, and short CV. This is basically to confirm that those people a) are real, b) are capable to deliver what is planned, and c) can be contacted for further questions.

All in all it does not provide valuable information other than a strong indication that those folks are serious and the plan sounds reasonable. I'm pretty sure friedcat will make most of those documents available to the general public at a later date (but for obvious reasons he won't post contact information to the individual developers on a searchable forum).


HTH

I can provide this info if I get a good to go from friedcat
//DeaDTerra

yeah, that's what I meant, I would be interested if the board members could give us some information about the recent development

OMG you're using cloudflare? So you're trusting all our wealth in hands of a SSL proxy?! I'm out!

The board members receive emails with updates.  I don't know how much they are allowed to disclose,.

so I decided to put some of my very limited budget in ASICMINER. It seems like a trustworthy company that can deliver and make good money in a long run. My question is if we will receive any more information about current development of this company as there hasn't been much discussion about what's going on right now in the thread. I wonder if some of the bigger shareholders have some more information that they would be willing to share with the small investors.

Yes, I do run as different users when it's necessary for security. Yet I didn't really get why I shouldn't rely on GLBSE's model. I'll read about what you said about browser's settings. I won't reply again, since it's apparently off-topic.


I agree. Though it became relevant because of the possibility of me paying the price as a shareholder. I guess this is best moved to PMs.

This discussion about GLBSE is a useful one but I feel this topic is not the place for it. When I see updates on this topic I hope to read about developments surrounding ASICMINER. I think these GLBSE discussions would be better off in their own topic.

If you can't rely on the security settings of your browser (that's what's the case here) you have to go to the next level and put your applications into a sandbox. The easiest way to achieve that is to setup up a different user account for trusted services, e.g. for logging into email, exchanges and glbse. Another, more fancy solution is to run the insecure stuff in a virtual machine.

I know it's a hassle but if you can't rely on the security model of GBLSE you have to make your own.

I can't list you attack scenarios because it's been a while since I've been reading up on the different possible attack vectors. But sandboxing/different user accounts is an old technique which hardly breaks (unless you run the insecure stuff as root).

How does cross-application scripting (?) apply to this case?

I think the current scheme is pretty OK actually. Do you have a scenario how a session can be remotely hijacked?

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!

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..

As long as a 'hacker' can't use my SessionID on his own computer, I see no problem, but according to the above this ID won't change since I'm always logged in..

https://bitcointalksearch.org/topic/m.1138707

Does he use Windoze 

I don't know exactly what you mean by this, but I have Google 2FA installed.

When I log in on GLBSE en close the tab without logging out, I can re-open GLBSE after a few hours and it will come back up with me logged in, so I don't have to re-login

I do leave other tabs in my google chrome open, so I never close chrome completely

FYI

No. Some shares were lost by Nedbert9 and he tried to figure out why and came to the conclusion the only weak point must be GLSBE with a session fixation attack. What really caused the loss, no idea.

ASICMINER has been compromised? :O
//DeaDTerra

I just want to chime in on the compromise.

There was no unusual activity around the time of the attack, meaning there wasn't a large number of attempted logins.

GLBSE uses SSL from the browser to Cloudflare and from Cloudflare to the GLBSE server, cloudflare can minify JavaScript (hence the "we may change site content" in their TOS). I have a paid service with them.

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 only whitelist certain html elements for PM's and contracts so no XSS, and we use SSL so no man in the middle session sniffing attacks. Session ID's are not predictable or unencrypted.

In my PM I said apart from machine compromise, re-used/insecure password, the only thing I could think of that could be the cause was a session fixation attack, which GLBSE is not vulnerable to.

A session fixation attack requires the attacker to set the cookie in the users browser so the session ID is known, once the user visits a site and logs in, if the session ID is not changed then the (known session ID) becomes a valid session, and the attacker has succeeded. This is prevented by changing the session ID on login and using SSL (GLBSE only allows SSL).

I'm not able to say what caused the compromise, but I can say what it was not.

Nefario