Software Developer Says Mega Master Keys Are Retrievable 136
hypnosec writes that software developer Michael Koziarski has released a bookmarklet
"which he claims has the ability to reveal Mega users' master key. Koziarski went on to claim that Mega has the ability to grab its users' keys and use them to access their files. Dubbed MegaPWN, the tool not only reveals a user's master key, but also gives away a user's RSA private key exponent. 'MEGApwn is a bookmarklet that runs in your web browser and displays your supposedly secret MEGA master key, showing that it is not actually encrypted and can be retrieved by MEGA or anyone else with access to your computer without you knowing,' reads an explanation about the bookmarklet on its official page."
Who trusts Mega anyway (Score:3, Insightful)
Re: (Score:2, Interesting)
but most people realize that the guy is a self-aggrandizing scam artist and charlatan
This. The man is just the flip side of the copyright cartel, and they're both about the same thing: getting rich by leeching off the hard work and creativity of others.
Cue a hundred Defenders of the Faith claiming that this is well-engineered incompetence, not malice, and that a hole as wide as Uranus is actually not serious.
Re: (Score:3)
Mine, I wouldn't worry about. Your mom's on other hand...
Re: (Score:1)
I've said it before and I'll say it again. Mega is simply an Internet file hosting service. It is not Kim's fault that people use Mega to commit copyright infringement. Kim's Mega business is as legitimate as any other Internet business such as Napster, Grooveshark or eMule.
Re: (Score:1)
Oh noes, the pestilent scourges, the one percent!!!!
Re: (Score:1)
If he was found in a dingy little basement with row upon row of servers. If he was still named (whatever he was called before dotcom) because he was too poor to afford the renaming fees, THEN I might distrust him a little less.
But honestly anyone with that name or house is pretty obviously trying to become part of the 1 percent, not take them down. (Or at least not without taking over their position.)
That's an unfair attack on Kim! He's not trying to become part of th 1%; he's obviously attempting to start up an alternate 0.1%....
Re:Who trusts Mega anyway (Score:5, Insightful)
Does anyone actually trust his stuff?
For sensitive material? Of course not. But, I have used Mega a number of times for legit downloads (Android ROMs, Linux, various open-source projects). Let's not forget that MegaUpload was used for non-nefarious purposes, although people who store sensitive data unencrypted on someone else's service are always taking a risk.
Re: (Score:3)
At least he's not lying about himself or his intentions. If anything, he's been absurdly honest. Just look at his licence plates, or one of his bragging pictures.
Re:Who trusts Mega anyway (Score:5, Insightful)
the guy is a self-aggrandizing scam artist and charlatan
However, if he wore a suit with tie and had not only fullfilled DMCA requests (which he always did) but also had proactively given away his customers data to any US authority and private copyright holders like the RIAA without any real legal basis and had additionally given money to the two leading US parties, he'd be considered quite a decent fellow in the US now. In other words, while he never did anything else than Google and thousands of other companies, including US ones today, he hasn't shown "the right attitude" and that is the main and real reason why he is being persecuted now. He doesn't act the way you are expected to act as a rich entrepreneur with a serious business. Such misbehavior is usually sanctioned. They even wondered whether they could turn an inflatable tank he had in his garden into some kind of evil plot, but didn't manage to find the right legal angle to it...
Regarding trust ... well, at least New Zealand law cannot force you to install backdoors and lie to everyone about it, but of course you cannot trust any closed source company with data security. Encrypt on your own before storing something on Mega and you're fine.
Re: (Score:3)
Re:Who trusts Mega anyway (Score:5, Interesting)
All those other companies gave no illusion of being secure.
Neither did Mega. They explain these very risks and others right in the FAQ [mega.co.nz] and since they launched have using alternatives that do not involve trusting them. Providing a interface is a significant convenience, but you can't trust anything truly secret to a script someone else can remotely replace on a whim.
Re:Who trusts Mega anyway (Score:4, Informative)
Proof-reading fail. Sorry :(
The missing word was "recommended". They have always recommended alternatives that do not involve trusting them. Here's an example from that same FAQ page:
What if I don't trust you? Is it still safe for me to use MEGA?
If you don't trust us, you cannot run any code provided by us, which precludes opening MEGA in your browser and entering your login credentials. However, due to MEGA's end-to-end encryption paradigm, you can safely use client applications written by someone you trust.
Re:Who trusts Mega anyway (Score:5, Insightful)
he hasn't shown "the right attitude" and that is the main and real reason why he is being persecuted now.
If you aren't a paid shill, you should change that. Your misleading and faulty argument surely qualifies, and you'd have to be an idiot to think that a multi-millionaire scam artist in the public spotlight would not have hired a PR agency to improve his online image.
Kimble is a career criminal, simple as that. He was prosecuted and even convicted before, and by several other governments. That distinct sound you're hearing is the shattered pieces of your argument falling apart.
If you are a large-scale career criminal, there are two paths you can go.
One, you can fly under the radar, like the people in the famous train robberies and serial bank breaks that many of us have heard about but almost nobody can name even one of the actual people involved.
Two, you can scale it up so much that it becomes quasi-legal by sheer scale and being-part-of-the-system, like the financial industry, the corporate corruption or the various pet-sectors of the various countries that are untouchable (Spain had a huge real estate scandal - nobody was ever convicted. Germany even has a name for the network of corporations, banks and government entities so closely connected that they all protect each other: Deutschland AG. In Greece, the shipping industry was holy for decades. In the US it is probably the military industry, and so on).
Kimble was arrogant and self-obsessed enough to think he could reach the same place simply by having an overblown ego and being audacious.
Re: (Score:2)
In the US it is probably the military industry, and so on
Nah, over here it's the financial services industry.
Y'know, the ones who just recently broke the whole system for everyone in the western world, and then got the government to pay them to make sure they didn't stop doing the same things that led to the crisis.
Dan Aris
Re: (Score:2)
So how much does the PR agency pay for a comment like that?
When someone has been a career criminal all his life, the burden of proof kind of shifts around, you know? Fool me once and all that.
Re: (Score:1)
Regarding trust ... well, at least New Zealand law cannot force you to install backdoors and lie to everyone about it,
That might have been true earlier, but I think the recently passed GCSB and TICS bills now allow it. JohnKey wanted to bring NZ laws into alignment with the US and UK... But he says you can trust him, he'll only use the powers against bad people, and anyone who disagrees (like the law council and human rights commission) just doesn't understand the new laws.
Re:Who trusts Mega anyway (Score:5, Funny)
I read this as "Sega Master System Keys Are Retrievable." I was sadly disappointed.
Re: (Score:2)
Yup. Wasn't until getting into comments that I even remembered this Mega existing.
Re: (Score:2)
Re: (Score:2)
I'm glad I wasn't the only one...
Re: (Score:3)
Does anyone actually trust his stuff?
Idiots with no knowledge of history.
Kimble ratted his partners out to the FBI when he was under investigation for a previous crime some years ago. Once a traitor, always a traitor. If you think there are no closed-doors talks between Kimble who's trying to save his neck and the government, you must be very naive indeed. And the obvious thing that Kimble can offer is - the users of Mega, of course.
Re: (Score:2)
Not me. I wouldn't host anything I didn't care about on any server he had any control over, let alone something important. The guy is a crook, pure and simple.
Re: (Score:2)
Forgetting that sometimes the uploads stick on 99%, and forgetting that some files timeout at random times and restart the upload from 0%, it's a really nice place to store 46gb. The up/down speeds can't be grumbled at either.
I couldn't give a flying shit if they are encrypted, nor do I care if they are ever deleted. I have local copies.
What am I suppoosed to be trusting again?
Kim DotCom gives me a large amount of fr
of course they are retrievable (Score:5, Insightful)
Once you enter your password into a website, the website can do anything that you can do.... Duh
Yes, mega doesn't have your key stored on their servers.
Yes, at any point while you're logged in they can change this fact, or they can just log your password, or whatever.
Doesn't matter what the website is, you have to trust it to use it.
How is this news?
Re: (Score:2, Interesting)
not to troll but this may be a new tactic by Big Media or maybe the NSA to try and cripple Mega and others, I find it odd, (tho I do not make an conspiracy out of it) that the NSA is attacking owners of sites that refuse to give up there encryption, and the owners/creators are shutting there sites down.
It is possible and wouldn't be surprised to see someone or some sinister force at work here. But I am not sure if the creator of the exploit is supporting Mega, and trying to improve its security or trying to
Re: (Score:3)
"I don't know all the software, firmware and hardware functionality perfectly, therefore I throw my arms in the air and give up."
Security is often as much about trust as anything. It is important to expose, more than anything else, something which could suggest a breach of trust.
Re: (Score:3)
Well, there's your problem... Why are you letting people you don't know install and run software on your computer?
Fundamentally though, like all security, you need to make a cost benefit analysis. If you have data of a life and death nature, you shouldn't be entrusting it to anyone you can't kill. Or a little less extreme, you shouldn't be putting information in the hands of someone you can't successfully sue. That is, i
What's the big deal? (Score:5, Insightful)
Re: What's the big deal? (Score:1, Interesting)
i fixed this problem on my project using javascript closures. your private keys are decrypted with your password. password is never uploaded to the server. you can see that by looking at the post requests. the decrypted key is stored in a local variable for activities the rest of your session. closures are secure. no program outside the function scope can access the keys or password. its tricky to get right so maybe Mega can fix it soon.
Re: (Score:1)
Still everyone has to trust the site to not deploy malicious javascript. That's why this concept is fucked up ...
Re: (Score:2)
i fixed this problem on my project using javascript closures.
How does that fix anything? Every time I visit your project, I must rely on your java script. The fact that it is correct today does nothing for me tomorrow.
A secure solution requires that there is nothing you can do to get my key.
You could simply change the java script on your site tomorrow, and slurp the key next time I visit.
Essentially one has to decouple the client from the service, so that I use a client YOU DON'T CONTROL. That is the only
Re: (Score:2)
A real fix to this problem would let me download the js and html and whatnot once, as a signed archive, and use your application from a file:// url on my computer.
In other words, the only thing that would come from a server from session to session is the encrypted data file. No application code. No HTML. Just the data.
It's a lot more like a traditional application, except that it runs in the browser and the source code is right there for me to look at.
Re: (Score:3)
Yeah, I saw this tool was already built in to Chrome, so I guess I've had the hack for a while - even before this guy released it!
what's odd about this? Your key is local (Score:5, Informative)
That's how you want it to be. It's zero-knowledge from MEGA's point of view. You generate your own key, keep it and use it to decrypt and encrypt stuff.
So of course if someone gets access to your computer they can get your key, it was on your computer all the time, by design.
His assertion that MEGA can get your key is what is a bit more surprising. But if you read it, he's simply saying it's conceptually possible that MEGA could use a script on their site to grab your key and send it to them. This is of course possible, but we have no way to know whether they've done it. If the javascript can access your key to encrypt/decrypt stuff, then it is also possible it can squirrel it away somewhere.
Re: (Score:3)
His assertion that MEGA can get your key is what is a bit more surprising. But if you read it, he's simply saying it's conceptually possible that MEGA could use a script on their site to grab your key and send it to them.
And you think this isn't serious? Every vulnerability is "conceptually possible" until it's implemented. NSA/FBI/local bobby want to see what you've been using Mega for? Slip in a one time bit of Javascript to a page delivered by Mega, and it's all theirs for the reading.
Perhaps you don't even understand what Mega has been promising up to now.
Re:what's odd about this? Your key is local (Score:4, Informative)
As far as I can tell there isn't any other way to do it. If Javascript needs access to that encryption key then of course it is possible to send that key anywhere else. It sounds like there is some client-side encryption that takes place before sending files, and that encryption code presumably comes from Mega, and that encryption code uses your private key, so of course the encryption code has access to the key. How could it encrypt otherwise? The browser doesn't natively support that process, that is what would have to change in order for this to not be an issue. The promise by Mega not to store your keys is the only thing that users have, because if they are running Mega's encryption code client-side then there is nothing stopping Mega from getting your keys, or unencrypted data, or whatever else, other than their promise not to.
NSA/FBI/local bobby want to see what you've been using Mega for? Slip in a one time bit of Javascript to a page delivered by Mega, and it's all theirs for the reading.
Again, the onus is on Mega to stop that from happening, but they can only protect their own servers. If someone wants to intercept and decrypt your traffic and change the data to add new code (a man-in-the-middle attack), then that is still a threat. It's always going to be a threat as long as organizations like the NSA are capable of decrypting that SSL traffic.
Otherwise, this is not an issue that has a solution with today's browser implementations. Maybe Mega can produce their own version of Firefox or a Webkit-based browser that will natively implement their encryption without exposing the keys to Javascript, but then you would have to trust that software, don't you? It's all about trust. If you don't trust Mega, then don't use it.
Re: (Score:2)
By using a proper browser plugin rather than a crappy Javascript implementation, perhaps?
Yes, it is all about trust: companies ask you to trust them, then their reputation is built or broken. Evidence for either is welcome.
Yep, exactly .... (Score:2)
I'd agree that this is not really a vulnerability in the traditional sense.... but under the circumstances, Mega should (IMO) do more to convince customers the data they store there isn't going to be viewed by any 3rd. parties.
Ultimately, I suppose a custom browser plug-in could be written which would divulge your secret personal key, too. But I'd rather see a less trivial process to upload a user's key than some basic javascript making it possible. (Otherwise, it's too easy to trick a user into visiting
Re: (Score:2)
The promise by Mega not to store your keys is the only thing that users have, because if they are running Mega's encryption code client-side then there is nothing stopping Mega from getting your keys, or unencrypted data, or whatever else, other than their promise not to.
It is likely that this was an intentional design flaw, introduced at the behest of one or more government agencies (I didn't say which government, and you shouldn't assume!). You'd be surprised what threats of torture, destitution, or prison, can do -- especially to someone like kim dot com, who is used to a higher standard of living. You can't really threaten a poor person; Government long ago learned to forget that strategy and instead go after their family and/or lover. But a rich person? oooh, so very m
Re: (Score:1)
Except who owns the TPM MASTER KEY?
TPM is not and never will be a secure method of key storage. It's just another form of Key Escrow.
Re: (Score:2)
That's irrelevant in this particular situation: the TPM is merely being to securely store a key and use that key -- entirely within the TPM -- to encrypt or decrypt data. The TPM could (and likely does) store other keys that aren't being used for this particular task, but that doesn't matter in this scenario. Although TPMs can be used for various purposes, in this case it'd be used like cryptographic smartcard or HSM.
Are you aware of any way of retrieving a private key stored on a TPM by any means other tha
Re:what's odd about this? Your key is local (Score:4, Informative)
As far as I can tell there isn't any other way to do it. If Javascript needs access to that encryption key then of course it is possible to send that key anywhere else.
At present, this is true. There's a W3C WebCrypto spec in progress (being developed by Google and Mozilla, IIRC) that will change it, though. It will not only provide native implementations of ciphers accessible from Javascript (rather than performing expensive calculations in Javascript), but will also provide a client-side key store so Javascript code can create and use keys without ever seeing their value, and hence be unable to send the values anywhere.
I think the Javascript code would still have access to the decrypted data.
Caveat: It's been a while since I looked at the in-progress spec. It may have changed, and I guarantee my memory is faulty in at least some respect.
Re: (Score:1)
There's a W3C WebCrypto spec in progress (being developed by Google and Mozilla, IIRC
So its being implemented by the two vendors who slip in silent updates faster than my sister spreads her herpes? This really isn't any better when they can just silently send you an update to relay your keys off to them. You've been trained to accept their updates without thinking about it, good job, same problem.
Re: (Score:3)
Just like your OS vendor can slip in an update that sends all your keys to them. (As Shuttleworth said, they have root.) You basically need to trust someone, as no one person is able to audit everything people typically use daily.
Re:what's odd about this? Your key is local (Score:5, Insightful)
The issue is that it's 'conceptually possible' for Ubuntu to ship a package in the base system that uploads your keys to Canonical's servers. I can give you a script that you run on RHEL and it'll show decrypted ssh, ssl, and gpg keys (if you've entered the password). I can put a package on your system and show that RHAT could put a modified gpg that logs all your shit and passwords and everything to their server. And so on.
This isn't a vulnerability. It's like saying it's conceptually possible for a thief to steal your car after you've put the key in the ignition.
is it serious? More how serious are you. (Score:2)
It's not a question as to whether it's serious. It was always the case and could be assumed to be the case. If the JavaScript can get to your key to use it to encrypt/decrypt, it can also possibly upload. It's part-and-parcel of the design.
I pointed this out when MEGA was first announced. There always is the possibility of a system squirreling away your keys. You cannot design it out in software. The software reconstructs your key at some point, you then have to trust it discards after using it only for the
Re: (Score:2)
Or at any time Mega can sneak in a bit of extra javascript to send them your key too. How many people actually audit the javascript every time they visit the page. It's the main reason why client-side encryption is bullshit. It just adds extra vectors of attack, rather than makes things more secure.
Re: (Score:3)
When the method is javascript in the browser; sourced from the very same service you are sending the encrypted data off to than yes; client side encryption is BS and probably offers so much attack surface it reduces security.
The fundamental problem here is you are running 'untrusted code' to handle sensitive information. There is a solution here. A small simple OSS program easily audited. Probably needs to be real real basic command line utility using few if any external libraries so people can post the
Re: (Score:2)
Yes, or an actual browser plugin/extension which will let you do proper sandboxing and code signing.
Re: (Score:2)
Or the code comes from a known-good set of files on your local drive, and only the encrypted data is transferred to and from the cloud.
HTML + CSS + JavaScript files == open source. As long as you load them using a file:// URL you can know what exactly you're getting.
This is preferable to an extension which is a) compiled and b) could access every page my browser visits.
Re: (Score:2)
I respectfully disagree. This almost needs to be a pure C implementation and like I said use few or no external libraries. Java script and HTML renders are big beasts. You can't possibly audit them as an end user. Yea the C compiler is to big and complex for most people to practically audit as well; hence what I said about posting md5sums, so you have some verification if imperfect that your compiler is producing output that really corresponds to the input code you just audited.
Re: (Score:2)
I it can display it to you, it can post it to the server.
Summary (Score:5, Insightful)
Unless Im misreading it, this can be summarized as follows:
* Coder has discovered that, in order to encrypt data, your computer must have access to the encryption key
* Further, if someone has root access to your machine, they can get your encryption key.
Wow. What a discovery.
MEGA and anyone else with access to your computer can see this, and use it to decrypt any file you upload.
Wait, someone with access to my computer has access to things that my computer has access to? WOW!
Re: (Score:1)
Only if you define "someone with access to my computer" to include "anyone who runs a web server I visit".
Re: (Score:2)
Pretty sure such an attack would qualify as a cross-site scripting vulnerability.
Re: (Score:2)
Only if you define "someone with access to my computer" to include "anyone who runs a web server I visit".
The article doesn't say that any web site can access the key, just the browser itself (via bookmarklets or third-party extensions) and Mega. Both of which are obvious.
The browser prevents sites from accessing other sites' local data. It would be interesting if they managed to find a way around that protection, but they didn't. The system is working as designed.
Re: (Score:2)
Eh, you could easily write a plugin which doesn't allow any Javascript to access its private data. It might involve platform+browser-specific implementations, but doing things right isn't always easy.
Re: (Score:2)
I don't disagree. My own preference would be an open-source native client with no ties to the browser, something stable which can be audited and won't be replaced every time Mega updates their web site. However, the existing system isn't exactly handing the key out to every web site you visit, just the components which are expected to have access to it. It's about as secure as can be expected of a plain web app.
Re: (Score:2)
Do you have any idea what you are actually talking about?
One thing that we can be sure of is that I know how to use the subjunctive mood, while you've probably not even heard of it.
Re: (Score:2)
"Only if you define "someone with access to my computer" to include "anyone who runs a web server I visit"."
That definition works, if you are foolish enough to enable javascript.
Re: (Score:2)
And foolish enough to run a browser which doesnt prevent cross-site scripting attacks.
Hey, if your browser allows random websites to pull all of your cookies, your login sessions could be compromised! Except, they do restrict that.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
"If you do not enable javascript, you cannot use Mega."
And that is indeed my point. If it wont work when you turn javascript off, it isnt a webpage, and it definitely cannot be trusted.
Re: (Score:3)
Re: (Score:2)
Indeed. If you want to store encrypted files, then encrypt them locally before uploading them.
Re: (Score:2)
That is what is happening here. Just from reading the article, I can see that the key is using local browser storage, which is used to encrypt the data and upload to Mega. Mega is NOT doing the encryption (thats the entire point of doing it in JavaScript).
Re: (Score:2)
Just from reading the article, I can see that the key is using local browser storage
Which is about as secure as storing the key in /var/www.
Re: (Score:2)
What I'm saying is that if you don't want your files to be seen, then you encrypt them outside of the browser before uploading them. If you're encrypting them in the browser then that's a vulnerability. The browser can encrypt the already-encrypted file if it wants to, if anyone decrypts it they're just going to get another encrypted file back.
Wrong. Mega is doing it. (Score:3)
Emphasis and clarification added. The problem isn't that the files aren't getting encrypted before upload, it's that *you* aren't doing it. Your browser, executing JS code from mega.co.nz, is doing it. You aren't even running the encryption program yourself; it's all automatic. You are handing Mega an un-encrypted file, and trusting them to securely encrypt it against themselves. Does this sound stupid yet? Let
Re: (Score:2)
Yes, basically there's no way this security model works. Their promise is that they give you client side software (java script), the software does all the magic on your end, then gives them impenetrable black boxes. That's it.
Microsoft EFS promises that Windows doesn't upload your encryption keys to microsoft.com. Apple's encryption tools, same. PGP and GPG, same. We really really promise we don't send your private keys to home base, then add back doors to your computer and come snooping your filez.
Re: (Score:2)
Mega uses an open-source java script thing, you can check the source. It's not free, but you can see the source.
TPM is supposed to cover this--if you can audit the TPM design and say that this model TPM is secure, and can guarantee that the TPM in there is of that model and not another model. We can narrow the threats down to hardware or software--an operating system service that manages keys, for example, and must be communicated with to act. That means that whoever wrote the service could be a bad g
Re: (Score:2)
There's a fundamental problem in all of this generation's encrypted storage: the server should never know the key, but the software now used to transport the file to the client is also the decryption software and is made by the company operating the server, so you have to trust that they aren't just phoning home your key and reading your precious files.
Thats true, but I believe that horse has already been beaten to death.
The claim HERE is that anyone can grab the key, which is just a stupid point to make: Its only true in situations where all security bets are off anyways (ie, youve already been rooted).
Federal Reserve creating magnittude inflation? (Score:2)
Re: (Score:2)
Did you hear about the Mega Man reboot?
Re: (Score:2)
I find it extremely annoying too.
Problem is dedupe (Score:2)
The problem with storing data in the cloud with encryption from the providers standpoint is that you can't use dedupe on it. Dedupe can make an extremely large difference in the amount of storage that you have to buy and run. From an operational costs standpoint the difference between running a data repository with and without dedupe could easily be the difference between running at a profit or a loss.
The service provider has a very strong financial incentive to use dedupe technology. The problem is that th
Re: (Score:2)
There is a way to do dedup without having the key.
For example: the client takes an SHA256 of the data, then encrypts the data it with the lowest 128 bits of the SHA1, uploads the encrypted data to the server saying "this data has id ". The lowest 128 bits are then encrypted with the client key and uploaded as well. This way another party with the possession of the same data gets the server to merge their data (but the key still keeps hidden from the server). Servers makes an SHA1 sum of the encrypted data s
All backup sites have this problem (Score:1)
I worked for a company that wanted to offer secure cloud backup. A crucial requirement was that the company would never have the encryption key, and we went to significant lengths to do that. But the users wanted a way to download their files from the web. Well, how were we supposed to send the user a decrypted file if we didn't have the decryption key? Solution: The user must enter the key into the web app, then the server decrypts the file and sends it to them. So now, in theory, the company could si
Obvious (Score:3)
So this is obvious to anyone with knowledge of encryption. I believe Mega's claim is that because the encryption is done on the client side, they don't know the key. This could be true, but you still have to take their word for it.
But even though it's obvious, it's something to consider. Mega claims that they could not decrypt your files. This is demonstrably false. So what's to stop the government from serving them with a National Security Letter that forces them to add code to the login process, logging all keys upon login, without any advance warning to their customers?
There's essentially no way to trust a third party on the internet now without an alternate, reliable channel of communication to exchange keys in the first place.
Re: (Score:2)
So what's to stop the government from serving them with a National Security Letter
He's not in the USA and never has been?
Re: (Score:3)
> Mega claims that they could not decrypt your files. This is demonstrably false.
Not quite.. It requires all these things to happen:
1. Mega gets a reason to get your key (LEA for example)
2. Mega adds new JS just for you
3. You use the web interface
4. You log in
5. You don't notice the new code (Mega already have a chrome browser extension that would stop this by running its own code instead of the server's code iirc)
So.. They have to start looking for your key, you have to use the *web interface*, AFTER th
Fuck it (Score:1)
Wow... (Score:2)
I cannot be the only one (Score:3)
I read the title as "Software developer says Sega Master keys are retrievable".
Re: (Score:2)
That's why (Score:1)
fnord (Score:1)
The first time I read the headline it said "Software Developer says MegaMan Master keys are Retrievable" so I thought it in regards to was some kind of ROM DRM. Second time I read it, it said "Software Developer says Sega Mega Keys are retrievable". So I googled Sega Mega only find that the Sega Genesis (or some variation) was marketed with that name in some parts of the world. This made some sense, although didn't really seem to belong in YRO. Is my mind deteriorating faster than I expected or is the Illum
What's new? (Score:2)
Groundbreaking? I think not. (Score:1)
Re:JavaScript not secure? (Score:5, Informative)
yeah something you run on your browser.. ..that gives you access to the files.. CAN GIVE YOU ACCESS TO THE FILES.
wow what a shock! because in this case, MEGA can alter the js so that they get the keys. how this is is news I don't really get. it's just common sense.
the real question is, are there 3rd party mega clients that are not javascript or subject to changing without notice..
Re:JavaScript not secure? (Score:4, Insightful)
yeah something you run on your browser.. ..that gives you access to the files.. CAN GIVE YOU ACCESS TO THE FILES.
wow what a shock! because in this case, MEGA can alter the js so that they get the keys. how this is is news I don't really get. it's just common sense.
the real question is, are there 3rd party mega clients that are not javascript or subject to changing without notice..
What is common sense to anyone who understands how a service is built is not necessarily common sense to those who use it.
So it matters.
Re: (Score:1)
the real question is, are there 3rd party mega clients that are not javascript or subject to changing without notice..
Not if you disable auto-updates from Mega.
Re: (Score:2)
What the hell is mega, other than a prefix?
Re: (Score:2)
Re: (Score:2)
The bright thing in front of you is called a computer monitor. It displays information from your computer. Your computer is a machine which can execute instructions, called "programs", to compute or manipulate data. The output of these programs is typically displayed on the monitor. The inputs to these programs, and most of the programs themselves, come from a variety of sources outside of your computer. These sources include yourself, other computers which your computer is connected to, and data storage de
Re: (Score:2)
"Mega" is a file sharing site, started in place of the now-defunct MegaUpload, purported to be secure against even themselves. This article is to show that there is exactly zero effective security against data breaches by Mega.
A "bookmarklet" is a bookmark that rather than storing a URL, stores a snippet of javascript, which gets run in-place on the currently loaded web page, altering it in some fashion. Think GreaseMonkey, but without the framework to automatically run the scripts on certain sites.
sshfs (Score:2)
Re: (Score:2)
Re: (Score:2)
I got your 3:
3) Call them out on their bullshit tactics and techniques