Author

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

hero member
Activity: 938
Merit: 1002
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.

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?
donator
Activity: 994
Merit: 1000
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.

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

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



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!
sr. member
Activity: 322
Merit: 252
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.

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

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

legendary
Activity: 1372
Merit: 1003
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
ASICMINER has been compromised? :O
//DeaDTerra

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.

Does he use Windoze  Roll Eyes
hero member
Activity: 868
Merit: 1000
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.

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
legendary
Activity: 2271
Merit: 1363
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
ASICMINER has been compromised? :O
//DeaDTerra

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.
donator
Activity: 1064
Merit: 1000
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
ASICMINER has been compromised? :O
//DeaDTerra
hero member
Activity: 602
Merit: 513
GLBSE Support [email protected]
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
sr. member
Activity: 800
Merit: 250
One approach to the "who owns how many shares" challenge, (I may suggest this to Nefario if he doesn't already have something else in the works):

- Allow an asset Owner to generate a "certificate" for a number of shares. Which then become "locked" in their account.
- They can unlock the shares at any time, which would invalidate the certificate.
- The asset Owner can then distribute a public key for the certificate, allowing someone else to verify they own the certified number of shares
- If at any time the certificate becomes invalid, any "subscribers" to the certificate, would be notified. (And it would show as invalid in the web interface).

This way if someone here for example wanted a seat on the board, they could email a request to the Issuer, who in turn requests a verification certificate for 5000 shares. They respond with a public key. Then the Issuer can use the public key to subscribe to  the certificate, and issue board member status accordingly. If the user decided to liquidate their shares they could do so without any "delay" but the Issuer would be notified immediately that the certificate had been invalidated.

This allows validation of share ownership, and it also allows maintaining privacy of the shareholders.

+1 internets for you, sir.
vip
Activity: 574
Merit: 500
Don't send me a pm unless you gpg encrypt it.
One approach to the "who owns how many shares" challenge, (I may suggest this to Nefario if he doesn't already have something else in the works):

- Allow an asset Owner to generate a "certificate" for a number of shares. Which then become "locked" in their account.
- They can unlock the shares at any time, which would invalidate the certificate.
- The asset Owner can then distribute a public key for the certificate, allowing someone else to verify they own the certified number of shares
- If at any time the certificate becomes invalid, any "subscribers" to the certificate, would be notified. (And it would show as invalid in the web interface).

This way if someone here for example wanted a seat on the board, they could email a request to the Issuer, who in turn requests a verification certificate for 5000 shares. They respond with a public key. Then the Issuer can use the public key to subscribe to  the certificate, and issue board member status accordingly. If the user decided to liquidate their shares they could do so without any "delay" but the Issuer would be notified immediately that the certificate had been invalidated.

This allows validation of share ownership, and it also allows maintaining privacy of the shareholders.

Very nice.
sr. member
Activity: 407
Merit: 250
One approach to the "who owns how many shares" challenge, (I may suggest this to Nefario if he doesn't already have something else in the works):

- Allow an asset Owner to generate a "certificate" for a number of shares. Which then become "locked" in their account.
- They can unlock the shares at any time, which would invalidate the certificate.
- The asset Owner can then distribute a public key for the certificate, allowing someone else to verify they own the certified number of shares
- If at any time the certificate becomes invalid, any "subscribers" to the certificate, would be notified. (And it would show as invalid in the web interface).

This way if someone here for example wanted a seat on the board, they could email a request to the Issuer, who in turn requests a verification certificate for 5000 shares. They respond with a public key. Then the Issuer can use the public key to subscribe to  the certificate, and issue board member status accordingly. If the user decided to liquidate their shares they could do so without any "delay" but the Issuer would be notified immediately that the certificate had been invalidated.

This allows validation of share ownership, and it also allows maintaining privacy of the shareholders.
sr. member
Activity: 476
Merit: 250
This very early post discusses the issue a bit. With some clarification IMO.

https://bitcointalksearch.org/topic/m.1088302
"The unsold shares may be sold later, but hopefully with a higher price if we successfully produced our first batch of chips."

--

This was what I should have found earlier when I got distracted by distribution of 'extra' shares. Which are not "unsold" shares. (The extra were the 10% and 12.5% 'discounts' for large direct block purchasers.)

The difficulty I see with just leaving these shares unsold / undistributed is their 'proxy' power. Even if Bitfountain doesn't directly vote them as a proxy and they are left to abstain, any amount less than 200,000 in non-Bitfountain hands/control gives Bitfountain a greater than 50% effective vote.

But the quote above makes this situation clearly possible. And that statement was made prior to the IPO.
donator
Activity: 994
Merit: 1000
@Jutarul

Within my understanding, the way friedcat raise capital for the bitfountain is a little different than traditional. The total number of shares of the bitfountain is 400k, and no matter how many ASIC shares we purchase through the IPO, the number of bitfountain shares outstanding will not be impacted. Things happen in this way:

1. Bitfountain has 400k shares issued, which all belongs to the 3 partners.
2. An SPV set up named ASICMINER. the total number of shares outstanding is not decided.
3. Whenever ASICMINER issue 1 share, the 3 partners will sell 1 share of bitfountain to the ASICMINER at the price of 0.
4. ASICMINER will be responsible for the R&D cost of the bitfountain. if the money ASICMINER raised through its IPO is more than bitfountain need, there will be a special big dividend.
5. ASICMINER's share in bitfountain has a preference in the dividend distribution of bitfountain.

In conclusion, 1 ASICMINER share represents 1 bitfountain share, with some privilege.

Thanks for the interpretation. I suspect these things get cleared up when friedcat prepares his first report and/or releases the business plan to board members. My current understanding diverges a bit from yours, mainly because I see 200k shares issued on GLBSE for ASICMINER. Thus, in your language, the shares already got sold from BITFOUNTAIN to ASICMINER beginning of August at a price of 0. All 200k shares are in the possession of ASICMINER. Those shares which haven't been sold through the IPO to the shareholders should still be in the account for ASICMINER.
donator
Activity: 1120
Merit: 1001
@Jutarul

Within my understanding, the way friedcat raise capital for the bitfountain is a little different than traditional. The total number of shares of the bitfountain is 400k, and no matter how many ASIC shares we purchase through the IPO, the number of bitfountain shares outstanding will not be impacted. Things happen in this way:

1. Bitfountain has 400k shares issued, which all belongs to the 3 partners.
2. An SPV set up named ASICMINER. the total number of shares outstanding is not decided.
3. Whenever ASICMINER issue 1 share, the 3 partners will sell 1 share of bitfountain to the ASICMINER at the price of 0.
4. ASICMINER will be responsible for the R&D cost of the bitfountain. if the money ASICMINER raised through its IPO is more than bitfountain need, there will be a special big dividend.
5. ASICMINER's share in bitfountain has a preference in the dividend distribution of bitfountain.

In conclusion, 1 ASICMINER share represents 1 bitfountain share, with some privilege.






donator
Activity: 994
Merit: 1000
I'm sorry to hear that.

However, isn't that a commitment you made?
I'm very sorry for all the confusion. By "extra" I didn't mean leftover unsold shares, I meant
the extra shares for large investors.

Sending leftover shares proportionally to shareholders is technically very hard.
This sentence isn't a excuse for me to avoid my commitment with "technical difficulty".
It's just to explain that I understood it's very hard in the first place so my "extra shares" did
mean extra 10% and 12.5% for larger bulk purchasers, but not all leftover ones.

I'm sorry again and it's my fault to bring so much confusion in my last post of announcement.

Alright. Then the unsold shares are currently an asset of asicminer. I guess we can keep them for later use. Might be interesting to release them slowly at market value when the first batch of chips arrived and the mining operation started. This way we can even raise more capital for further chip development and production without the need to modify the volume of total shares. Alternatively the surplus of the sale could go into paying dividends.
sr. member
Activity: 252
Merit: 250
Inactive


I'd like to thank Jatarul and Horserider for their offer to sell back the shares to me.

However unlikely, I'd like to make a plea to the buyer of

ASICMINER   2443   0.00021   2012-08-23 17:00:01

To purchase those shares.
full member
Activity: 159
Merit: 100
I don't really understand what you're saying, xkrikl.
Sorry, I didn't explain well myself. I was talking more in general without stating it.
Quote
"let them have a vote in some decisions"

They have no more nor less 'vote' than their number of shares weighted against all the other shares.
Generaly it doesn't have to be so. They could be the executive board. But that would have to be stated in the contract or standing orders. That's not the case of ASICMINER also because ... see next point
Quote
"only as a communication platform"

Yes. Their only significant 'power' is the ability to 'examine the books' of the 'company'. That is, verify, or not, that Bitfountain is doing what they say they're doing.
In case of ASICMINER the executive part is in Bitfountain only and ASICMINER as whole is only shareholder and ASICMINER's board is more like Control board.
Quote

As such, they have a vested interest in 'making things look rosy'. That is, communicate good news to the community until they benefit from an inflated share price and can dump their stock. (After which, of course, they could then 'bare their souls' and tell everyone why they sold all they had. So, in a sense, they are canaries in the coal mine.)
Well that might be problem if there is only few large investors who control small part (ie. less than 50%) and a lot of small investors. In such case they could take advantage of their position but I don't expect it to be the case here as I expect large percentage of ASICMINER's shares to be owned by the board members. Anyway that would be an interesting information to know.
Quote


Really, I only see the board member position as a, reasonable, way for Bitfountain to restrict who all they need to communicate fully with while at the same time having a credible amount of transparency.

Credible is the key word here. And now that the IPO is finished, it is pretty much a moot point.

We have all placed our bets. We'll see how they come out.
Yep and I believe that this will be a success and want to thank Friedcat for the great work he's doing in managing this IPO and communicating with us.
Thanks!
legendary
Activity: 1778
Merit: 1008
i'm wondering what we're looking at for the final product. a single chip for really low cost, multiple chips, or big TH boxes...

any info friedcat?
In the first batch, we will get boards with multiple chips on each.
Single chips could be provided for sale later, when there are interested business partners.

good to hear. i'm not in any position to buy a $30,000 box, afterall... gona be lots small units bought over time here.
donator
Activity: 848
Merit: 1005
i'm wondering what we're looking at for the final product. a single chip for really low cost, multiple chips, or big TH boxes...

any info friedcat?
In the first batch, we will get boards with multiple chips on each.
Single chips could be provided for sale later, when there are interested business partners.
Jump to: