Though I'm using HTTPS the attacker might get the access token by intercepting the request with burp suite This means that the attacker has a certificate trusted by the client. HTTPS does not protect against MITM by a trusted party, which in case of Burp suite is often the client themselves (i.e. reverse engineering the app). Such MITM could do anything in the name of the user anyway, by modifying any requests passing through or injecting script into the responses. There is no need to explicitly know the access token for this, i.e. protecting the access token would not help here anyway. That said, the access token is basically an authentication method which relies on sending the secret to the server, similar to a password. There are authentication methods which only prove the knowledge of a shared secret without sending the secret itself, like https://en.wikipedia.org/wiki/Digest_access_authentication . There are also methods which rely on asymmetric cryptography to prove knowledge of the private key, like client certificates or signing some server provided challenge. In these cases the secret itself is never transmitted. But it will still not protect against attacks by the client itself using Burp suite or similar, because the client might extract the necessary secrets from the client app.

Do I need to store this salt on the server and deliver it to each new client/device the user authenticates from? (I'm assuming here that the client can't store the salt, otherwise he could just store a strong encryption key and using a PBKDF would be a bad choice.) Yes. Although I would probably store some random data in the server, then let the user transform it with its password to get a different random data, which is then the one used as key by the client. If I do have to store it in some form on the server, is there a way to make it "hard" for the server to guess a weak user password? No. The server could always "fake" a login by the user. Moreover, it could simply log the password provided by the user to decrypt their secrets later- I would suggest that when the client provides the password to your website for login, it is actually some salted version (e.g. with a "website" salt) different than the one it will use for their secrets. Not perfect, but a small improvement.

Short answer: The password is a secret. Every time you share (transmit) a secret, you risk it. Longer answer: You should avoid storing the password on the server in the first place, so this shouldn't be possible (use salted hashes or something better). There is no reason to send the password to the client. The user should already have the password. If they don't, the password should be reset, not shared. The client shouldn't need the password. If multiple operations require authentication, typically you would use a separate / distinct / random / limited-time-use token stored on the client, not a password. Hypothetical: You suggest using HTTPS + JWT for sending the password. Assume perfect security for this transmission. How do you know the client system has not been compromised between the login and you sending the password back? This would mean that the password was transmitted from the client to the server in secret, but that when you send the password back to the client, the password was compromised, permitting the attacker to authenticate as the user going forward, with no-one the wiser.

It depends a lot on what the application proposes, but considering a web-created system where search site indexing is basically irrelevant (as it is a system and not a site), I use the following strategy:The back-end is only responsible for answering requests with pure data (in json, for example) and performing what the back-end always does (validations, processes, data manipulation). That is, it avoids mounting dynamic views.In the views, I do not use loops or back-end conditions, I send the basics (a html with a script call inside) and leave it to be mounted by my javascript framework on the client side. This strategy causes some impacts, such as:The server does not need to process things too much, relieving processes (it appears not, but in generations of reports this can be a differential).The data that traffic between server and client is only pure data, no tags and information that can be built on the client. Imagine a screen with 1000 records, turning a thousand "tr's" and "td's" instead of returning only the data string and riding on the screen, there is a performance gain if the face internet doesn't help much.As I assemble everything in the customer, I can give better feedback from the processes that are occurring in the customer. For example: the customer asks me for a report, I make a request in the backend and there I can inform you that I am collecting the information, when it arrives, I can inform you that I am processing the information.What can impact is the performance on the client's side, when his machine is not good for processing many information and causes a slowness. But in this case it would be necessary to analyze how many customers this occurs, if it really is a great impact, how often this customer has this problem and etc.I use this strategy for a few years and have already implemented it in a vehicle tracking company where the reports were gigantic. I can tell you that I got great feedback from both customers and the board. Since the server was relieved to mount views, allowing parallel processes to run faster, and customers had better feedback's than was happening on the screen.

You can use the following function:var dados = ["mizuk","programação","animes"]; function baixarArquivo(name) { var link = document.createElement('a'); link.href = 'data:application/octet-stream;charset=utf-8,' + JSON.stringify(dados); link.download = name; link.click(); }<a onclick="baixarArquivo('arquivo.json')">Download</a>This function will:create a linkset the address as being the file you want Saveset a name for the file to be savedautomatically click the linkThis way the file is saved automatically

Any applications of any kind that serve to access something that is externally served to the "main" application can be considered a client, no need to be on or on another machine.Outlook is a desktop application, right? He's an e-mail client. The browser is an HTTP client that renders pages and it is desktop.I think an application that doesn't communicate with anything else shouldn't be called a client, but gives what to think. An application that accesses a file is being served at least by file systemSo she's a FS client, right? At least you're a client of that API.An application does not need to be a customer of just one thing. And she doesn't have to be a client of something, just some part of it.A computer that runs on a network and takes information from somewhere is a network client, right? It doesn't even have to be an application to call a client.The client and server concept is orthogonal to what the application does in general. Something about her is a client of something external that provides what she needs.If all that matters to the application is external access then we can even say that the application is a customer in general.If you have one https://pt.stackoverflow.com/q/187344/101 that loads in your browser and from there no longer accesses anything external, is it a client? What?Terms exist to explain an adopted concept. If he's irrelevant in a situation, he doesn't have to use the term. If you will use the term you have to fully understand what it is, why wrong communication is worse than not communication, largely of the times, and in general https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect .Useful information: https://pt.stackoverflow.com/q/13298/101 .

If I understand well, you want to create a method that makes the asynchronous call to the method testUdpSocketServer. This can be accomplished in two ways:Add a return type "System. Threading.Tasks.Task" in its function so that it can be 'waiting'private async Task testUdpSocketServer(string message) { // código... } So you could call the test using: await testUdpSocketServer(msg);Use a Task that do the work:Task.Run(async ()=> { await testUdpSocketServer(msg); });

Create a div in each location you want to load the files with ids header and footer and pull them over Ajax:var http = false; if(navigator.appName == "Microsoft Internet Explorer") { http = new ActiveXObject("Microsoft.XMLHTTP"); } else { http = new XMLHttpRequest(); } var paginas = ["header","footer"]; window.onload = function(){ carrega_paginas(0); } function carrega_paginas(i){ http.open("GET",paginas[i]+".html",true); http.onreadystatechange=function(){ if(http.readyState==4){ document.getElementById(paginas[i]).innerHTML = http.responseText; if(i == 0){ carrega_paginas(1); } } } http.send(null); }

RemoteStorage is a Javascript API that uses OAuth and Node.JS and in theory meets your client-only solution requirement: http://remotestorage.io/integrate/

There are two ways to do this:Hash LinksIt is given by the use of hash links, as www.meusite.com#conteudo. Being conteudo changes to every transition that you want to be returnable. For example: you would site.com#listagem and when you click it will change to site.com#detalhamentoItem=15. This technique takes advantage of the fact that everything after '#' is considered anchor and does not cause a page refill.ProsThe pro of this method is compatibility, since it has worked since the 1990s.Works very well for pages that written purely in js (no backend).ConsLinks "feet";Watching the hash change can be extremely tiring in older browsers (and ignoring them ends up with your advantage). However there are dozens of libraries that do this dirty work for you. Personally, I like it http://plugins.jquery.com/hashchange/ and used it in some projects.HTML5 history APINewer method that allows full control of url. See more in http://diveintohtml5.info/history.html ProsPerfect when your server can generate a page like site.com?detalhamento=15 or site.com/detalhamento/15, but can also serve the result via AJAX (which saves band). Thus is the speed of ajax without losing navigation by history;Full control of the url that will be as beautiful as your server and your creativity allow.AgainstUsing this is method is almost impossible without a serverside language;It's html5. Tchau to compatibility.

The algorithm described is quite different from page-rank.It seems to me to implement a cumulative time weight for each page per user.Each time the user views a page, you go in the pertinent record to that page and add a weight, which compared to the weights of other pages says in what order it is.The value to be added becomes increasing with the passage of time, so it has to be a type of floating point. It looks like this:adicionar = Math.pow(2, (new Date()).getTime() * 3.17098e-11 - 46); pagina.peso += adicionar; This way, page visited long ago lose relevance to other recently visited.In the example above, what I did was the following:(new Date()).getTime() - takes an absolute time in JavaScript... is the number of milliseconds since 1970 I think... one thing like that, what matters is that it is absolute.... * 3.17098e-11 - I want to control the loss of relevance in years, so multiply the value of milliseconds so, that is the amount of years in a millisecond (fractional value)....- 46 - to take the years since 1970, to become small the number, since I will use the number as exponent.Math.pow(2, ...) - I raise 2 to the number previously obtained, which makes the value of a visit double every passing year. If you want to triple it's just use a 3, quadruple a 4, and then go.About persistence, no matter if persistence is made in a cookie... where you find it better, it can be local-storage, on a proper server, or in the memory of javascript.ExampleI will give an example using only the standard features of modern Browsers. (works on Chrome 51):I will store the data in JavaScript memory, so there will be no persistence between page loads... for this it is possible to use localstorageI will rebuild the table every time it is necessaryI will double the base note every 24h instead of 365 days to make the effect more easily noticeablevar nota; var data = [{ id: 1, link: "www.google.com", nota: 0 }, { id: 2, link: "www.yahoo.com", nota: 0 }]; var elNota = document.getElementById("nota"); var btnAdd = document.getElementById("btnAdd"); var txtLink = document.getElementById("txtLink"); var linkTable = document.getElementById("linkTable"); btnAdd.addEventListener("click", function(e) { var tbody = linkTable.getElementsByTagName('tbody')[0]; var id = data.length + 1; var newLink = txtLink.value; data.push({ id: id, nota: 0, link: newLink }); reconstruirTabela(); }); function truncate(number, mul) { return Math[number < 0 ? 'ceil' : 'floor'](number * mul) / mul; }; function step(timestamp) { nota = 10 * truncate(Math.pow(2, (new Date() * 3.17098e-11 - 46) * 365 - 218), 10000); elNota.innerHTML = nota.toFixed(3); window.requestAnimationFrame(step); } window.requestAnimationFrame(step); function setupLinkCell(cell, item) { cell.className += " linkCell"; cell.onclick = function(e) { item.nota += nota; reconstruirTabela(); }; return cell; } function reconstruirTabela() { var tbody = linkTable.getElementsByTagName('tbody')[0]; var sorted = data.sort(function(a, b) { var cmp; cmp = a.nota < b.nota ? -1 : a.nota == b.nota ? 0 : 1; if (cmp != 0) return -cmp; cmp = a.link < b.link ? -1 : a.link == b.link ? 0 : 1; return cmp; }); for (var j = 0; j < sorted.length; j++) { var item = sorted[j]; var row = tbody.rows[j] || tbody.insertRow(j); (row.cells[0] || row.insertCell(0)).innerHTML = item.id; (row.cells[1] || row.insertCell(1)).innerHTML = item.nota; (setupLinkCell(row.cells[2] || row.insertCell(2), item)).innerHTML = item.link; } } reconstruirTabela();table { width: 100%; } thead { background-color: black; color: white; } td { border: 1px slid black; } .fill { width: 100%; } .fill > * { width: 100%; } #btnAdd { width: 200px; } .notes { color: blue; font-style: italic; } #nota { font-weight: bold; } .linkCell { color: blue; cursor: pointer; }<table> <row> <td class="fill"> <input type="text" name="txtLink" id="txtLink" /> </td> <td> <button id="btnAdd">Adicionar Link</button> </td> </row> </table> <div> <span>Nota de um clique</span> <span id="nota">?</span> <span class="notes"> - essa nota dobra a cada 24h</span> </div> <table id="linkTable"> <thead> <row> <th width="100">Id</th> <th width="100">Nota</th> <th>Link</th> </row> </thead> <tbody></tbody> </table>

DifferencesThere is a difference between languages, each has its point of reach and thus can do specific things.For example in JavaScript because it is a Client-Side language you could not make a connection with the database securely because your JavaScript is public, and everyone could observe your database server credentials. This is the responsibility of the Server-Side language.On the server-side, the client has no access to the code, all that is there is sigilous, all its business logic, its accesses, credentials, and etc. Imagine if Google develops all the algorithmic and business logic in JavaScript, everyone would know the big secret, right?Server-Side basically is:PHP, ASP.NET, etc.Business logic.Access to the database.Request and rendering.Languages Server-side act at the beginning of the Request until the rendering of the page HTML, already the Client-Side languages act after rendering, basically:Mouse interactions, keyboard.Animations, drag in drop, sliders.Requirements ajax.Validations of dynamic forms (you can validate the fields without having to make a new request).Note: It is worth remembering that JavaScript language is not exclusive and is not limited only to Client-Side, although the vast majority of its use is in this regard. Today the same is also used as Server-Side language, see the example of http://nodejs.org , and even for some applications.Follow a great http://tableless.com.br/camadas-de-desenvolvimento-client-side/ from Diego Here http://tableless.com.br/ commenting on the Client-Side layers for web.A complete language of the other and vice versa that neither beans with rice. http://pt.wikipedia.org/wiki/Linguagem_server-side Server language, or Server-side scripting, is the language that will run " behind the cloths", providing the main logic of application. Works as follows: whenever the user does one HTTP request (enter a page, click a link, etc), the request is sent to the server. The server-side language receives the requirement (Request) and do processing. Then it turns the end result in an XHTML and sends to the browser. It is the server-side language that will check if the user is logged in, get information in database etc.How server-side language processes requests before sending to the browser, this means that a Once the page has been sent to the user browser, there is nothing else that the server-side language can do until a new "Request" wants sent. That is, it is not possible to use these languages to manipulate the user page in real time. For the user, the language server-side doesn't matter, and it doesn't even have a way to find out which language is being used. (Wikipedia) http://pt.wikipedia.org/wiki/Linguagem_client-side The client language, or client-side scripting, is the language that is executed on the client side, i.e. on the user's own computer, and is therefore used in situations where the server-side language has no reach. Among the client-side languages, there is JavaScript, which is the only language that actually runs in the user's browser. Through JavaScript it is possible to manipulate the user page directly, doing dynamic things ranging from changing the value of a form field to creating a resized area that can be dragged through the page.As all JavaScript code is in the browser itself, the user can see the code and can also by using some programs, manipulate the code. This makes languages client-side are insecure to do things like accessing a bank data. Together, the server-side and client-side languages complement. (Wikipedia)

Update: the browsers modern implement the Content Security Policy (CSP), which allow websites to guide you browser to allow/block various things. More details on https://pt.stackoverflow.com/a/75492/215 .With pure JavaScript, no. It is possible to restrict something from scripts by placing them in one iframe with the attribute sandbox, but this thin level of control is harder.If you have a script - external or not - and you want to ensure that it only does what you explicitly allow, it is necessary to modify it to reach that end. At first this could be done on its own browser, but there you would need one parser JavaScript in JavaScript (which is feasible, but not very efficient). Another option is to do this on a server. The project https://code.google.com/p/google-caja/ I would like to say that.I've never used it, so I can't affirm its effectiveness, but the idea is to provide a capacity-based security model (capability), so that the script does not have access to the global object and all its classes/functions, but only to what you make available to it.(Note: in some circumstances, a JavaScript code contained in a function can run in https://pt.stackoverflow.com/q/2746/215 so that it also does not access the global object, but I would not rely on it to ensure the security of the site.) https://security.stackexchange.com/a/15193/6939 cites some other tools that can help this purpose.

You can encrypt the data to be sent and decrypt the data to be received via sockets, with the algorithm https://pt.stackoverflow.com/questions/43492/como-funciona-o-algoritmo-de-criptografia-aes?rq=1 .import java.util.Formatter; import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; public class AES { private byte[] chave; private byte[] mensagem; public AES(byte[] chave, byte[] mensagem) { this.chave = chave; this.mensagem = mensagem; } public AES() { } public static void main(String args[]) throws Exception { byte[] mensagem = "oi".getBytes(); byte[] chave = "0123456789abcdef".getBytes(); System.out.println("Tamanho da chave: " + chave.length); byte[] encriptado = Encripta(mensagem, chave); System.out.println("String encriptada: " + new String(encriptado)); byte[] decriptado = Decripta(encriptado, chave); System.out.println("String decriptada: " + new String(decriptado)); } public static byte[] Encripta(byte[] msg, byte[] chave) throws Exception { Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.ENCRYPT_MODE, new SecretKeySpec(chave, "AES")); byte[] encrypted = cipher.doFinal(msg); return encrypted; } public static byte[] Decripta(byte[] msg, byte[] chave) throws Exception { Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding"); cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(chave, "AES")); byte[] decrypted = cipher.doFinal(msg); return decrypted; } } I believe that a way to solve your problem is the server to request a login and for a security measure, the client only informs the hash of this login to the server, and never in flat text. Subsequently, the server uses a key associated with that login (may be a piece of the hash of that user's password, which is already saved on the server) to encrypt the data using AES. In the client you repeat the algorithm, make the password hash and use it as AES key. If the password is equal to that of the server, both will use the same key and the communication will occur in a fluid and protected way. I think it is unnecessary for you to inform the password to the server, since with a correct decryption of the data it is already substantiated that the client informed the correct password. But if this is necessary, I recommend that you never send the password in plain text. Send the password hash and https://pt.stackoverflow.com/questions/2402/como-fazer-hash-de-senhas-de-forma-segura EditedAt the suggestion of https://pt.stackoverflow.com/users/215/mgibsonbr it is interesting that you use more time-consuming hash algorithms such as PBKDF2, BCrypt or scrypt. I believe that if you use the SHA-3, but with a greater amount of iterations (1000x, for example) will also have a similar effect.

No way. Everything that traffics between server and browser is visible by the user in some way. However, you can "hide" this key in two ways:Make the request for external service on your backend and leave the key saved there - so the client only communicates with your API, without knowing the key to the external serviceMake the user use their own key - which is not feasible in all cases

Using the second form you will load WordPress twice: one in load page normal and the second when including wp-blog-header.php or wp-load.php. Have a post on Crappy Code dedicated to this: http://crappycode.wordpress.com/2012/12/13/wp-load-php-i-will-find-you/ The correct is the first form, calling the AJAX through the actions wp_ajax_* (being the nopriv for users who are not logged in) and passing the URL wp-ajax.php (and security nonce) through http://codex.wordpress.org/Function_Reference/wp_localize_script :wp_enqueue_script( 'meu-ajax', // handler get_template_directory_uri() . '/js/meu-ajax.js', // ou plugins_url( '/js/meu-ajax.js', __FILE__ ) array( 'jquery' ) // dependencia ); wp_localize_script( 'meu-ajax', // handler 'wp_ajax', // objeto disponível em meu-ajax.js array( 'ajaxurl' => admin_url( 'admin-ajax.php' ), 'ajaxnonce' => wp_create_nonce( 'ajax_post_validation' ) ) ); Full plugin example: https://stackoverflow.com/a/13614297/1287812

Client-side hashing works, conceptually. The problem, though, is that of power. In a Web context, client uses Javascript, and Javascript is feeble for computing intensive tasks. The client already uses a system which may have a relatively small CPU (it could be a cheap smartphone, for instance), but Javascript adds its own overhead, which is huge (because it is interpreted, hard to JIT, and lacks decent integer types). As a rough estimate, client-side hashing in Javascript will be 20 to 40 times slower than password hashing on a decent server. Unfortunately, user's patience does not stretch; the user tolerates one or two seconds of delay, no more. So when you use client-side hashing, you have to use less iterations than when you use server-side hashing, which weakens the whole picture. Or, said otherwise, as long as you handle the login process of no more than twenty users per second, server-side hashing will allow you to use more iterations than client-side hashing, and thus be better for security. If the client uses a Java applet, then it is much more powerful; the "20x" factor becomes "3x". But Java applets have fallen out of fashion and won't work on tablets and smartphones. Mobile clients with a dedicated app may revive the concept of client-side password hashing. As for the details, the best way is not to "remove one iteration" from the algorithm, but to add an extra hash: cryptographic algorithms are complex animals, and though password hashing function internally use "iterations", they don't necessarily use only iterations. For instance, you cannot easily remove "the last iteration" of bcrypt and get a partial result to be transmitted to the server. So, instead, do all iterations on the client, send the result R to the server, and the server stores both the salt, and h(R) for some hash function h (e.g. SHA-256).

No, this is impossible. For CalDAV and CardDAV to work the server needs to be able to see the contents of the file in order to respond to the WebDAV/CalDAV/CardDAV methods REPORT and PROPFIND and similar.

The best way of dealing with this is to write a custom sqlmap tamper script. You can find examples in the tamper folder. In the script you'll want to make a request to whatever page is generating the random form parameter (or appending to a parameter's value); or if you can truly predict it every time, just have the tamper script generate it itself. So your script would look something like this (if I am understanding the problem correctly): def tamper(payload, **kwargs): username = get_username() password = get_password() return payload + "&%s=user1&%s=password" % (username, password) If you then call sqlmap with --tamper yourtampername it will run that script before every request. It will be a little bit hacky, but your tamper can also introduce new parameters into the request. Now, if you also want to test those dynamically generated values for injection, things might get a little tricky. Play around with it though and see if you can get it to do what you want.

You might want to read the three excellent answers to the question How does SSL work, where it's all explained, but in a nutshell, the server will select which ciphersuite (and compression) to use during the SSL/TLS handshake, after it receives supported ciphersuites from the client. Since you removed support of certain weak ciphersuites on your server end, they can't be selected for the SSL/TLS transport encryption, even if they are supported on the client. Edit to add: As has @DavidHoelzer mentioned in the comment below, not all websites have yet moved to TLS, and you don't want to be punishing your users for that. Even the weaker ciphersuites are better than none at all, if you remove support for them on clients. Your users would most likely still use those websites, even if they couldn't connect to the host using HTTPS, and would end up opting for HTTP, exposing them to many more threats in the process. In short - I wouldn't recommend it.