Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to make my REST API more secure. For the moment I'm hashing my password in my angular app with CryptoJs.SHA256 before sending it to my C# backend. But I realize it's better to hash password on server side. So how can I send a password only readable by the server? I'm going to add SSL but I know HTTPS is also breakable. Is there an other solution?
Thanks
As Bruce Schneier says, "Anyone can design a cipher that he himself cannot break. This is why you should uniformly distrust amateur cryptography, and why you should only use published algorithms that have withstood broad cryptanalysis."
While nothing is 100% unbreakable, breaking HTTPS is significantly harder than breaking a homecooked security scheme made in JavaScript. Consider this: if you serve your super-secure JS over an untrusted (HTTP or HTTPS-with-invalid-certificate) connection, what prevents the attacker from substituting a broken version, which will bypass all the JS security? Nothing.
Modern browsers are going to great lengths to prevent HTTPS from being broken (with HSTS etc.); so it's significantly safer to rely on HTTPS (which can provide actual security when used correctly - "just ignore all those big red errors" is one simple way to break it) than on JS-over-HTTP (which only provides a feeling of security without an actual chance of being secure).
Further reading: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
https://security.stackexchange.com/questions/3921/why-do-some-people-really-hate-security-via-client-side?rq=1
https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side
There are a lot of sources out there on this topic, but few have actually analysed it. As a general rule, trust guidance from Thomas Pornin more than anybody else. I also highly recommend my own survey and recommendation on the topic.
Not exactly a fullblown answer to your question, but i'd start by looking into using a KDF (Key Derivation Function) rather than just hashing your secrets. Some KDF libraries that you can look into are:
PBKDF2
bcrypt
scrypt
https://en.wikipedia.org/wiki/Key_derivation_function
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
This question is more about web architecture than actual code behind it.
I posted a question yesturday about how to fix a problem I was having about js encryption and decryption.
My whole system now works however I think I've just rebuilt https.
In my current app the client recieves a public key to encrypt data. That data is decrypted at the server with a private key which I've learnt is exactly the way https works. I was going to abandon my encryption functions completely however I thought that they might actually be useful.
This is because I thought I might have one server for handling requests and another for database interaction. So I would encrypt the plaintext password before it reached the request server (and then decrypt it after it reaches the database server). This is because the less places the password is known, the better (as far as I see it).
Not only that but I still don't feel safe sending a password as plaintext to the server even if it is encrypted.
There's probably a standard for sending passwords that I'm missing or something about https that I don't understand but really my question is:
Should I have https and my encryption system?
or just https and sending the passwords in plaintext?
You are not sending the password as plaintext when you send it through HTTPs, but you should not store it on the server (or pass it to other server). What you should make to prevent the password to leak, is to salt and hash it and store the hash and salt on the database, you can read more about it on wikipedia.
On the other hand, while building software from scratch is a good practice, it is important to review other implementations, so you can copy the implementation details on known open source secure implementations, like for example devise.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How do services which have JavaScript client libraries secure those libraries and the APIs they call? Specifically:
Ensure library is only loaded on valid sites.
Ensure a user doesn't just open up the console and start making calls.
Any other major considerations to be made?
Ensure library is only loaded on valid sites.
You can't and you don't. Security in client-side JS is futile. If you're talking server-side JS, you're pretty much pwned if arbitrary code is able to execute server-side.
Ensure a user doesn't just open up the console and start making calls.
Most services require some form of API key/token, a value that needs to go with your API requests so that the service can check its validity. This value is usually only obtainable by being a registered user of the service. That means an API key is tied to an account. If the service finds out that you're breaking ToS, they can simply block your API key or account altogether.
For public APIs, there's a combination of rate limiting, tracking and blocking (i.e. IP or a fingerprint of some sort), referrer checks (ensure something is only loaded by a certain page, not somewhere else), UA checks (ensure a browser is downloading, not a bot, app or something), and more. Individually, these checks are easily spoofed, but combined, can be a deterrent.
Well, since your js basically lives client side then the only thing you could really do there is make users authenticate before they can really get your libraries. Anything past that would really just be a tiny roadbump to anyone who really wants to manipulate your js.
Where you do have and can maintain control is securing your API calls. The most popular forms are with basic auth, OAuth, and IP whitelisting.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I want to insert a piece of javascript in the clients websites to track various statistics (like crazyegg, intercom.io), but traffic related.
I was thinking of using IronMQ but I don't know how to call it from Javascript directly and I am affraid that making a request to my server (3Gb Ram) from sites that have tens of thousands of visitors / days can cripple the server when making too many javascript requests in the same time.
You can call the IronMQ thru the HTTPS API.
See IronMQ REST/HTTPS API for more information.
Of course, you will need to provide Project ID and Token to JavaScript code. I suggest to encrypt Token before you place it into JS/HTML and decrypt on page load or before using the API.
Welcome Iron.io Live Chat even you will need more information.
Upd: For now it seems does not work. Because of Cross-Origin restrictions. But we're working on it, so, stay in touch.
You'll need to optimise as you go. If you find CPU is a problem, optimise for that. If you find memory is a problem, optimise for that, if bandwidth, etc etc etc. It all depends on
your requirements
your resources.
Optimisation is almost always the last step in the development process.
You might just have people include a 1x1 pixel image, you might have them include an iframe, or you might have them include a javascript file running off your server. Or you might have them include a javascript file on their server. More questions you need to ask yourself might be what information you want, what security issues are there, etc. If it's information for their purposes, then you don't need to worry about them forging it. Otherwise, you do.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I need to build a website that allows users to upload files and a few other actions. I have zero experience with javascript so I was wondering if there was some type of built site that already had logins coded so I could just work on the other logic?
I'm a long time delphi developer so I'm not new to programming. Any javascript video references would be great as well.
Thanks in advance.
You don't want to be handling logins with plain-old JavaScript unless you start building a super cool NodeJS setup, which, I wouldn't recommend if you have zero experience with JavaScript.
To ease your JS adventure, check out JQuery.com which makes it easier to code JS without worrying so much about browser quirks.
For easy server-side login, I recommend PHP since there are literally millions of tutorials and free code snippets out there, hosting is cheap, and an enormous community of PHP developers online to help you. To ease your PHP adventure, start with a framework such as CodeIgniter.
To answer your question, here's an example of a PHP + JavaScript (JQuery) login solution: http://blog.webwizo.com/2011/05/04/simple-login-with-php-and-jquery-ajax/
In order to upload files, you'll need a server-sided script, possibly done in PHP.
As for communicating with the server, it can be somewhat daunting for a beginner, but it's largely done via xmlhttprequest (otherwise known as AJAX).
Here's a tutorial on how to use it by W3CSchools, but there are plenty more on the net: http://www.w3schools.com/ajax/default.asp
One word of advice; don't make the mistake of relying of a JS library too soon; familiarize yourself with the language and its capabilities. A lot of answerers are just going to say "Use JQuery." You can (and possibly should), but it's important to know how Javascript works without it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am curious as to what, if any, security concerns other develpers have in regards to the use of JQuery plugins. I have seen very little talk about security where JQuery is concerned. Is it really a non issue?
Appreciate your thoughts!
Personally I am comfortable enough with Javascript to be able to swiff through the plugin code and understand possible misbehavior.
What I look for is the most relevant security issue with javascript, cross-domain communication, which is usually done with the creation of iframes, script/img tags etc..
Most of the times though, I trust the community, for example if it's up on http://plugins.jquery.com/ it is usually a trusted source.
jQuery can't do anything that javascript itself can't do, so all the same security standards apply. Basically - never rely on it for security. Always validate all inputs on the server side.
The best way to think of it is that from a security perspective, the client-side javascript is not actually a part of your application. Your application consists of all the possible http calls to your server. For good security, assume that hackers won't even be using a browser - they'll be making http requests directly to your server. Make sure that you aren't exposing any vulnerabilities in your http endpoints, and you should be ok.
note: I made the assumption in this reply that you're talking about data and system security. User security (preventing your users from being phished, etc) is another kettle of fish, but I'm not sure it has to do with jQuery any more than javascript in general.
The most popular ones are used all over the web on major web sites. If there is a security concern, someone else has probably already noted it. Also, a lot of the most-used jQuery plug-ins come from the same developers who are very active in the community, so it's fairly safe to trust them. (Jörn Zaefferer, the guy who did the validation plug-in, comes to mind)
Granted, it's a good idea to always test and always be skeptical, but at some point it becomes cost inefficient to worry too much.