I want to know how secure is the data sent to the server via meteor.call method bcz all my sign up data including username and plain password, I’m sending through these methods only.
Is there any way to see the data that is sent via methods?
How can I make my application more secure?
What methods or packages help me to improve the data security?
Any articles or blog posts that I can read about security in meteor?
You could start off by serving through https.
I use https to serve my application, but my question is, How is the data sent to server is secure?
In https the data is secure as the protocol (TLS, not the Poodle infested SSL3.0). The data are encrypted in transit and useless if intercepted. The concern is plugging the vulnerabilities in the client and with the data-at-rest on the server. Anyone wishing to obtain sensitive data would use ways and means much simpler and far more effective than intercepting the data in transit over TLS.
Like what for example? Could you elaborate a bit? I am curious as to what we have to secure our apps against.
One way to generate session keys/token for unique user, auto-regenerate different tokens on each form submission to prevent CSRF and invalidate any pending post data if the token is expired (configured by minutes or hours).
Using the same feature from Laravel PHP framework, we can create “tokenkeys” collection in MongoDB for maintain user activity. Is this feature support in any package?
If you are using https, the data is secure between the client and the
server. And once on the server, the accounts-password package (if you
are using that for your accounts system) already keeps the passwords in
a format that you cannot decrypt.
But if you are using your own accounts system, you need to take care of
the secrets as you would do in any other application.
I am talking about the hacks based on obtaining user credentials with a phishing attack or social engineering. For example, the recent Anthem breach (80MM health records stolen) took advantage of a name change in the company (formerly WellPoint) and set up a bogus site with a similar sounding name but the L was replaced with a 1. They eventually got a sysAdmin at Anthem to login to the fake site and then they had the necessary credentials to login and start copying unencrypted records to a cloud storage location at a slow enough pace not to alarm other indicators. It was finally discovered when the sysAdmin noticed a recent login that they knew they didn’t make.
Another is exploiting zero-day weaknesses that are published at the time of software release. The Target point of sale exploit took advantage of a known defect and exploited it with a vendor login having decreased privileges but sufficient to put the skimming software at the point of sale. Many exploits are remarkably successful months after a fix is available. For instance - the SQL Slammer worm in 2003 shut down the internet within 15 minutes of being released by exploiting a published weakness that had been known for months. Too many users failed to patch their MS SQL Servers and MSDE instances and the rest is history.
Very few breaches are the level of sophistication you see in stuxnet - which is still a problem for Microsoft and IE. That virus targeted a specific Siemens PLC known to be used in Iranian nuclear processing plants. Since they did not adhere to what nuclear engineers refer to as “separation criteria” all of their PLC’s were incapacitated. (Separation criteria would dictate that two channels in every critical system use separate technology and are physically separated). For us, there are a few single points of failure that could cause problems - namely, a worm in MongoDB or nodeJS would shut us down. An extremely high reliability installation would use CouchBase (for instance) on AWS as a backup to mongoDB running on a Windows Azure VM - both “channels” using separate technologies, ideally.
But I am not a security specialist. I do rely on Krebs website for the latest on what is happening in security issues.
Security is vast topic and how Meteor handle it differently compared with other frameworks.
PHP and similar frameworks process pages over server. But Meteor does not do that.
Meteor also do not use cookies.
So, we can safely say, Meteor is safe from CSRF.
What meteor does is, it authenticate a DDP connection by passing user credential over the wire.
So answer to @noname is to use SSL. So, no one in the network can see the password and any other traffic.
(data is also send over the same WS connection)
Hope that answer your question.
Have you created your own Meteor.method to authenticate a user, or are you calling the existing login method with a plain text password? You can hash the password by pulling in the internal SHA package, used like this:
{
user: {email: 'test@user.com'},
password: { digest: SHA256( password ), algorithm: 'sha-256'}
},
For login I’m using existing loginwithpassword method but for sign up I’m sending plain user password to the server. Is it safe or do I need to hash that? If I need to hash how to pass it to createuser method as it hashes again(I don’t know exactly,I feel create user method hashes the password That we sent)
Check the source code if you want to see what happening in those methods. I’m pressed for time right now, but here are some bits to check out, which includes how the hashed password is decrypted prior to bcrypting for the db.
@noname - if you are concerned about password security you really should consider biting the bullet and using an OAUTH provider. Meteor makes it really simple - I was up and running with Google ID and Github in less than 30 minutes. The nice thing about that is you aren’t storing the password. Open ID Connect is emerging as the prefered ID management. In fact, the various government task forces looking at health records security are already pushing Open ID connect as the preferred mode.
If you are talking about sending a nonce to the server, unencrypted, that is a different matter. And it isn’t stored anyways (thus the “once” in “nonce”. Besides, it is over HTTPS so it is encrypted.
One thing to keep in mind (even over SSL) is that the server method has to do security checks before supplying sensitive data to the caller, since it can be easily accessed from any client that knows the method exists and that uses DDP (which could be from anywhere). Server methods are essentially a DDP API and will be as secure as you make them. Don’t think of them as private methods to your application.
Hi Rhyslbw,
It is a very old post. but I still have to say that, you have inspired me to start look into the source code. However, I couldn’t find how the Sha256 was decrypt in the source code.
Also , I think even if password is encrypted by Sha256 and send over internet, and it still can be not called ‘safe’ because the encrypted password can be encrypted anyway in less than a second. (check this out http://md5decrypt.net/en/Sha256/ )
I am having the same question as the creator of this post now. And now i think the best option is just to implement SSL, because it simply encrypts all traffic. So it doesn’t matter how passwords are shared between client & server.
Password is encrypted because that’s a web-standart.
Both user and server don’t need password to be stored at server at all. So password is NEVER decrypted.
Only its hash its matched against stored on server, so there’s pretty much nothing else to encrypt that way.
Some apps make use of reversable encryption to make these branded chats where servers can never decrypt data they store, and only those with key are able to decrypt it. But SSL propose is different, it serves against MITM attacks and sufficient for ~ 95% cases, in case both server and client considered “trusted” sides, and only malicious intuder(for example - an owner of Mc.Donald’s WiFi spot) considered dangerous to take advantage of it. So, if your question is put simply SSL in a modern world is both “enough” and “must have”.
[quote=“donyang, post:16, topic:1796, full:true”]
Also , I think even if password is encrypted by Sha256 and send over internet, and it still can be not called ‘safe’ because the encrypted password can be encrypted anyway in less than a second. (check this out http://md5decrypt.net/en/Sha256/ )[/quote]
What they’re using there is called a Rainbow Table. That’s not the same as decryption. They simply have a huge database of hashes, that’s all.
And such a table becomes utterly useless the moment you’re using a salt.