Why different key exhange techniques for ssl key exchange?

The distinction is not so much a matter between Diffie-Hellman and RSA key exchange generally, rather it's about being able to use Ephemeral Diffie-Hellman, which use ephemeral (i.e. new) parameter every time. (It's also possible to use fixed DH parameters, but I'm not sure I've ever seen it.)

Essentially, if you record the encrypted traffic and later on get hold of the server's private key, an RSA cipher suite, you can later on decipher the entire traffic straight away (e.g. using Wireshark's SSL tools).

In contrast, using EDH, new random DH keys are (or should be) generated every time on each side. Those parameters are not recorded and not visible on the wire, which provides Perfect Forward Secrecy (PFS). This is why deciphering EDH cipher suites are not supported in Wireshark. Reasonably recent versions of Wireshark can decipher traffic that uses EDH cipher suites, but you need to get hold of the pre-master secret (every time). (See "Using the (Pre)-Master-Secret" section of the Wireshark SSL wiki page and this question here.)

(Whether it's actually perfect is not clear, but it adds another random space that an attacker may have to brute force.)

You can find more details in this RSA Security Inc. document or at the end of this section of the TLS specification.


Is it possible to use a GPG or SSH key for web based authentication in a secure fashion?

For a Web application, the main problem is that the Web site code (Javascript in a browser) is not able to read and write files at will. Well, in general, this is more a boon that a problem, but here it means that the Javascript code will not be able to access SSH or PGP private keys.

There are things which can be done, depending on how much technology-savvy your users are, and how many manual operations they will tolerate:

You could use a locally installed browser extension which accesses the SSH or PGP private keys on behalf of the Web site. Preferably, some user control is advisable: we really don't want a browser which will sign things just because a Web site said to do it.
The server may act as a SSH server, and requires clients to connect with SSH and key-based client authentication. The user would run SSH in "SOCKS proxy" mode. The Web server itself would listen only to localhost, i.e. be unreachable except through such a local proxy. In this mode, the Web server could even be HTTP, not HTTPS; this would really be replacing SSL with SSH. On the server side, keeping track of users should use mod_ident or something similar (the SSH server knows who the client is, but the information must be forwarded to the HTTP server; fortunately, this is on the same machine, so the Unix-level identity can be used).
The Web site could display a "challenge" as a downloadable file with random contents. The user obtains the file, signs it with GnuPG, and pastes the (ASCII-armored) output into a text field on the Web site. The server verifies the signature, and accepts it as authenticating the user (provided that the server already knows the user's public key). Clunky, but works.

A mail-based variant of the above can be advisable, because PGP implementations are often embedded in email software, and also because it opens a possibility of not having to trust an external root CA. It would look like this:

User connects to the Web server with HTTPS. The server uses a self-signed certificate. The browser warns about it (the "red scary warning") but allows the user to proceed.
In the site, the user enters his name. Then the server sends a signed and encrypted email (with PGP) to the user; the signed email contains a random nonce, and also a copy of the server's SSL certificate thumbprint. The random nonce is also printed out on the Web site itself.
The user verifies the PGP signature on the server's email, then checks that the thumbprint matches the one he can see from his browser; this convinces the user that he is seeing the genuine server certificate, so there is no ongoing Man-in-the-Middle attack. (This is where we replace the X.509 CA system with PGP-based validation.)
The user also verifies that the nonce displayed on the Web site matches the one he sees in the email (this is important).
The user responds to the email by sending its contents back, this time signed with his own PGP private key, and encrypted with the server's public key. The server verifies that email and thus knows that the nonce value was indeed received by the intended user.
The server sends the nonce value as a cookie to the user's browser. This allows browsing without pestering the user with further authentication rounds. It is up to the server to decide how long it will accept the cookie as a valid authentication token.

In the above scheme, it is important to notice that by sending back his email response, the user is really authorizing the server to assume that whoever comes back with the nonce (as included in the email) is really the user himself. This is why manually checking that the nonce matches what is shown on the Web page is important.


Is it secure to interact with a web page before it has fully loaded?

This will be site dependant, however in most cases, yes, it should be safe to interact with a site that hasn't fully loaded. Many sites are designed with priority loading where the most important page elements are loaded first and supplemental elements are loaded in the background. The reason the site are designed this way is so that you can start interacting with the main content without having to wait for the less important data to load. Browsers makers spends quite a lot of their time thinking about how to safely load a page incrementally while all the resources are loading in parallel, and the are features in modern HTML for web developers to control this loading.

It is possible for a poorly designed page to break if you interact before it's ready, however in my experience this is very, very rare in practice. Most sites would hide any elements that can break until it's ready, or show a loading interstitial page if the developer deems it necessary, but the occasions where these are necessary are very rare as most things in HTML and CSS are safe to interact before page load finishes.

In particular, clicking links and back buttons are almost always going to be safe. The developer have to mess up something really, really badly if these very basic actions break their site. Filling forms are usually safe for all simple HTML forms that doesn't use any JavaScript, and even for most firms that do use JavaScript. It is possible though for poorly written forms to mess up, but this is quite rare.

  I believe that this can often cause history corruption,

If you're seeing history corruption, that's definitely not caused by interacting page while it's loading.

  however could there be any cases where interacting with the page causes information to be POSTed to the wrong destination, or a hyperlink destination to be incorrect resulting in you accidentally visiting a phishing site, etc?

It is possible, but this is rare. The only remotely realistic scenario (one that doesn't involve the developer deliberately going out of their way to make the site vulnerable) I can think of of incorrect POST destination is if an HTML form doesn't specify action attribute but instead uses JavaScript or modifies the action value by JavaScript afterwards. By default, this means that the form will be posted to the same server you're viewing the page on. This may trigger an error but are not normallya security issue. Except for credit card page, because credit card page are often posted directly to third party payment processor so the server wouldn't have to comply with all the requirements of PCI-DSS.

I can't think of any realistic scenario where you'd accidentally post to a phishing site due to incomplete page load. While it's not impossible, the developer would have to go out of their way to make this a possibility.


Recognizing malicious URL attempts against your website

Googling for "url_result ctw_" I found "I think it is yahoo japan search result for some music search and it also does translation into japanese language from english.
honyaku.yahoofs.jp is yahoo japan search engine and when you go to that address it is yahoo japan transtext site (text translation)" (here), and I also see 'real people' referencing it, and those references are OK.

There are many (838000) hits, it's obviously a common referer.


What kind of information gets shared while pairing a device using Bluetooth?

As I don't have the reputation to comment or mark this question as a duplicate I'll provide you the information you require.

Adi has a wonderful answer to what I believe is your question (link below):

What can an attacker do with Bluetooth and how should it be mitigated?

Of which I believe only the

  "What can an attacker do once a malicious device is paired with mine?"

matters to you.

The answer to this is dependent on the device you're using and the Bluetooth  profiles (sort of like Bluetooth standards/protocols) it supports. I've provided a link of the various profiles and what they can be used for: https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#OBject_EXchange_.28OBEX.29

I wasn't able to find the profiles your phone supports, but I believe that if both phones support the same profiles they will be able to interact with each other using them.


Is it possible to build a web-service which is immune to DOSes?

DoS is exactly what "user can send data" means; how do you tell between a legitimate user and someone/something that emulates a legitimate user just to cause trouble ? Often you can't.

For bandwidth-exhaustion attacks the mitigation is simple, you need to have more bandwidth than the attacker; either by doing it yourself or relying on a provider that sits between the Internet and your servers and has more bandwidth than most (all ?) attackers can have. Cloudflare is an example.

For application-level attacks, the ones that try to crash/slow down your server by overloading is more difficult to mitigate; if it's a web application you could use caching to avoid processing the page on each request and instead returning a cached version; you could also limit the number of requests per second to what is reasonable for normal use of your service, another idea is to put resource-intensive pages behind authentication so that only your legitimate customers can access them but outside attackers would just get a 403 without causing the server to process whatever that page was supposed to display - of course the solution isn't perfect either, as a legitimate user may have his account compromised to perform the attack, or that you made that "legitimate" user sad and he's now angry at you and wants revenge (I've seen that happen on video game communities sadly full of script kiddies).


Why does paxtest show OpenBSD as vulnerable?

if anyone interested, correction for the pax topic

  Sent: Tuesday, October 11, 2016 at 3:57 PM From: "W. Dean Freeman"
   To: "'Peter Janos'"
   Subject: RE: RE: OpenBSD PaX Test question
  Increasing the stack gap size isn't necessarily bad or good.
  Basically, you're adjusting the run-time value of a gap page that gets
  inserted at the top of a new stack frame, so that when an attacker is
  analyzing a binary and attempting to write an exploit, there is an
  unknown-at-compile-time number of bytes which have to be included when
  building the exploit and attempting to over-write the return address
  to the previous stack frame. It's just one of a series of mitigations
  against buffer overflows (like stack canaries, W^X, etc. You're also
  here adjusting the amount of room there is to play with when
  randomzing addresses for ASLR, at least as is my understanding.

  So, I doubt it hurts anything, but given the general strength of ASLR,
  stack gaps, stack cookies, the new W^X feature, etc. I'm not sure it's
  really necessary. If you really want to play with something fun that
  may ferret out bugs either in your code or in things you get from
  ports, turn on memory junking in the /etc/malloc.conf. For a
  discussion on some fun around that, see here:

  https://www.youtube.com/watch?v=YYf1U0xcHmk

  To the second question, there isn't any magic to what I'm doing in
  that program and between screenshots from GDB and a description of
  what's going on, you should be able to reconstruct it. There are three
  basic tests:
  1. Attempt to mmap(2) a page of memory with permissions PROT_WRITE|PROT_EXEC
  ** on OpenBSD, this will cause the program to abort. On HardenedBSD or NetBSD, you'll get a writable page of memory back
  ** If you get the page back, I put a bit of do-nothing shell code into the mapped buffer, then write a function pointer to it and attempt to
  execute in order to cause a page fault there and record the violation
  is caught properly, proving that I didn't get W|X memory
  2. attempt to map a page of memory as writable then mprotect() to W|X. With PaX, the page stays writable. OpenBSD will abort the processes
  here
  ** I did share a version with Red Hat through technical community channels, which included proof via live shell code that even if you
  turn off execmem allocation in SELinux, that you get no protection
  around mprotect and can still get a shell here.
  3. Attempt to map a page of memory as executable and then mprotect() to W|X. Again, OpenBSD will abort this but PaX just gives you back
  what you had originally

  I may be able to share the tool, but it basically just does a subset
  of what is in the paxtest, geared directly at three sub-cases for one
  security functional requirement which isn't even mandatory right now.
  However, RedHat didn't want to burn political capital with the Linux
  kernel devs pushing for it when OpenBSD didn't even turn it on. Now
  that they have, there may be a better case to be made in that regard.

  ----- W. Dean Freeman, CISSP, CSSLP, GCIH Lead Security Engineer Mobile: +1.8048158786 wdfreeman@acumensecurity.net
  http://www.acumensecurity.net

  -----Original Message----- From: Peter Janos [mailto:peterjanos2@mail.com] Sent: Tuesday, October 11, 2016 2:23 AM
  To: W. Dean Freeman  Subject: Re: RE:
  OpenBSD PaX Test question

  Only two question:

  ======================================

  1) Increasing kern.stackgap_random=262144 to
  kern.stackgap_random=16777216 increases the "14 quality bits" to "20
  quality bits".

  Stack randomization test (SEGMEXEC) : 20 quality bits (guessed) Stack
  randomization test (PAGEEXEC) : 20 quality bits (guessed) Arg/env
  randomization test (SEGMEXEC) : 20 quality bits (guessed) Arg/env
  randomization test (PAGEEXEC) : 20 quality bits (guessed

  is this a wise thing to do? Does setting the kern.stackgap_random to
  16777216 increases security?

  ======================================

  2) Can we have the cc-memtest binary or source? Or it is not public.
  http://blog.acumensecurity.net/revisiting-wx-with-openbsd-6-0/

  ======================================

  Many Thanks!

    Sent: Monday, October 10, 2016 at 5:46 PM
    From: "W. Dean Freeman"
    To: "'Peter Janos'"
    Subject: RE: OpenBSD PaX Test question

    Sure, go ahead.

    From: Peter Janos [mailto:peterjanos2@mail.com]
    Sent: Monday, October 10, 2016 11:46 AM
    To: W. Dean Freeman
    Subject: Re: OpenBSD PaX Test question

    can I post this as an anser on stackexchange?

    Thank you!

    Sent: Monday, October 10, 2016 at 4:36 PM
    From: "W. Dean Freeman"  >
    To: peterjanos2@mail.com
    Subject: OpenBSD PaX Test question

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Hi Peter,

    I'm the author of the blog post that you referenced in your stack exch
    ange post.

    As you may note from the blog post, I make three points in particular:

    OpenBSD does not follow the PaX model (and therefor shouldn't be
    expected to do everything that paxtest checks for, necessarily, and
    certainly not in the same way) 2. In OpenBSD, you can still use
    mprotect() To switch between wri table and executable pages of memory,
    because what is enforced is stri ctly W^X, not W!->X.
    My claims about OpenBSD 6.0 were strictly in relation to the c
    onformance with FPT_W^X_EXT.1 in the latest revisions of the NIAP-appr
    oved Operating System Protection Profile for Common Criteria.

    So, an operating system like HardenedBSD or NetBSD, which follow the P
    aX model, will not allow you to successfully do something like this:
    * Map a page of memory as writable
    * Subsequently mprotect() that page to W|X
    * OR mprotect() that page to just X after it was W

    On OpenBSD, the behavior is:
    * You cannot map a page of memory W|X
    * You cannot mprotect(2) a page of memory that is W to W|X
    * You can map a page of memory as, say, R|W, then mprotect(2) t o R|X

    This allows you to, say, run new Firefox builds, which use this mprote
    ct(2) swapping method to keep pages allocated by the JIT from being W|
    X at the same time without having to push Firefox off onto a separate
    /opt filesystem or something where you have fs flags to remove the W^X
    protections. In HardenedBSD or NetBSD you would still have to use se
    cadm or paxctl to remove the mprotect hardening on a per-binary/per-pr
    ocess basis because the PaX model wouldn't let you swap the permission
    s.

    I demonstrated this in the blog post, towards the end, and then explai
    ned why this matters in the context of JITs.

    Please let me know if you have any other questions, but I hope this he
    lps clear it up. Essentially, your'e going to get those "vulnerable"
    messages from the pax test tool because OpenSBD doesn't do PaX.

    Thanks,
    Dean

    W. Dean Freeman, CISSP, CSSLP, GCIH
    Lead Security Engineer
    Mobile: +1.8048158786
    wdfreeman@acumensecurity.net

    http://www.acumensecurity.net http://www.acumensecurity.net/

    -----BEGIN PGP SIGNATURE-----

    iQFRBAEBAgA7BQJX+6daNBxXaWxsaWFtIERlYW4gRnJlZW1hbiA8d2RmcmVlbWFu
    QGFjdW1lbnNlY3VyaXR5Lm5ldD4ACgkQrnqwKenh3fRbrQgAjFsvyXA6bZIPYyjX
    0A3ldKlFTekRuyFnhmWuX3CsK5eV7azrADyamuPV5T2YMN7U0tmjcOC9hOX3OPsK
    0IC9YqTjGxpLuxt0Z7GeXeeRO58SvroKMbsKZz6pU8pvKAJn8Hl/0UcAJsmfcHUd
    6ErH7wuHgpCEzTHGkiEIz1W/kPZXUsRhT9XpURUCBwOp01vsl5Lm9GfYWb64zHCM
    f9fDwkasE/Dy8amn907bGLSP1M711HhVB5cP76xe0twYyxOKtNRlJno2Kc9cEr4D
    d2U/r/iCG8A9Qabp+QBuxVWTdP3kq2LwDqb6ySUSLLrSYLbRjUOi+7GhQer3yM+r
    6TEFcQ==
    =gBZh
    -----END PGP SIGNATURE-----


How should high net worth individuals secure their financial accounts?

The best security measure is quite simple.  Don't use accounts that allow your money to be easily stolen via the Internet.  Happily, high-net worth individuals have used systems like this since before the Internet was a thing, and are in fact particularly likely to choose them regardless.  While banks certainly aren't perfect at protecting money from theft, historically, they do a massively better job of it than the individuals who have money to protect, high net-worth or otherwise.

First of all, when you're a billionaire, your money is not in a checking account.  Most of it, in fact, isn't liquid at all.  It's ownership of corporations, real estate, things that are difficult if not impossible to steal in any but the most convoluted ways.

For the assets that are somewhat liquid, the vast majority of them are still going to be investments.  And there's not going to be in an E-Trade account with a web login.  They're going to be held by an investment bank that caters specifically to high net worth individuals, managed by private bankers whose job is it to know what's in your portfolio and how its performing at all times.  It simply isn't accessible to outside threat actors.


Where are NTFS security ACLs stored on Windows systems?

On NTFS volumes, various access permissions applicable to securable file system objects such as files and folders are stored as metadata (Access control lists, ACLs) that are part of the file system. During normal operation, Microsoft Windows NT and successor OSes enforce said permissions  strictly.

If a given NTFS volume is to be used alternatively in 2 or more different installed OSes, one must therefore be very careful not to mess with or destroy existing permissions, set in another OS and which may be necessary for the proper operation of it - especially permissions on system folders and files.

In the particular instance which affected an old windows 2000 Pro, I had carelessly messed with permissions for its whole System32 folder hierarchy, using a "convenient" point and click so-called "unlocker assistant" while running Windows 7.
Repaired the mess, while running Windows 2000, by reapplying the "secedit" to (an extract from) the relevant default security template (found at %SystemRoot%\security\templates).


How to verify .plist and .kext files are legitimate?

The only good solution for recovering from a malware infection is to wipe the disk and reinstall the OS. If you have a backup that you are confident predates the infection, you can go back to that.

I know that you state that it's a potential malware infection, but if you have any doubts (which you obviously do as you asked this question), wipe the disk.


Reflected XSS is not only by GET. It can be by POST too. And they are not prevented always by the browsers. And of course, is still relevant.

A couple of definitions:

https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting
https://www.acunetix.com/websitesecurity/xss/

And from Checkmarx knowledge base, it says: "The most commonly found XSS". Extracted from here. So if is the most commonly found I guess is still relevant.


Other than blatant photo editing (online tools exist for this!), it's possible to modify the message database to create seemingly native messages. All data is stored in an SQLite database and while the format is pretty complex (so as to support advanced features such as attachments, interactive apps, etc). This would mean that a sufficiently advanced person could modify their local database and insert messages from a person that never happened. They could literally present their phone to the judge and jury and unless an advanced security analyst were brought in no one would be the wiser.

As far as I know there are no known (or publicly known) exploits which allow iMessage to be spoofed before it is received on the end user device. This would be a major, ultra valuable vulnerability.

Here's what a row in the database looks like. There is more info to the left but the good stuff is pictured (click for the full size):


Does using the same mail and web server increase a risk of DDos due to IP exposure?

You can use CloudFlare to hide your server's real IP address. This article is saying that if you use CloudFlare and send email from your web server, it could expose your real IP. Assuming that you are not using CloudFlare or another similar service, the risk described in the article is not relevant to your situation and can be ignored.


Can a Tor exit node be reliably identified?

It sounds like what you're trying to do is block all traffic from Tor exit nodes.  This is exactly opposite of what shady sites like Silk Road do, in that they allow traffic only from Tor exit nodes.  Either configuration is easily done because all Tor exit nodes are published.  See these two StackExchange articles about how to do this:

Quick and easy answer:
https://stackoverflow.com/questions/9780038/is-it-possible-to-block-tor-users

More in-depth answer:
Block all BotNets and TOR addresses from accessing our site


What do you call the entity seeking to be authenticated?

In IEEE 802.1X terminology that would be the supplicant:

   Authenticator
         An Authenticator is an entity that requires authentication from
         the Supplicant.  The Authenticator may be connected to the
         Supplicant at the other end of a point-to-point LAN segment or
         802.11 wireless link.

   Supplicant
         A Supplicant is an entity that is being authenticated by an
         Authenticator.  The Supplicant may be connected to the
         Authenticator at one end of a point-to-point LAN segment or
         802.11 wireless link.

(Source)

In other contexts the entity being authenticated is often simply referred to as a client or user as that's in most cases unambiguous.


Are external assets included in the 2018 TLS 1.0 PCI deprecation?

There's nothing official so far, but it will almost certainly be down to the judgement of the individual ASV. This is almost always the case on purpose, because it allows assessments to be adaptive in the face of new attack vectors and different contexts.

For example, on an isolated domain where no information is entered and no stateful actions can be performed (e.g. a static link portal inside the PCI environment) none of these cases are particularly critical and I'd err on the side of letting it pass as long as the business can demonstrate a longer term plan to migrate to a more secure configuration.

In contrast, on a system that accepts financial data and performs financial transactions, I'd almost certainly fail it for any of those cases. Scripts and CSS are known to be XSS vectors, so those are the highest risk here. Fonts have, historically, been risky to the client endpoint but are generally more difficult to exploit outside extremely targeted scenarios. Images are the lowest risk here.


Using a verified certificate to sign others

For a certificate to be valid as an intermediate CA (i.e. as part of a chain of certificate, and not at the end -- that's what you propose to do), it must have a Basic Constraints extension with the cA flag set to TRUE. Otherwise, system which verify the chain (e.g. Web browsers, when validating a server's certificate) will reject the chain. See RFC 5280, sections 4.2.1.9 and 6.1.4 (item 'k'). Commercial CA can sell you a certificate with the cA flag set to true, but this will typically not be cheap. "Normal" certificates (the ones which can be afforded by individuals) have the cA flag set to false.

Note that up to circa 2003, Internet Explorer was failing to verify the cA flag, and your scheme would have worked. This was a huge security hole, of course, because anybody could then act as a pseudo-CA and issue certificates with any name in it.


What are the risks of providing SSLv2 for additional device compatibility?

SSL 2 was deprecated in 2011

It was not deprecated, it was outright prohibited which is a huge difference.
See also What's the difference between SSLv3 being deprecated and SSLv2 being prohibited?

  However many devices are manufactured before 2011 and still in use today

TLS 1.0 was defined 1999 and was available in major TLS stacks (including openssl) from around this time. Not supporting it was already not an option in 2011.

  if a well-designed network service provides SSL 2 compatibility

It is a kind of contradictory statement: well-designed vs. providing SSLv2 compatibility. Having a SSLv2 device on the network is not only insecure because of the SSLv2 protocol itself but also because it is highly likely that any old devices which cannot speak any better than SSLv2 wants to use weak ciphers too.

  if SSL 2 is not provided, the service will be completely inaccessible a major portion of devices (30~40%) that are otherwise perfectly functional.

Depending on the environment you might be able to secure such devices by adding some software in front so that they are available with better protocols and ciphers.

  An example would be a corporate email server for daily communications.

If this server supports only SSLv2 than it must be that old that it has lots of other vulnerabilities. TLS 1.0 was available with Windows XP already.

  What exactly are the risks of accepting SSL 2 connections on the server?

While it is bad to have SSLv2 only it is bad to have SSLv2 additionally to other protocols. See DROWN attack for details on how availability of SSLv2 can aid in decrypting properly encrypted connections.

In summary:
if all of this is done within some restricted network where you have no malicious activity the using SSLv2 is probably perfectly safe as would be plain text. But as soon as you have the possibility that someone attacks the network you need to deal with the problems caused by the insecure SSL version (DROWN) and age of SSL stack (weak ciphers) and also at the general software problems (i.e. outdated and probably vulnerable software).


How can Authy use Google Authenticator QR

The use of apps other than Google Authenticator is not, by itself, a security risk, provided you trust those apps.

The purpose of 2FA is to prove that you have some physical object (in this case, your phone), in addition to knowing something (the password).  This makes it more difficult for an attacker to compromise your account, because they are less likely to simultaneously know your password and have your phone.

The TOTP protocol used by Google Authenticator basically works like this (for full details, see RFC #6238):

You scan a QR code which contains some secret.  The site provides this secret to you, and also stores it server-side (preferably encrypted, in an HSM, or in some other "reasonably safe" storage; RFC #4226 has some interesting discussion of the difficulties here).
When you need a new one-time-password (OTP), you perform some cryptographic operation (an HMAC) based on the secret and the current time.
That cryptographic operation produces a value which can be converted into an OTP.  You provide that OTP to the website, which generates an OTP by the same process.
If your provided OTP matches the OTP which the website generates (or the OTP it would have generated a few time steps into the future or past, to allow for clock skew), then it is accepted.  Otherwise, it is rejected.

This is an open standard, and by design, anyone can implement either half of it (client or server).  However, a malicious client implementation could hand the secrets over to an attacker, who could then impersonate you for 2FA purposes, so you should only use client apps which you trust.

All that being said, I have some pretty strong reservations about Authy in particular.  When I last investigated it, it stored the secret from step (1) in the cloud by default.  This is intended to be for convenience, so that if you lose or replace your phone, you won't have to reconfigure TOTP on all of your accounts.

But it also means that you are defeating the core purpose of 2FA: You are no longer proving that you both have something and know something.  Instead, you are proving that you know something (your password), and have authenticated with someone else (Authy's cloud storage).  This is a weaker security model because it makes Authy a point of failure for all of the other sites.


Is it possible to filter user input at browser side to prevent injection?

Yes it's possible to add something like this on the client side, but it would not be effective.  I wouldn't waste your time adding this type of protection to your client side.  Since it is on the client side, a malicious user can (and will) bypass it immediately using an HTTP Proxy or something similar.

I would recommend give the book, The Web Application Hacker's Handbook a read.  This goes into detail about how a malicious user will attack your site and points you to free tools that will allow you to attack a test site you control in the same manner that a hacker would.  Actually doing this will open your eyes to how web security really works.


API which does not allow to invalidate session on server side - how to make it more secure?

This is actually not that uncommon a setup.  Typically where an application uses stateless cookies, there's no way apart from timeout to invalidate the session.

The advantage of this appraoch is that the server doesn't need to maintain a list of valid cookies, which is handy for scaling, the downside is (as you've noticed) if the application has a long timeout there are risks relating to stolen sessions.

What you could do assuming the flow is

customer <--> your app <--> API

is if you give your customers a token created by your application and then maintain a mapping table so you effectively proxy all traffic between the customer and the API, you could then implement a logout function for your app which removed the token that the custoemr has on logout.

The API token would still be valid of course, but assuming that you can secure the link between your app and the API the main risk would be in the compromise of your app, which likely has more serious consequences that individual customers losing control of their session tokens.


Should I include a random padding in every HTTPS request and response?

From the outside, one can only see the length of the exchanged data, i.e. the total length of the request, and the total length of the response (rounded to a multiple of the symmetric cipher block size, e.g. 16 bytes if AES is used; but not rounded at all with RC4). To avoid leaking any information, all requests and all responses should have exactly the same size; so the padding should have a variable size which depends on the length of the padded data. If you add padding with a random length but with a probability distribution which does not depend on the size of the padded request or response, then the original request length can be reconstructed statistically if that request is performed on a regular basis.

There is no need for the padding bytes to be random. Only the length is visible "from the outside". You can use constant byte values (e.g. a custom HTTP header X-Padding: ZZZZZZZZZ with, as contents, a sequence of 'Z' of appropriate length). Using random data could actually leak extra information through timing (if the random generator is not very fast, the attacker could observe the client or server reaction time and deduce the size of the padding, thus indirectly obtaining the true request or response length).

Always targeting a fixed size is wasteful of network bandwidth, because all requests will have the size of the largest possible request, and all responses the size of the largest possible response. @Paŭlo's suggestion of padding up to the next multiple of a given value (e.g. up to the next length which is a multiple of 500 bytes) is appropriate: it leaks a bit more than always padding to the same length, but it does not leak much; and it avoids wasting network resources.


Is using haveibeenpwned to validate password strength rational?

"Strong" has always had the intention of meaning "not guessable". Length and complexity help to make a password more "not guessable", but a long, complex, but commonly used password is just as weak as Pa$$w0rd.

If a password is in the HIBP list, then attackers know that the password has a higher likelihood of being chosen by people, hence, might be used again. So those lists will be hit first.

So, if your password is on the list, then it is "guessable".

If your password is not on the list, then from a dictionary attack approach, it is less guessable and not what others have chosen, and by implication (for as much as that's worth), is "less guessable". Many other factors, of course, can make your password "more guessable", even if it is not on the HIBP list.

As always, a randomly generated password is the most "unguessable" and a maximum length and randomly generated password is extremely difficult to bruteforce. And if you are randomly generating it, then why not go max length?


It's actually not a SHA1 hash in the CSR.  It's a signature of the message.

For simplicity, I'll assume we are talking about RSA certificates, where the public key is (N, e) (the modulus and public exponent which is typically 65537) and the private key is (N, d) (the modulus and the private exponent which can be easily calculated via Euclid's extended algorithm if you can factor the modulus into p and q).

A certificate is simply a public key, with some meta-data (e.g., who you are, what domain the certificate applies to, who signed the certificate), plus the signature of the certificate.

In RSA you sign a message by attaching a signature to the end of the message.  You obtain the signature by first hashing the message and then doing modular exponentiation on that hash with your private exponent.  That is the signature is S = H(m)^d mod N.  Note anyone with the public key can verify the signature by calculating S^e mod N and verifying that this matches the hash of the message.  Note, if you do not have the private key you cannot construct a valid signature for the message, so this prevents tampering with the certificate.

A CSR is a certificate signing request, but essentially it is just a self-signed certificate that you create on a local machine, so you can give to a CA to sign (so the CA will never learn your private key).  So you locally construct two large primes, multiply them to find the modulus, and calculate the private exponent.  You add your meta-data about yourself to your CSR.  For good measure, you immediately sign your certificate with the private key associated with the public key contained within the certificate.

This prevents someone from altering your CSR in transit to the CA (to say change your organization details, challenge password, serial number, without changing the modulus/private exponent).

This probably isn't the most devastating attack as you still have to trust the CA to act in trustworthy manner, and there's no reason to give away your CSRs to any other third parties.  However, its straightforward to sign it, takes no additional effort, so it is commonly done.


I've implemented the functionality you describe in the past as follows: Along with every account in the database, a Boolean value is stored. This property might for instance be named IsPasswordChangeRequired.

When the sign in form is submitted, the web server first checks whether the user credentials are valid. If this is the case, it checks the value of the IsPasswordChangeRequired property. When that's true, an alternative version of the sign in form is served, i.e. one that contains fields to enter a new password.

The server could also respond by redirecting to a change password page.


Is adding a supplementary credit transaction something that could improve online payment security?

Answering my own question to be able to flag it as answered and prevent it from popping up from time to time: this measure appears as a plain example of security theater.

Here are the elements leading me to this conclusion:

I asked their support teams then reason behind this change: while they were usually quick to answer more usual questions I never received any answer to this one.
The change was apparently clunky and not well thought: they had to add a special functionality to allow onetime and prepaid cards to bypass this measure a few weeks after enabling this system as, obviously, a section of their customers weren't able to proceed with the payment step anymore.
This process is exclusive to this website: this a good thing to impress their customers but, from a technical point-of-view, this does also mean that no one else ever wanted or felt the need of such a system. It never takes long for new and genuinely efficient security-related ideas to spread, under one form or another.
This process is directly noticeable by the end user, which is required for an effective security theater measure.
I never saw any advantage to this measure, neither did any of the other Security.SE contributors for the two last years.

If anyone has some knowledge which could change this conclusion, feel free to add your own answer, but after two years I think I can safely put this one in the security theater bin, alongside with other ideas resulting from "pseudo-security as a marketing argument", "you hired a too zealous security intern/company" and "we need to justify our budget".


Connection between PIN/password and encryption keys in Android

File Based Encryption (FBE) keys are bound to screen lock authentication. Unless user enters screen lock password, keys that decrypt FBE keys cannot be derived. Screen lock authentication and key derivation are executed inside Trusted Execution Environment (TEE) which is a separate secure environment that runs independently of android OS.
TEE has 3 components:

Gatekeeper - It enrolls new screen lock password and authenticates existing user.

Biometric - It enrolls new biometrics like fingerprint, face ID and Iris and authenticates enrolled biometrics.

Keymaster - It handles cryptographic operations for the device.

Here's how authentication followed by FBE keys decryption works during first unlock after reboot:
Biometric authentication doesn't work in this state.
Authentication

Start point is PIN pad.

Invalid frequent password attempts are throttled by exponential timeout by Gatekeeper. Each attempt takes 100ms for verification so brute forcing a strong password is not feasible.

HMAC key that generates HMAC on Auth Token is valid until next reboot. After reboot, Keymaster invalidates this HMAC key and generates a new one for the Gatekeeper. Gatekeeper cannot cache this key and it has to request this key every time authentication takes place.

FBE Keys Decryption

Start point is User Root Key.

Two start points.

FBE keys are re-encrypted by Keymaster using Ephemeral Key which is valid until next reboot. FBE keys are then cached in vold and the Linux kernel keyring. When the Linux kernel requires this key to read or write a file, it calls into the secure environment which decrypts FBE keys, derives a 64-byte AES-256-XTS key and programs it in into the Inline Crypto Engine. This ensures that FBE keys are never stored in plain-text when outside of TEE. FBE keys also undergo an additional key derivation step in the kernel in order to generate the subkeys actually used to do the encryption, for example per-file or per-mode keys.
Now user can use biometric to unlock screen.

Is this design secure enough from forensic extraction?
It's secure when the device hasn't been unlocked once after reboot. This is called Before First Unlock state. Once the device has been unlocked atleast once after reboot, the device goes to After First Unlock state and at some point FBE keys will have to come in memory for reading and writing data. Background apps like messages, emails, contacts, notes, reminders etc. can keep them in memory indefinitely from where they can be extracted.
That's how FBI might be Hacking Into Private Signal Messages

Qualcomm File Based Encryption (pdf)
File Based Encryption
Android 7 File Based Encryption and the Attacks Against It
Data Security on Mobile Devices: Current State of the Art, Open Problems, and Proposed Solutions


This is normal. See the last column Metric. If there are two routes to the same destination, the one with lower Metric value has less cost and is chosen as the better alternative. On the other hand, the VPN tunnel itself needs a route to 0.0.0.0, too.

Some (Open)VPN implementations do extra measurements to be chosen over any other connections. They split the 0.0.0.0 e.g. into two halves in addition to using low metric values. As this route is more specific, it gets chosen over 0.0.0.0.

Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.1.254    192.168.1.100     35
          0.0.0.0        128.0.0.0         10.8.0.1         10.8.0.5      3
        128.0.0.0        128.0.0.0         10.8.0.1         10.8.0.5      3

Likewise, you still see more specific routes e.g. for your physical networks:

      192.168.1.0    255.255.255.0         On-link     192.168.1.100    291

That's because OpenVPN's redirect-gateway doesn't actively remove routes to local networks, whereas some other full tunneling implementations go further by doing it. From the Reference manual for OpenVPN 2.4:

  –redirect-gateway flags…

  Automatically execute routing commands to cause all outgoing IP
  traffic to be redirected over the VPN. This is a client-side
  option.This option performs three steps:

  Create a static route for the –remote address which forwards to
  the pre-existing default gateway. This is done so that (3) will not
  create a routing loop.
  Delete the default gateway route.
  Set the new default gateway to be the VPN endpoint address
  (derived either from –route-gateway or the second parameter to
  –ifconfig when –dev tun is specified).

There you could leak information through various protocols e.g. mDNS, LLMNR, NetBIOS or SSDP, but that's another story and doesn't affect the connections to the Internet through the VPN.


How to decide whether to password protect key files in addition to full disk encryption

TL;TR

It really depends on the organization.  Things to consider:

How seriously do they take security?
Is there a lot of travel that would lead to an increased risk of compromise?
Is a stolen computer or physical removal of a drive a risk?

The overhead for putting this into place is low.  For a large company with lot of company travel it's worth it to keep data safe.  In this day and age I honestly don't believe you can be too careful.  To guide them outline the risks that are involved in insecure data on a day to day, and explain the solutions are relatively non-invasive and simple to implement.  That's my $0.02.

Details

  What exactly does password protecting guard you against? What specific scenarios are you vulnerable to with FDE, but no passwords on critical files? Are you protected if you also use passwords on those criticial files? Are these realistic scenarios?

FDE protects an entire volume.  If that volume is separate from the bootable volume then you can take care your files are protected while on that volume and the volume is unmounted.  Assuming recommended good security configurations are used.  Generally once the volume is mounted it is accessible.  If the files leave that volume then they are unprotected, and if they are sensitive should be password encrypted.

If the volume is bootable, then once the BIOS boots up and the correct password is entered the entire volume is decrypted and accessible*.  This means that active attacks against your machine can access your files no problem.  In this case you absolutely need to protect any files you consider sensitive.

  What configuration details of the laptop affect this decision? For example, password-based vs TPM-based encryption? How relevant are defences like automatic screen locks?

There are lots of configuration details that can effect FDE.  These all depend on that you're using.

TPM-based encryption is good if you're worried about your hard-drive being physically removed from your computer.  A TPM ties the FDE'ed volume to a specific device.  The encryption keys are stored in the TPM and only in the TPM.  However this alone isn't fully secure.  With this configuration the computer will be FDE'ed, but boot up without any password authentication.  Some solutions offer to configure a password, or physical USB key in conjunction with the TPM.  This provides the authentication while keeping the actual encryption keys in hardware.  This is the best solution as keys held within the TPM are secure and no piece of software has them in memory.  Bitlocker provides for this configuration.  This answer contains an interesting paper about cold-boot attacks against FDE solutions.

Automatic screenlocks are always a good idea.  If someone tries to bypass by rebooting they'll run into the FDE.  If someone has your password... well something went terribly wrong.

  What password management processes are users expected to follow? Can the user use the same password for full disk encryption as for critical files? If not - how do you stop them?

Password management is probably the most important part of all this.  It's bad practice to use the same password for more than one purpose.  I don't believe that this is enforced in software solutions.  There's no secure way to enforce this.  If the software is doing things correctly with salted passwords there's no way for the software to tell if a password is used in more than one instance.  This is truly up to the user.  I would not use the same password for sensitive files as I used for the FDE.


Is there a way to create time based OTP with public/private key

In case you are talking about a One Time Password there is a simple reason, why TOTP-Algorithms are using a symmetric key on the client/device and the server side.

If you take a look at HOTP-TOTP (RFC6238), it is derived fro HOTP-OTP (RFC4226), the event based OTP algorithm.
This was specified in 2005. The first smartphone arived in 2007.

So what? The OTP algorithms are designed to work with hardware devices. These hardware devices have a display, so that the user can punch in the one time password. During the generation of the one time password the RFC defines a truncation method, so that the user is actually able to punch in a limited set of characters.
The output of HMAC-SHA1 is 20 bytes hexcode. Noone wants to enter this as a one time password.

To be able to do assymmetric cryptography you can not use any truncation function. Otherwise the public key would not be able to verify the signature. The private key would not be able to decrypt the message.
The data to transfer with assymmetric keys would be much larger - 1024 bit, 2048 bit... Again, the user would have to enter manually a very long one time password.

Well, if the client transmits this data electonically you would not have to truncate it. But then we are again not talking about one time passwords but about publy key crypto or client certificate based authentication.

So in the end it is all about human readability and truncation.


Carrier IQ is a rootkit previously installed by mobile phone operators on Android and on iOS 4 iPhones. It is capable of recording every keystroke on your virtual keyboard.
See What risk does Carrier IQ pose, exactly?


Should I worry about NoScripts anti-XSS warning when making a 3DSecure payment?

3D Secure is a fraud-prevention system:

  3-D Secure XML-based protocol designed to be an additional security layer for online credit and debit card transactions. It was originally developed by Arcot Systems, Inc and first deployed by Visa with the intention of improving the security of Internet payments and is offered to customers under the name Verified by Visa.

And your concern:

  NoScript informs me that it has stopped a potentially insecure script

It's most likely not an actual XSS attack.

This "XSS redirect" happens because the payment page on the website in question is redirecting you to a payment gateway. It is a redirect, yes, and it could be used to attack you yes, but!

You should check for the green padlock in your URL bar on the website you're purchasing from. If there's no green padlock, do not even enter your details.
When you submit the payment, you can see where it's redirecting you, as NoScript gives you a warning. Have you verified that the URL belongs to 3DSecure?

Unless the attacker has access to your machine, and is able to modify the NoScript plugin to report the wrong URL, then you should be fine. However, if an attacker has access to your machine, there are bigger things you need to worry about.

Note that in many cases, ignoring the XSS redirect (refusing to "Unsafe Reload") still allows the payment to go through for me. I am unaware if this is the case on the website you're visiting.

Potential risks

  As a customer, what risks am I exposed to by adding the merchant to the whitelist? Can someone steal my credit card details?

It really comes down to the security of each site.

If you use https, and the certificates are properly issued, a man-in-the-middle attack is highly unlikely.

These https certificates will validate that you are on the correct website while encrypting your connection to/fro. However, your data is only as safe as both websites that handle it. If there's a vulnerability in either website, even if the certificates are valid, it might be possible for your data to be stolen.

It's definitely possible for a website to be hacked, and for data to be gathered on the inside, and then accessed later on. However, most credit card companies promise zero fraud liability. Does yours? While this won't prevent your personal information from getting out, it at least offers some mitigation in the event of a breach.

Should I worry about NoScript's anti-XSS warning here?

It depends. Does everything check out? Green padlocks in your URL bar? Generally, there is no need to worry. However, if either of the websites in question are breached, then no... you can't trust either website at that point.


Using Cain and Abel to capture traffic of machine in the same network

You can't: Cain and Abel is not a general purpose packet sniffer. Abel captures the packets, and then Cain performs analysis to try and find passwords; you look at the results of the analysis, not the raw packet capture.

If you want to view packets, you should use a more general product such as Wireshark.


Could this list of ciphersuites be improved on?

A simple grep would not provide enough context to determine if there is a problem. Even if your find actual uses for these less secure algorithms (contrary to just finding code which uses these names for other things) it is still not clear if there is a real problem. For example, MD5 and SHA-1 are no problem when used as HMAC. Thus, you actually need to look at what these algorithms are used for.


How do openvpn/easy-rsa generated keys map to RSA algorithm variables?

Creating a Certificate Authority

When you create your Certificate Authority certificates you will get ca.crt and ca.key files.  The .crt file is the self-signed public key, and the .key file is the private key file.  It's not quite as simple as this.  Both files are base64 encoded, and the data underneath is DER encoded.  Since you are likely generating X.509 certificates.

Really all you need to understand is that you have a self-signed certificate whose public portion is stored in ca.crt and the private portion is stored in ca.key.  Remember that you need to keep ca.key secret  All of the big primes, GCD operations and what not is all taken care of by whatever you're using to generate the certificate.

The dh2048.pem is not a key, it is the Diffie Hellman parameters for the server.  These have nothing to do with your RSA keys, and are only used for when Diffie Hellman is used to connect to your server rather than RSA.  The difference between the two can be found in the Key Exchange section of How does SSL/TLS Work?  These should have nothing to do with PKI.

The crl.pem is generated to be your Certificate Revocation List.  Any certificates that you revoke that have been signed with your CA are added to this file.  In your OpenSSL configuration (I'm assuming you're configuring OpenSSL, but the idea applies to any configuration) this CRL file will be pointed to.  That way it will know where to check for revoked certificates.

Signing Certificates

Now that you have a Certificate Authority you can begin signing certificates of users for your system.  Users do this by generating their own RSA keys client.crt and client.key.  These keys should be generated whenever a new user is introduced to the system.  Again, the .crt is the public portion of the key, and the .key is the private portion.  The client.key must be kept secret by the new user..

To sign the certificate of a new user a Certificate Signing Request (CSR) is made.  There is a command in OpenSSL to do this.  The request contains the public key of the user to be added, and some other public information needed by the request.  The client's certificate will be added to the appropriate authorized lists on the server, and a new signed certificate will be produced.  This is what the user will have to import into their browser to visit PKI enabled pages.

There's a great tutorial about Public Key Infrastructure on OpenSSL's site for future reference.

Hopefully this clears some things up.  Each variable you've mentioned in the RSA algorithm is generated when you create a certificate.  Public certificates don't contain them all, but the private portions generally do.  For implementation purposes you won't need to worry about them.  Just remember that there is a public and private key pair.

To Answer your 1st Edit

The exchange of CSRs and the resulting certificate is generally performed using some type of secure copy (scp).  The server and client must be in communication with each other.  The statement that "the client and server authenticate each other" is not really correct.  The client wants to be a part of the infrastructure so it must prove its identity to the signing server.  As the Certificate Authority, it is its responsibility to verify the identity of the client before processing the CSR.  The CSR itself should have all the information needed to verify the identity of the client to be added.

To Answer your 2nd Edit

RSA is only the public key algorithm used for key generation, encryption/decryption, and signing.  Public Key Infrastructure is a collection of standards and services required to implement a secure infrastructure.  A trusted timing service is most likely one of many requirements.  Much like a Certificate Authority is a requirement.


Most justifications for a non-encrypted sessions / information serving stems from not owning visitor (client) security concerns. i.e., "My server / my data won't be harmed, so I'm okay". If that's all you want and you're only serving content to authenticated/authorized users (not allowing them to change anything), then your strategy will work.

So I suggest you use encryption. Getting and using a LetsEncrypt certificate costs nothing these days (other than a few minutes of your time). It won't be long before browsers and search engines start warning users away from unencrypted sites.

  ... classic MITB, and it would easier due to having no encryption

For web applications, MITB has practically the same impact as client compromise. So "encryption" or other defenses don't help at all.

From the Wikipedia - MITB Article:

  A MitB attack will be successful irrespective of whether security mechanisms such as SSL/PKI and/or two or three-factor Authentication solutions are in place. A MitB attack may be countered by utilising out-of-band transaction verification, although ...


Let's clear up some confusion here first. Internet Key Exchange (IKE) is a hybrid protocol, it consists of 3 "protocols"

ISAKMP: It's not a key exchange protocol per se, it's a framework on which key exchange protocols operate.
Oakley: Describes the "modes" of key exchange (e.g. perfect
forward secrecy for keys, identity protection, and authentication)
SKEME: Provides support for public-key-based key exchange, key distribution centres, and manual installation, it also outlines methods of secure and fast key refreshment.

So yes, IPSec does use IKE, but ISAKMP is part of IKE.


Security implications of hosting third-party Javascript

I would say the implications are the same as any XSS vulnerability.  What you are basically doing is allowing them to insert javascript of their choosing into your application without making them jump through the hoops of finding an XSS vulnerability.

Two big risks that come to mind are performing actions on behalf of the user without their ok and stealing session cookies if they aren't HTTP only.

If you do agree I would only do it on the condition that you will need to review and approve all javascript.


Does Convergence solve the problem of hacked CAs?

No, Convergence won't protect against that specific attack. It is designed to detect a bad CA issuing a forged certificate for a real site to allow a MITM attack, by checking that all the Convergence notaries are seeing the same cert.

In your phishing example, the forged cert is for a fake site, so there's no "real" cert, and so the notaries will all see the same thing and not notice the problem.

There's good info about convergence in the answers to this question

Note that the attack you describe is unlikely to be used much in the real world. Firstly, phishers usually don't bother with a certificate at all, since plenty of victims won't notice that the page they are accessing is http and not https. Secondly, it would be much easier for a phisher to purchase a legitimate certificate than hack a CA - whoever owns gmial.com can perfectly legally buy an SSL cert for it. Lastly, phishing attacks get noticed fairly quickly (they are rarely subtle) and any certificates involved are going to be revoked quickly.


Database encryption or filesystem encryption?

The encryption you use depends on the risk you're trying to mitigate. File/disk encryption is typically used to protect against theft of the physical media. i.e. they won't be able to access the content as it's encrypted. For a web application this doesn't provide any additional protection so protection of the data within the database may make more sense.

If a malicious external user manages to dump the database, they'll only have access to encrypted data (and hopefully not the encryption/decryption keys) and your encryption control has been a success. Alternatively, if the end user manipulates the application to extract data from the database in decrypted form (which the application must be able to do) then the encryption control hasn't mitigated that particular risk!

Also, as you likely only want to encrypt some of the data, doing that at a database column level should provide minimal overhead.


Is there a real risk of exploitation in java code where a null pointer is dereferenced

Theoretically, any kind of null-pointer dereferencing in Java triggers a NullPointerException, which can be handled within Java just as any other exception. This does not mean that this is good: in practice, it is quite hard to recover from such an exception except by removing the faulty part (i.e. letting the calling thread die, or getting back to a catch-all clause). Following a null pointer is akin to overrunning a buffer: it is still a bug; the difference here between Java and non-protected languages (such as C) is that Java is more graceful about the consequences of that bug: in particular, the exception will propagate back the call stack, releasing monitors (the synchronized keywords) and executing the finally clauses, and only the faulty thread will be affected.

In practice, however, a few issues may arise. How the JVM traps null pointer dereferences is up to the JVM implementation; but what implementations usually do is the following: they just follow the pointer. If the pointer is null, then this leads to a memory access in the first page of memory, which is access-forbidden by the OS. The OS catches the occurrence (through the MMU) and informs the application in a relatively brutal way (on Unix-like systems, this is a SIGSEGV signal). The JVM receives the information, and transforms it into a NullPointerException.

The conversion from signal to exception is a complex thing because the JVM only receives the offending opcode address, which is somewhere either in the bytecode interpreter, or in the JIT-produced binary code. The JVM must locate the method and the thread stack. This has some fine interactions with how the OS put things in memory in the first place. Such code is quite stable nowadays, on mainstream platforms. However, on a less common combination (Sun's JDK ported to FreeBSD), I sometimes had null pointer dereferences for which the JVM was unable to locate the caller stack (because the JVM code was tuned for Linux, not for FreeBSD, and was apparently making an assumption on where the stack should be, assumption which was not always fulfilled on FreeBSD). Consequence was immediate JVM termination, in a most ungraceful way.

Another possible gotcha is that the null pointer dereference is caught because the access falls somewhere in a "forbidden" page; namely, the first page of the address space. However, when accessing an instance field, the JVM usually accesses directly the right data element: if the reference is, at native code level, a pointer to address x, and the field is at offset n in the object structure, then the code will read bytes at address x+n (this really depends on how the JVM represents objects internally, but a C-like structure is common). If the class has many fields, then n may be greater than the size of a page, in which case the read access will not fall on the first page, but the second. What happens in that situation depends on the operating system.

The "field at high offset" situation does not arise with arrays, because array accesses are length-checked and the "length" is usually a kind of field which is close to the object header. Also, there is a limit on the number of fields in a Java class (there is an absolute limit to 65535 in the class file format, actually lower than that because each field must have a name and a type, which are also in the class file format and will hit other limits sooner than that). So the problem will not arise on "common" systems, e.g. a Linux running Sun/Oracle VM. This is mostly something that VM implementers must be aware of.

So my advice is to consider NullPointerException as a serious bug, just like a buffer overflow (which is IndexOutOfBoundsException in Java). The VM safety will help you debug your code (stack traces are really handy) and, if you did not debug enough before deploying, it will probably save your skin. But a bug is a bug.


How to turn of telnet and FTP on Thomson 789vn router?

Have you tried to telnet onto it? I had a similar Thomson router which if you telnet onto has it's own command line interface. It wasn't very intuitve, but once you get the hang of it you can figure out how to remove services.


How to view e-mails without internet connections?

What you are speaking about is an airgap, a device or network with no network connections outside of its own loop.

If you had an email client within the airgap then you could view emails that have been transferred over to the airgapped system on removable media, but you could still be infected by any malware that is contained within them.

A well known example of this is the famous 'stuxnet' malware. Although the exact delivery mechanism was not email,  it was targeted malware that was suspected to have breached the airgap via removable media.

The airgap itself will mitigate against many types of malware, even if it is successfully delivered. For example, droppers, c2 bots and other malware that requires an Internet connection to function and/or spread will not be able to function correctly.


There are quite a few considerations that need to be made here.  First, although your php.ini disables the exec php function there remains the web server security itself. Consider the following:

1) Does your web server allow script execution for other languages (perl, python, or CGI in general)?  Or, perhaps scriptalias definitions.

2) Are you concerned about protecting users that view the website?  i.e. if someone installs a malicious iframe or .htaccess file?

3) Are you concerned about hosting malicious/illegal content?

4) Are you concerned about being a spam/attack relay?

If someone is able to execute code under the context of the apache user, you have to assume a few things.  First, you have to treat the apache user as any account with an interactive shell.  Anything another user can do on the local system, the apache user would (likely) be able to.  (i.e. DoS, attack other systems, attack higher privileged accounts, host content).

HTH.


NuGet does not currently support code signing for package or nuspec files, so the author of the package cannot truly be identified. This issue was raised as a feature request in 2010, but it didn’t get much attention and hasn’t been implemented. See http://nuget.codeplex.com/workitem/79.

Currently an already existing package NuGet can only be upgraded by the same account that it was originally uploaded by but this does not verify the actual author of the code which I believe is what you are getting at.

Outside of NuGet, code signing for assemblies still exists. Based on this I would suggest that you ideally:

Only use signed assemblies from a trusted publisher.
Use strong name references in your projects (which binds the project/assemblies to a specific public key).
Verify the signature for each assembly you download.

Possibly another concern is that a NuGet packages can have PowerShell install/uninstall scripts attached to it which are automatically run when using the NuGet package command-line. NuGet 1.4+ does support code signing for PowerShell scripts so I would suggest leaving PowerShell execution policy to RemoteSigned.

Alternatively don’t use NuGet and download the .msi/.exe from an official release and verify the signature on the file.


TrueCrypt vs "native" whole-disk encryption on Linux?

The only thing TrueCrypt gains you is portability. Windows, Mac OS X, and Linux all have a version of TrueCrypt available for download and easy install from http://www.truecrypt.org/. TrueCrypt support is in dm-crypt 1.6+ now which gives Linux native TrueCrypt support out of the box, but you'll have to have a distribution that includes it or install it yourself. Provided you use a compatible file system (FAT32 works on all of them for sure, NTFS with read-only support for Mac OS X by default, and exFAT support works with Linux with the installation of the exfat-fuse package), you can carry a TrueCrypt container and expect to be able to use it on any of the major operating systems seamlessly.

On the other hand, dm-crypt is not as portable to other operating systems, but does everything TrueCrypt does and provides the flexibility of using any algorithm the kernel supports. dm-crypt comes with every Linux distribution and should work out of the box. For Windows, you will need FreeOTFE to mount dm-crypt volumes. You might run into issues with 64-bit Windows along the way. As far as I know, there isn't a FreeOTFE-equivalent for Mac OS X; accessing a dm-crypt volume basically requires installing Linux itself. It's not worth the potential hassle to try and use dm-crypt volumes from other systems if you ask me.

Short answer: if you do not expect to use a volume on other operating systems, stick with native dm-crypt since you'll get support for it straight out of today's live Linux discs. Otherwise, use Truecrypt and FAT32/NTFS.


How isolated are files on a VirtualBox virtual machine from the host filesystem?

The virtual machine usually stores its virtual hard disk as a normal file on the host operating system's filesystem.

Think of a filesystem like a warehouse. The warehouse contains a large number of boxes (files) and a manifest that lists all of the boxes (the file table). When you delete a file, it doesn't actually destroy the data, it just deletes the entry from the manifest. When the next box comes into the warehouse, the manifest is checked, and the file is put into a free location. If that location already has a box in it, that old box is thrown out. As such, if you can scan through the warehouse instead of the manifest, you could check for boxes that aren't on the manifest, allowing you to extract contents of the boxes even though you "deleted" them.

So, if you delete the virtual machine's virtual disk file, the data will still remain on the disk. Since the virtual disk file is structured in terms of its own headers and the internal filesystem, it shouldn't be difficult to find and extract file data from within the virtual machine's filesystem. Formatting often doesn't solve this problem, as it just overwrites the file table with an empty one - the data is still there.

There are two ways to properly destroy files:

Overwrite the disk sectors that contain the data with zeros.
Encrypt the file data at runtime, then destroy the key when you want to delete the file.

The first option takes longer when you want to destroy the data, and puts more stress on the disk, as you have to overwrite every sector. The second option provides fast secure deletion, and increased protection during day-to-day use, but has a performance hit on the CPU. In fact, SSDs use the second option to reduce write-wear on the flash devices during a re-format - they store a master key, encrypt everything on the drive with it, then destroy and re-generate the key when given a re-format command.

So, if you're looking to destroy data securely, either perform a proper low-level wipe using shred, or encrypt the disk using TrueCrypt and throw away the key when you want to get rid of the drive.


A good source focused on publicly announced data loss is - http://datalossdb.org/


LastPass Key Derivation Security Question

First, keep in mind that 99.99...% of sites transmit your password to the server in clear-text over (over an SSL connection, of course). There the server actually has your clear-text password during authentication. So even that one hash increases security.

Taking a step back, the reason that we perform numerous rounds for hashing or key derivation for passwords is that we are going from a relatively small set of possible inputs (ie: passwords chosen by us dumb users). As the set size is small, you need to increase computational expense of a dictionary or brute-force attack by making the calculation of each hash (much) more costly. We do this by repeating the hash over and over.

In the Lastpass situation that you ask about, the input to the hash is the output of another hash. So the input space is relatively well distributed across the full 256 bits. At least it will be after you salt the passwords (without salt this would be susceptible to a pre-compute attack). That means that a brute-force attack would have to test the full 256 bit space to reverse the one hash. This is too large for precomputation attacks (eg: use of rainbow tables).

Now if an attack is developed that allows you to reverse SHA-256, that would increase the risk in this situation, along with many, many others.


guarantee that the public key isn't compromised on the way to the recipient when sender has recipients public key

Yes. There must be a trusted entity, be that the connection between a and b that c cant access or a CA who can confirm that a is a and that b trusts.


I tested Chrome and Firefox, both mobile on ssllabs.com:

Chrome

Cipher Suites (in order of preference)

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)   Forward Secrecy    256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   Forward Secrecy  256
OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)   Forward Secrecy    256
OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)   Forward Secrecy  256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   Forward Secrecy  128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   Forward Secrecy    128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   Forward Secrecy 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   Forward Secrecy   256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   Forward Secrecy   128
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)  128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)

Signature algorithms

SHA512/RSA, SHA512/ECDSA,   SHA384/RSA, SHA384/ECDSA,   SHA256/RSA, SHA256/ECDSA, SHA224/RSA,   SHA224/ECDSA,   SHA1/RSA,   SHA1/ECDSA

Firefox

Cipher Suites (in order of preference)

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   Forward Secrecy  128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   Forward Secrecy    128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   Forward Secrecy     256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   Forward Secrecy     128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   Forward Secrecy   128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   Forward Secrecy   256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   Forward Secrecy   128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   Forward Secrecy   256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)     128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)     256
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)

Signature algorithms

SHA256/RSA,SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA

SHA384 is seemingly unpopular. Have not seen it in the wild. Firefox (NSS) and Chrome (WebCrypto) have some problems implementing those strong ciphers.

Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=923089

Chrome: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/ufzO8NhttaA


Is it possible to crack a laptop's encrypted hard disk?

To put it bluntly, no. If the encryption software is solid and the password is xmc'jg.6EE/l\Z>tX;8mXb0#0k+RgW!1'N)q)}OE1FO(3!JbyUq^\HUR1&#o, then there is absolutely no chance to crack the password. Even if you waited billions of years, there isn't enough energy in the universe to do so.
So why did the guy say that eventually it will be cracked anyways? What does he know that we don't?
The problem is, most people don't set a secure, random password. You see, a lot of people tend to think that they don't need security - until they need security. They pick easy-to-remember passwords like Spring2021, Julia1994, etc. because they think nobody will ever try to crack their password anyways. So if your password is easily guessable or follows "a totally secure scheme nobody would ever guess", then your chance of being cracked will increase.
Furthermore, it also depends on who stole your laptop. A lot of people who steal a laptop simply want to sell it for some cash. They don't care what's on your laptop, and most likely, even if it was without any encryption, they wouldn't dedicate the time to finding out ways to monetize your company secrets. To them, stealing a laptop is a quick way to make cash. The people who buy a stolen laptop also couldn't care less what the previous owner had on there. It's just an extremely cheap laptop to them.
On the other hand, if your laptop was stolen by a dedicated attacker who knows who you work for, what you work on and how to make use of that knowledge, well, let's hope your password isn't Spring2021.


That depends on what you mean by "inside". For example, as Conor Mancone suggested, there could be a combined reflected XSS and SQL injection. That could look like this:
http://example.com/badendpoint?q=<script>$('input').value="';DELETE FROM USERS;--";$('form').submit()</script>

In this example, the SQL injection is the payload of the XSS. That's sort of putting the SQL injection "inside" the XSS.
When a hapless user opens that link, the script tags will get added to the page. The JavaScript will then fill out a form and submit it. The data entered in the form contains the SQL injection that deletes all users from the target database.
As nobody said, it may be better to call this chaining the vulnerabilities together.


OpenSSL SSL enabled client application, server verification?

The way you check to see if a certificate is valid is by checking the certificate parameters (expiration, subject, etc.) and verifying that the certificate was signed by a trusted authority.

As far as what authority to trust for Google certificates, Google publishes a Frequently Asked Questions document here. If you follow their guidelines you should be fine.


How can I reliably erase all information on a hard drive?

The only NIST approved method to securely erase a hard drive is by utilizing the secure erase internal command - documented at the Center for Magnetic Recording Research (CMRR) - and that is what everyone should be doing. It is an ATA command, and covers (S)ATA interfaces.
After that, you can optionally degauss the drive to erase the firmware itself.
Lots of interesting info in Guidelines for Media Sanitization, NIST SP 800-88 (2014).
A quote from the paper:

Secure Erase
An overwrite technology using firmware based process to overwrite a
hard drive. Is a drive command defined in the ANSI ATA and SCSI disk
drive interface specifications, which runs inside drive hardware. It
completes in about 1/8 the time of 5220 block erasure. It Was added to
the ATA specification in part at CMRR request. For ATA drives
manufactured after 2001 (Over 15 GB) have the Secure Erase command and
successfully pass secure erase validation testing at CMRR. A
standardized internal secure erase command also exists for SCSI
drives, but it is optional and not currently implemented in SCSI
drives tested by CMRR. SCSI drives are a small percentage of the
world’s hard disk drives, and the command will be implemented when
users demand it.

A more recent (2010) short presentation from NIST that compares different erase techniques and their limitation is in a ppt presentation by Lyle and Russell.


If I understand this correctly you forward any traffic originating from outside to a pfSense VM (192.168.1.3/10.0.0.3) which then filters it and forwards it to some inner VM (10.0.0.10). This means

An attacker which is able to heavily compromise the inner VM 10.0.0.10 or the pfSense VM 10.0.0.3 might be able to compromise the VM host through vulnerabilities in the virtualization layer. See these questions for more details on this.
Since pfSense is bridged into the internal network it is possible to access internal machines (VM host and others) from the pfSense VM and depending on the configuration of pfSense also from the VM behind pfSense (10.0.0.10). This way even an unprivileged user on the inner VM (10.0.0.10) might be able to attack the internal network (192.168.1/24) including the router. Explicit firewall rules on pfSense might be used to restrict which networks the inner VM can access.


Airbase-ng & Metasploit the perfect pair

What you are looking for is Karmetasploit. It is the integration of Karma with MSF to offer a variety of network services to wifi clients.

Several tutorials and videos are available.

In addition, there are hardware solutions, like the wifi-pineapple from Hak9.


Going off your example of Twitter and Facebook, both of their army of scripts aren't reading the DOM or interacting with other scripts. If either tried to, say, get the value of a variable or something like that, then they'd be violating SOP.

The origin of a script is where it's included. So if you included Google's analytics scripts on your page it can interact with the DOM -- that's exactly why you can load jQuery from Google's CDN and have it work.

Here's a scenario. Let's pretend you own server one, and you want to include a cool "Like my page!" button from server two. In order for server two's button to work, it needs to load code from their servers. So, if you include <script src="servertwo.js"></script> you're including an actual file that can change your DOM because its "origin" is your page. It's "origin" is your page, even though the file is hosted on another server because your page is the one saying, "I want to use this file but it's located elsewhere."

If server two's JS file tried to load an additional script into your page, by inserting something like this: <script src=anyserverexceptforyourown.js"></script> then it'd be violating SOP if that script tried to change the DOM. Even though you loaded the original script, the second script that server two's JS tries to load didn't originate from your page like in the first portion of the example, so its origin would be from server two not your server.

On my personal website I have multiple scripts. Some of the scripts look like this:

<script src="http://www.ericlagergren.com/javascript.js"></script>

others look like this:

<script src="https://www.google-analytics.com/analytics.js"></script>

both of these "originate" from my website because I referenced them and asked to include them in my page.

If either of those two scripts tried to load an additional script into my page that third script would be violating SOP because I didn't explicitly ask to load it in my page. Make sense?


Common practice when CVSS v2 score over represents severity

If you are correct that the vulnerability really doesn't effect your systems then the proper thing in my opinion is as you mentioned.  The business should formally accept the risk (which is negligible if you are correct in your assuming your systems are not effected).


Is it unwise to use Redis to store PII, private keys, and other secrets?

The risk/issue is exactly the same and the mitigation as well. Regardless if it loads the database partially or completely into memory. There will be no way for you to tell which keys have been compromised and which haven't. So the only option would be to revoke them all, regardless if it's a Redis or SQL database.

Most of the time the reason why people are using Redis vs SQL is because of performance issues. I think the likelihood of such a succesful attack is considerable low if you have a decent design and prevent direct exposure of your database server. If they already implemented this then the investment to fix it on one hand will be great considering half of the codebase will require updates. I think you should look into isolating the Redis cluster, monitoring all operations (SIEM logs), seeing if you can implement extra controls (anomaly behavior) and verifying their incident response plan in case of breach, rather than shoot down their solution.


Assigning random IPv6 ranges to ISPs as a security measure

Most IPv6 subnets are no smaller than /64. It's not a protocol requirement, but it is de facto standard and also necessary for networks that run SLAAC.

Each of those networks contains 18446744073709551616 IP addresses, and, in each network, only a handful of those addresses will ever be used.

Therefore, even if you know exactly what subnets are assigned and which are unassigned, it's infeasible to scan even a single IPv6 subnet to find the host addresses that are in use inside that subnet. So making it hard to guess which subnets are assigned doesn't really help.

Put that together with the fact that even if ISPs must move their address blocks around from time to time, they must still document their assignments in WHOIS so that outsiders can find out who is responsible for a given IP address and contact the right abuse desk. We intentionally do the opposite of hiding IP network assignments!

Exceptions: if you guess an IPv6 subnet that is in use, you actually have better than 1/18446744073709551616 chance of finding an assigned IP address within that subnet. For example, if SLAAC is in use and who can guess the MAC address of a host on the subnet, you can generate its IP address. Privacy addresses mitigate this. Also, servers will often have well known, simple addresses like <subnet>::1 so you can guess those too (but then again, they're servers, so they're supposed to have well known addresses). Still, it's sufficiently daunting that I think it's still a futile task to try to "portscan" IPv6.


Books about theoretical basis in log management

You can start learning about data mining here and if, you need a book, try this one.

For more on Machine learning you could go to
videolectures.net

A great introductory lecture on the site is Machine Learning, Probability and Graphical Models by Sam Roweis.

Next, you can have a look at Tom Mitchell's seminar The Discipline and Future of Machine Learning. Here is a direct link to the video [mov].
And the Syllabus page has a good list of recommended texts:

Neural Networks for Pattern Recognition by Christopher Bishop
Pattern Classification by Richard Duda et. al.
The Elements of Statistical Learning: Data Mining, Inference and Prediction by T.R. Hastie et. al.
Information Theory, Inference, and Learning Algorithms by David MacKay
Machine Learning by Tom Mitchell


With Nmap it is possible to scan according mac address?

Keep in mind that nmap is an IP based scanner. Based on the information that you have provided, I would suggest using nmap to perform a host discovery i.e. identifying active hosts in a network. This step will give you a list of active IP addresses.

You can use ARP to resolve the IP addresses (Obtained during host discovery) to MAC addresses (Assuming its all in the same local area network). Once you have identified the MAC addresses that you wish to scan, feed the corresponding IP addresses to nmap for scanning.

In short:

Host Discovery > IP to MAC conversion > Identify target IP addresses using MAC > Port scanning

Refer this for more information on using nmap.


By any measure, they're wrong:

Seven random printable ASCII: 957 = 69 833 729 609 375 possible passwords.

Ten random alphabetics: 5210 = 144 555 105 949 057 024 possible passwords, or over 2000 times as many.

Length counts.  If you're generating your passwords randomly, it counts for far more than any other method of making them hard to guess.


API based platform to save bank account information

If your systems have visibility to the sensitive account data, your negligence could be responsible for any breach or fraud. So by merely collecting the data, you expose yourself to these risks.

These risks are magnified if the sensitive data is durably stored "at rest" in your custody- whether on servers you control or at a provider you contract with- rather than just passing through your systems "in transit."

There are plenty of services that will store data for you, but they will not take any custodial responsibility, particularly in the heightened form that storage of sensitive data implies. Custody remains with you.

So- because your systems have visibility, risk remains with you and you cannot expect to shift that risk onto another provider. Therefore there will not be services that work in precisely the desired fashion in the ACH space.

Services, like Stripe, collect customer payment information and then use that information to request transfers of money from customer accounts to your account. You can safely utilize these services with minimal risk because you never see the sensitive account data. Stripe bears the risk, in exchange for taking a 2-3% cut.

The rules in this arena are much clearer in the credit card domain, where PCI has over the years developed a relatively high degree of sophistication for classifying participating organizations, developing roles and standards, building an audit and compliance ecosystem, and handling enforcement. It is not perfect, and credit card fraud occurs every day, but it is managed and the requirements and consequences are much clearer.

The ACH system, whose counterpart to PCI is NACHA, is much older and arguably less well organized than the credit card system. The machinery is much less mature. This risks that arise from the lack of maturity are offset by the pace at which the ACH system works, in which the minimum transaction time is days rather than the seconds that can be achieved in the credit card system. But NACHA still expects that billers utilizing ACH must have clear evidence both of the identity of the customer initiating the payment and of their assent to any particular transaction. These responsibilities begin with the parties who collect this information.


Security implications of a fixed vs relative pathname

In general: an absolute path name is more clear than a relative one. It is not open to interpretation based on the context like a relative path name is. The actual meaning of a relative name depends on the current directory, on environment variables (like PATH) etc, while an absolute path name most times means the same thing.
Therefore an absolute path name is almost always the more secure choice. Of course one is probably able to deliberately construct some scenario where the absolute path is the more insecure choice and likely there will be even such scenarios out there in the wild - developers are often creative in inventing their own approaches of how things should work and of ignoring established ones.
There is one scenario I could think of though, where a relative name can be less ambivalent: if chroot or similar things are used, then for example a symlink using an absolute path can result in a different target file inside and outside the chroot, while a symlink using a relative path might still point to the same file. And this difference might actually result in a security issue.


What can protect a C file from buffer overflows?

Try to attempt an overflow with your payload under GDB and debug it. I bet the problem is that your payload contains characters considered special by the input function in the binary, such as \0 or \n. Input function simply stops writing to the buffer after encountering them.


Could this solve SQL injection and XSS vulnerabilities?

Both of these ideas have already been proposed.  From a security perspective, they can be made to work.  However, they are not widely adopted because they require too drastic a change to the way that developers write code, and many developers are not willing to do that.

That said, there has been more recent work on better approaches, approaches that achieve similar security properties but without disrupting the way that developers write code nearly as much.  So your idea is not without merit.

Early, seminal research. To see your idea worked out in greater detail, look at, e.g., this research paper:

Static Enforcement of Web Application Integrity Through Strong Typing, Wil Robertson and Giovanni Vigna, Usenix Security 2009.

It looks at exactly the idea you proposed for defending against XSS, builds a framework that works in that way, and evaluates it.  It turns out you may want to do something a bit more sophisticated than you suggested, to prevent the app from inadvertently adding script tags (while still allowing web pages that are intended to have script tags, to have them), but it's feasible.

The primary shortcoming is that it radically changes the way you write web applications, and it is less convenient for developers.  Instead of writing a simple HTML fragment like

Hi John!

, you have to write several lines of code with several DOM operations.  As a result, your code gets wordier.  This is a barrier that makes it harder to persuade developers to adopt the idea.

Since then, there has been a lot of work on attempting to make this sort of idea more palatable for web developers.  Let me outline some of them.

Context-sensitive auto-escaping. Today, the best defense against XSS is to use a web programming framework that supports context-sensitive automatic escaping.  The idea is that the web framework automatically identifies what escaping function needs to be used for each variable that is dynamically interpolated (at runtime) into the HTML, and automatically applies that escaping function.  This is great, because it provides a framework that is "secure-by-default" and "secure-by-design".  There's a lot less opportunity for developer error or developer oversight to lead to a severe vulnerability in the web application.

Context-sensitive auto-escaping is an especially good match for frameworks that are based upon a template engine: i.e., where the framework enforces separation between code and content, and uses HTML templates for the content (with holes that can be dynamically filled in based upon the results of the computation by the code).

However, today only a few web frameworks currently support context-sensitive auto-escaping.  Google's ctemplate does.

To learn more about context-sensitive auto-escaping, read the following questions on this site:

Filter user input before the database or upon display?
Current best practices to prevent persistent XSS attacks

and the following research papers:

Context-Sensitive Auto-Sanitization in Web Templating Languages Using Type Qualifiers,
Mike Samuel, Prateek Saxena, and Dawn Song, CCS 2011.
A Systematic Analysis of XSS Sanitization in Web Application Frameworks,
Joel Weinberger, Prateek Saxena, Devdatta Akhawe, Matthew Finifter, Richard Shin, Dawn Song, ESORICS 2011.
GuardRails: A Data-Centric Web Application Security Framework, Jonathan Burket, Patrick Mutchler, Michael Weaver, Muzzammil Zaveri, and David Evans, WebApps 2011.
Efficient Character-level Taint Tracking for Java, Erika Chin and David Wagner, 2009 Workshop on Secure Web Services.

Interpolique.  Interpolique is a proposal by Dan Kaminsky that attempts to defend against these vulnerabilities in a way that is a bit less obtrusive and more familiar for PHP developers.  (See also Blueprint, for a predecessor.)  You can find a detailed evaluation of Interpolique at this question: Interpolique: transparently preventing SQL Injection and XSS with base64 encoding, what happened?

Prepared statements. Today, the standard defense against SQL injection vulnerabilities is to use prepared statements (strictly speaking, parametrized queries; but many developers know them as prepared statements).  This is a "good-enough" defense against SQL injection.  It is widely supported by databases and frameworks, well-understood by developers, intuitive and familiar to developers -- and provides "good-enough" security.  Therefore, there is little motivation or need to develop or adopt better solutions for SQL injection.   Today, the predominant problem is not that people use prepared statements and end up with vulnerable code -- the predominant problem is that too many web applications still use string concatenation rather than prepared statements.

Therefore, SQL injection is largely a solved problem, from a technology standpoint.  That's why most of the research focuses on XSS, which is a considerably harder problem.


Changing the PSK has absolutely no effect on KRACK. KRACK doesn't give an attacker access to the PSK. KRACK is an attack on the process that exchanges the PTK/GTK between the client and the AP. A successful attack will allow the attacker to calculate the PTK much more easily (or in the case of very broken clients set the PTK to all 0's). This will happen no matter what the PSK happens to be and changing the PSK doesn't change this attack in any form.

If you believe a connection between client and AP is compromised, simply disconnecting the client and reconnecting is sufficient to generate a new PTK. Just make sure that connection isn't subsequently attacked and compromised as well.

If you want to protect your "high value targets," you should:

Patch both the AP and the clients.
Don't rely on a single layer of encryption, especially one that only protects from the client radio interface to the AP radio interface.
Enable 802.11w to prevent deauth/disassoc attacks in the first place.