skolor

Have we seen malware ripping keys out of memory? It seems a stretch to think that making this slightly easier to do will result in it being more widespread. What reason does malware have to do this that isn't better served by DNS Hijacking + installing a root cert?

The difference looks fairly consistent:

Febuary 1995: U6 is 183% of U3.

Febuary 2000: U6 is 175% of U3.

Febuary 2004: 173%

Febuary 2006: 155%

Febuary 2007: 182%

March 2008: 178%

Febuary 2009: 183%

March 2010: 172%

Febuary 2011: 177%

Febuary 2012: 180%

March 2013: 184%

Febuary 2014: 188%

There quite a bit of variance, but it seems to be seems to have been consistently in the 170-185%, with a few outliers.

The clever part is getting the startup repair command prompt with no additional tools. Its similar to the old windows login bypasses (https://i.imgur.com/fqjnKh.jpg) in that it gives on more tool to use for pentesting.

I'm a little unclear what "success" is. Does the quote just mean within 18 months 50% of employees have left the company? Surely it doesn't mean that 50% of employees are getting fired after 18 months. A median employment length of 18 months seems low but ultimately within a reasonable range to me.

To expand on it, its also a security thing. Having my phone with a network of personal contacts and my computer with more work related data means a separate of attack surface.

At this point, if you have anything worth securing, its probably a good bet that your device will get compromised in the next 5 years. Compartmentalized devices helps with that significantly, since it means only partial compromises.

Even if I had a full scale performance in a cell phone with great docking capabilities, I probably would rather have a separate desktop computer for working. Just being able to compartmentalize "social stuff" on my phone, and "work stuff" on a desktop tends to vastly improve my performance.

That could quite possibly just being taking advantage of the torrent block downloading. Normally you download blocks based on the least available, but you can pull them in any order you want. This would allow the server to selectively buffer whatever you need fairly quickly.

That said, its likely that they're cacheing.

> run more exit nodes (which are depereately needed -- about 1k nodes for 2M users)

What is the ideal ratio of exit nodes to users? It seems that too close to 1:1 is going to be almost as bad as too few nodes, at least to my (not particularly well versed in Tor infrastructure) thinking.

Looks to me like they're just using Kali. Not that surprising, for someone doing that type of work.

Looking at it again, you're right. Its definitely from the case files.

The way I read that was that the phpmyadmin screenshot was not supplied by the FBI, rather it came from Krebs for the purpose of demonstration.

Really? While you can argue that the bill might not do as much as you want towards cutting back the surveillance available, 1/3 of the sitting Congresspeople cosponsored a bill to reduce the abilities of FISA/FISC [1]. It has significantly more sponsors than things than the recent SSA ammendment (116) [2] and "Life at Conception Act" (132) [3].

Sure, its not a "Defund the NSA" bill, but it is an effort to curtail some of the most objected to content from the Snowden stuff, and a pretty large number of politicians supported it, presumably without repercussions.

[1] https://www.congress.gov/bill/113th-congress/house-bill/3361

[2] https://www.congress.gov/bill/113th-congress/house-bill/4190

[3] https://www.congress.gov/bill/113th-congress/house-bill/1091

Do you have a solution to that?

It seems like an intractable problem. If you want moderated conversation, there is the potential for moderator abuse. The same is entirely possible on HN, 4chan, or any moderated forum.

Its because the result of buying from a terrible baker is I might get food poisoning. On the other hand, a terrible taxi driver could very easily get me killed.

The regulations in place don't do a huge amount to fix either of those problems, but having something in place makes people feel better.

The kind of person I can see maintaining Truecrypt for a decade I can also see making this decision. They're upset and are completely done with the project. They take down all the old versions, knowing that the licensing means they're largely useless for purposes of forking (unless you want to violate the licensing, which causes questions to the validity of the fork). Despite their frustration with the project, they still deeply care about crypto and keeping their users secure, so they publish some brief recommendations on alternatives, and release a read-only version of their software to support it.

There are any number of possible vulnerabilities that could exist. Its definitely a plausible possibility. I could fairly easily believe that they were contacted by a researcher who was about to publish a major AES flaw, or one of the other algorithms in use.

There's a number of relatively plausible theories. I wouldn't be surprised if we don't find out for 20 years what the actual reason for this was, when the developer is on their deathbed.

Considering the licensing, its likely that the developers wanted to keep development to themselves, and never turn it over to someone else. If the ragequit theory is correct, its fairly reasonable for them to remove the previous versions to make a fork slightly more difficult, especially since it would be an illegitimate fork.

That's a fairly trivial check to make. I would be fairly shocked to find out that people have discovered multiple sidechannel attacks against Bitlocker to leak keys out (if you have physical access to the machine while the disk is decrypted), and didn't manage to catch the fact that the key was getting sent over the network.

The more plausible potential for Bitlocker being broken is that there is some subtle flaw in their crypto implementation.

That's effectively the same thing as releasing details of the bug. It would take time to take the patch and figure out the bug from it, but it would be fairly easily done for a determined attacker.

Consider the case where the hacker gets in and sits on a machine that processes cards for a week. With bitcoin, the only people who would lose money is Dish, the users wouldn't have any direct effect.

> Should a prosecutor be allowed to prosecute a case if he doesn't understand the actions taken by the prosecuted?

Yes.

There's no reason a prosecutor needs to understand the details of exploit development in order to prosecute a case related to it. A hyperbolic comparison would be to claim a prosecutor needs to be able to build a nuke if they were to prosecute someone who built one in their garage. A more apt comparison might be:

Suppose Weev was the first person to discover bleach+ammonia = toxic gas. The prosecution is trying to demonstrate that this was done intentionally, using techniques that are well beyond the average person. An equivalent quote would be

> "He had to purify the ammonia. He had to use a centrifuge. He had to do all sorts of things—I don’t even understand what they are."

I seem to remember quite a bit of hubbub recently about how meta-data related to communication could be useful, even if you couldn't get the content of the communication.

Now I see a proposal for a "Secure email", which involves giving an additional third party access to that meta-data.

Correct, but that doesn't make the statement of the causes for SQLi any different.

That's exactly what defines SQLi. Incorrect filtering of user data is precisely the reason why SQLi is a vulnerability.

Its also more dangerous in the US. Since the majority of major web apps are hosted in the US, if you're in the US it is easy for the app's owners to go after you legally. It gets much more complicated if you're in another country. For example, if weev had been in eastern Europe, it would make it much more difficult for ATT to go after him.

What? Encrypt it on your system, store the encrypted blob there. Add a simple web server to host them.

If you do any crypto on these servers, obviously anyone with physical access could compromise it (although potentially not without alerting you that it had been).

I haven't used Firefox seriously in a while, but the shift+F4 shortcut looks fairly similarly to the Chrome developer console (F12, select the Console tab). It looks like the Firefox shell is more designed for making new pages though, while the Chrome one is more for debugging the current page.

Pay-for-security is a bad path to go down. Compare pay-for-ssl to using md5 on the lower tier for password encryption, while the upper tiers get something like bcrypt, or you only get a salted password if you pay extra.

It seems pretty absurd to require a payment for security, especially when you're implementing it for a subset of users. Its true that SSL is going to be more taxing on their servers, but the majority of the cost is going to be spent getting an engineer to implement it, rather than the actual operational costs.

I searched around a little bit, since I found the lack of details somewhat disturbing. This is the best I found: http://www.seattlepi.com/news/article/Facebook-hack-lands-UK.... From the sounds of it, he broke into an employees account (likely their work computer, possibly further access). I'm speculating, but that makes it sound like he stole some portion of the Facebook source code, coupling that with the "intellectual property" claims.

I'm curious about this line, towards the bottom:

   his intention throughout was to contact Facebook in due course when he had rectified their problems

I'm fairly sure most people kick around ideas like this at some point or another. It would definitely be cool to give a try.

It does have the problem of playability. How do you keep someone's interest beyond a week or two of this?

My thoughts on the subject have lead to something like this:

Create a fairly persistent world. This means that any action a player can make will be permanent in the game. It can be something fairly simple, a grid based game, maybe some resource management. I like the idea of a turn based strategy game, with ~30s per turn.

Create a point system. How points are won doesn't really matter, but make it something interesting. Point reset every week. When they reset, the person with the highest amount of points gets to make a new "rule". This could be anything from a new ability for a unit to a change in the way the physics work. It (obviously) has to be tested and verified, but would be deployed relatively quickly. This process iterates for as long as desired.

Obviously a number of iterations will cause problems of complexity eventually. My thoughts on the matter have led me to a rather specific idea for a game of this type, which I think would be incredibly enjoyable to play.

If you're interested, send me an email. I'd be happy to send you a more complete description of my idea, and if you still like it I'd be up for trying to implement it. That is true for anyone, not just the OP.

I'm not sure how well you would get ZFS working on it with so little RAM, although it may work better on OpenSolaris.

On the other hand, I've got an Intel Atom processor, running with 1gb of RAM, and it runs ZFS reasonably well on FreeBSD. Mind you, this does have a much larger footprint, although it does have some advantages (mine has 3x sata ports built in, plus a pci and pcie port for more if I wanted, plus a dual core 1.6ghz processor). It was only marginally more expensive ($80 for the board/processor, $15 for the ram, spare PSU and case).