Why must I use numbers when displaying SSHFP DNS records? I'm writing a DNS client, where records are queried and shown to the user, and I'm adding support for the SSHFP record type, which stores SSH fingerprints. Records of this type have three fields:

The public key algorithm number (where 1 is RSA, 2 is DSS, 3 is ECDSA, among others)
The hashing algorithm number (where 1 is SHA1, 2 is SHA-256)
The fingerprint itself

After parsing the first two numbers from the packet, I was ready to write code to display "DSS" or "SHA1" for the algorithm fields, instead of just displaying "2" and "1". However, in §3.2 of RFC 4255, which specifies the record type, this is explicitly forbidden (bolded for emphasis):

The RDATA of the presentation format of the SSHFP resource record
consists of two numbers (algorithm and fingerprint type) followed by
the fingerprint itself, presented in hex, e.g.:
   host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890

The use of mnemonics instead of numbers is not allowed.

Why is this the case? Surely anyone who reads these numbers will go and look them up anyway, and as this is a presentation format rather than a data format, the underlying data will be the same no matter how it's shown to a user.

The presentation format is part of established DNS terminology, as explained in RFC 8499, 5:

Master file:  "Master files are text files that contain RRs in text
form.  Since the contents of a zone can be expressed in the form
of a list of RRs a master file is most often used to define a
zone, though it can be used to list a cache's contents."  (Quoted
from [RFC1035], Section 5) Master files are sometimes called "zone
files".
Presentation format:  The text format used in master files.  This
format is shown but not formally defined in [RFC1034] or
[RFC1035].  The term "presentation format" first appears in
[RFC4034].

It is in the master files or zones where you should use this presentation format. GUI clients and configuration interfaces are free to present the data however they like, and they do.


Securing ASP.net web api (REST) I am developing a middle-ware web service app (REST) using ASP.net MVC-4 web API.

The rest services are consumed by android, ios, angularjs client apps. The same user is able to use multiple platforms at the same time.

Can anyone advise me which is the best protocol for my purpose? I read articles about JWT, HMAC, auth, auth-2 protocols, but I am not able to take the right decision.

JWTs are a good way to approach this. My two cents would be to sanitize any and all user input on the client side (reduces surface area for XSS attacks), and use cookies as a medium for transporting the token between client and server. Set the token expiration times to something where, even if it gets stolen, it won't be useful for long. You can lookup XSS prevention cheat sheets which will provide more information regarding XSS prevention. And finally, if this is a production level app, have it pentested or scanned by a tool like Mozilla Observatory. Hope this helps.


How do I hide the OS I am using from internet sites? I am currently trying to mask the OS system I am using from the websites I visit. I'm doing this for an added layer of security. How would I go about hiding the OS from websites?

It is not currently possible to hide the type of OS from a website

A solution against general fingerprinting and obtaining more specific information about your system is to use Tor Browser with the security slider set to high (in order to disable JavaScript). It is designed with fingerprint resistance in mind, attempting to look identical to all other instances of the browser. It provides resistance in several ways:

Unlike a regular connection or a VPN, Tor exposes the network stack of the exit node, not of your own computer, so you do not have to mess with advanced TCP option mangling firewalls or modify low-level networking code in your operating system.
With JavaScript disabled, system-specific behavior like high resolution math libraries (certain trigonometry functions give unique results for each operating system) and data formatting functions (which format the data in an OS-specific way).
The user agent is standardized. There is no way to know what the underlying system is from just the user agent itself. Changing the user agent randomly makes you stand out as one of the few people doing it, so using a standard one is preferred.
The default window size is standardized, so CSS and JS functions which obtain the window size cannot guess your operating system based on things like the size of your task bar.

However, the task of preventing the general type of operating system from being known is currently impossible, even on Tor Browser. A list of whitelisted fonts is provided in order to prevent font rendering exploitation or font fingerprinting, but the whitelist is different for Linux, OSX, and Windows due to needing to use system fonts. There is currently no way around this. Until you find a way to provide system fonts without revealing what type of operating system you are using, you'll have no lock.

Also note that EFF's Panopticlick is only meant to bring awareness to the issue of fingerprinting. It is extremely limited in what signatures it looks for, and does not analyze a representative sample. You should instead look into https://amiunique.org/, which was designed from the current most extensive research into browser fingerprinting.

How does fingerprinting work in general?

While it is not possible to hide the general class of operating system you are running, you can make it so that you blend in with the so-called "anonymity set". A list of ways you can fingerprint a browser, with some notes, in case it is helpful:

TCP/IP stack fingerprinting - The TCP protocol provides some extra extensions changing its behavior such as window size (unrelated to browser window size), max segment size (MSS), time-to-live (TTL), and others. It is also padded by a nop option which does nothing but make sure the size of the options are consistent. Different classes of operating systems use different values. Linux for example sets the TTL to 64, whereas Windows uses 255. Additionally, the order of these options and where the nops are inserted differs from OS to OS.
Generic settings exposed by the browser - Certain things like the order of headers and the headers themselves can uniquely identify a browser. This includes thing like the system locale, DNT status, cookie status, etc. This is effectively all EFF's Panopticlick looks for, and a small subset at that.
WebGL fingerprinting - When certain types of hardware acceleration are enabled, the browser gets low-level access to your GPU. By telling the GPU to generate certain 3D shapes with special graphical properties (textures, light, transparency, etc) and applying various transforms to it and then hashing the resulting pixmap, quirks unique to your specific GPU can be identified. This allows a browser to be identified regardless of the operating system it is run as.
Audiocontext fingerprinting - Similar to WebGL fingerprinting, the browser can be told to generate triangle wave audio, then compress it, then increase gain and hash the resulting audio buffer. This hash will be unique to your system, regardless of what you have booted into. There is no need for the audio to actually be played for this to work.
Timezone fingerprinting - The system's timezone as set in environmental variables is available via JavaScript.
Math library fingerprinting* - When certain trigonometry functions are used, such as calculating the sin of the value 10, the system's math library is called, and this differs for each OS. It will likely be the same among classes of operating systems.
Canvas fingerprinting** - By generating a visual canvas element and hashing it, results unique to your browser can be obtained.
Window size fingerprinting** - The CSS @media elements can be used to selectively load resources based on the (often unique) size of the browser window. A website can create a large number of resources and see which ones your browser loads to tell the window size.
Font list fingerprinting - Your font list is often fairly unique, and differs between different OSes. As mentioned earlier, there is no practical way to avoid this. Keeping a list of whitelisted system fonts reduces the fingerprinting accuracy to the general class of OS you are running.
Date format fingerprinting* - If you call Date().toLocaleFormat() in the browser, the output string will depend on the operating system you are using. The output on Linux, OSX, and Windows 7 respectively is "Thu 26 Mar 2015 03:43:35 PM EDT", "Thu Mar 26 15:38:55 2015", and "Thursday, March 26, 2015 3:45:01 PM".
Virtual core fingerprinting* - The hardwareConcurrency JavaScript feature can be used to automatically spawn a number of threads for performance. By starting with one and increasing it gradually, while giving the browser a CPU-heavy workload, the number of virtual cores can be guessed based on the point at which more threads no longer improve performance.

* Tor Browser only mitigates these if JavaScript is disabled.

** Tor browser mitigates these with help from the user, so the user must follow its recommendations.


RSA 4096 vs. ECC Curve 25519 I want to use GPG to encrypt files before storing them as backup in the cloud. I don't care about interoperability or performance/resource consumption during encryption/decription. I only care about security.

In this case, would RSA 4096 or ECC with Curve 25519 be the better choice? Which one is more secure from today's perspective? Which one will be more secure if quantum computers become a reality?

RSA and ECC are asymmetric encryption algorithms which are considered by experts to be the types of algorithms relatively easier to break by quantum than symmetric encryption standards.
For file encryption and storage you should therefore take a better look either at AES256 or Serpent. Both are symmetric.
two Quotes by the expert Daniel Bernstein:

"In contrast to the threat quantum computing poses to current
public-key algorithms, most current symmetric cryptographic algorithms
and hash functions are considered to be relatively secure against
attacks by quantum computers."
"While the quantum Grover's algorithm does speed up attacks against
symmetric ciphers, doubling the key size can effectively block these
attacks."


Storing passwords online using Gmail documents Following this discussion about "Online Passwords Managers" I wonder whether it is a good idea to store the passwords using a spreadsheet inside Gmail documents? I mean, it seems to me that these password will be as safe as my Gmail account which I consider to be safe enough. Is my assumption correct, or this way of storing passwords is not recommended?

I have done that before and it is a fairly good solution when you need to share certain password lists with other administrators. Yes, your gmail account can be somewhat safe if you use it correctly. On the other hand, gmail is also a pretty big target, is susceptible to government subpoenas, and you have to be VERY careful that everything that connects to your gmail account uses a trusted SSL connection. It is very easy to take over a gmail account just by sniffing unencrypted traffic.

My preferred solution, other than an online password manager, is to place a password-protected excel spreadsheet on a shared cloud storage folder.


Is VPN the best solution against man-in-the-middle attack? I'm looking for the best way to protect my enterprise against man in the middle attacks, because a lot of people connect to the same network.

So I was thinking of creating a VPN. Is this really the best solution against MitM attacks?

Setup proper 802.1X authentication / WPA-Enterprise to connect to the network. So each client will have their own credentials and they'll be logged accordingly.

VPN could also be set up in the same manner if you need remote access. All of these protocols are designed with security in mind and thus inherently prevents any form of MITM attacks if implemented correctly. Basically, it creates a secure tunnel to communicate between client and server which coupled with secure authentication protocols would prevent anyone from monitoring, modifying or impersonating your communication.


How much security would I lose if I enabled "easy enter" pins on an android device? There is an option on android devices to unlock when the correct pin/password is entered, but without the user explicitly pressing the "done" or "enter" button. How much security does this remove from the device? is there any sort of limit to prevent many login attempts via this method? (granted, one may not know if this option is enabled or not... )

Are there other systems besides android that have this feature? what sort of mitigation do they implement?

It would not take away any security. Simple, Easy enter pins would simply auto-OK or auto-ENTER when 4 digits have been entered - just like iPhone. However, it would still mean that incorrect attempts are counted and at too many attempts the device is locked and require online authentication via google account.

The implications "Easy Enter" could have, is if the device is in pocket along with some other things in your pocket, and it accidentially push the home or Power button leading the touchscreen being activated, then Those things (like keys, wallets etc) can accidentially enter too many incorrect pins in a row , causing the device to be locked.


How to change TEA round count? I cribbed the public domain TEA source from wikipedia ( http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm ), looks like this -

uint32_t v0=v[0], v1=v[1], sum=0, i;           /* set up */

uint32_t delta=0x9e3779b9;                     /* a key schedule constant */

uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3];   /* cache key */

for (i = 0; i < 32; i++) { /* basic cycle start */
   sum += delta;
   v0 += ((v1 << 4) + k0) ^ (v1 + sum) ^ ((v1 >> 5) + k1);
   v1 += ((v0 << 4) + k2) ^ (v0 + sum) ^ ((v0 >> 5) + k3);
} /* end cycle */
v[0] = v0;
v[1] = v1;
}

It works fine, but I am trying to understand crypto a little more so I am tweaking and exploring. I would have thought that changing the number of rounds (32 in the example) would work great as long as the decrypt function changed to use the same number. However, I bumped it to 50 on each side and now my output does not match the initial plaintext. Thinking that may be too high, I tried 20; no dice. Then I thought to try very close, set it to 31 then 33, and neither worked.

Is the number of rounds in TEA required to be 32 for some reason? I cannot see why, but I am far from expert.

Sure enough Thomas, the decryption constant 0xC6EF3720 is simply 0x9e3779b9*ROUNDS and needs to be adjusted accordingly.


Do WordPress vulnerabilities matter in intranet? My company is comsidering to use WordPress as an internal blogging platform. It would be installed on a server that is accessible only through our intranet, no exposure to outside world. It would only be used as news page, with all the customizations done on our side (no third party plugins or layouts).

I would like to understand the risks involved in using WP this way. Do the vulnerabilities matter that much if the platform would only be available to internal employees and distributes the content that would be available to them anyway? Are regular updates enough to limit the risk?

This question is two-fold really. First, what are the vulnerabilities of a wordpress site within your intranet, and the second are what are the risks of certain employees to that intranet. So i'll tackle this in two parts for clarity.

Intranet and Wordpress

A lot of companies set up internal sites for various reasons, but proper configuration should be done anyway, since WP itself has a lot of vulnerabilities. One of the more prominent security issues is the ease that its login credentials can be brute-forced.

Just because the site is on a company network, doesn't necessarily mean that it can't be reached / used by people on the network. If any machine that has access to the intranet becomes compromised, it can be used to access this WP site. A technique known as pivoting, allows an attacker to compromise one machine and then use that to leverage other machines on the same network quickly. So the WP site should still conform to security standards, eg. proper authentication, strong credentials, etc. Depending on what data is going to be stored behind this page, extra measures should be taken, will it be a blog? will it be a portal for employees to see their payslips? etc.

Employees

Within any company there will be various forms of risk. Whether this be internal, like disgruntled employees, or external actors, like competitors, criminals, etc. The goal is not to reduce them as much as possible.

Internal employees have a certain level of inherent trust, as in they may have key-cards to open doors, access to certain sensitive information, websites, etc. And this can and often does lead to acts of fraud or collusion occurring, where the employee might feel as though they deserve more, they should've got that raise, they work hard, etc. etc.

Internal actors still need to authenticate with the system to gain access to its internal assets, however it can be just as much a risk if someone wants to cause damage if they get admin credentials for that site, allowing it to be used as a platform for various other attacks.

External actors will have to get into the network first, which can be done in various ways, but a poorly configured WP site would be an excellent target to compromise, and possible use to pivot, maybe the admin credentials for the site are the same for someones laptop?

In any case, an internal site should be configured to at least a certain standard to avoid cases where it can be exploited. I hope this answers your question - if not I'll be happy to add more to it if you have further questions.

EDIT: I came across this article that highlights the points made in the "Intranet and Wordpress" section of the answer. Specifically about identifying sites on local networks and bruteforcing logins. it can be found here.


Best way to do security testing for a server behind nginx proxy I'm trying to do some security testing for my server(not a web server) which is sitting behind a nginx proxy.
To start with it, I've done some fuzz testing using Sulley. As expected, most of the fuzzed requests were handled by nginx. I also tried using BED tool but since my server expects request on a specific URI(http://host/(uri)), I was not able to make the best use out of it. (is that possible?)

My question- is there any further scope of doing fuzz testing(which I might have missed)?
If yes, then what tools can be used?

I'm also looking for a tool for doing penetration testing. Thanks in advance for your inputs.

I agree that Burp suite is a good tool, but there are a lot of different types tools to perform penetration testing. Tools are useful for pentesting but you need to understand the application and environment. Then you can select the right tools for the job.

You indicated that your server isn't a web server, but is behind a nginx proxy, so what kind of server is it? Understanding the environment and "attack surface" is the first step.

Once you understand that, you need to look for vulnerabilities and attack vectors. Once you find a vulnerability, then you need to understand if it is exploitable.

Much of this can't be done by a tool.

Check out "Engebretson, Patrick. The Basics of Hacking and Penetration Testing: Ethical Hacking and Penetration Testing Made Easy, Second Edition. Syngress Publishing. © 2013" for a good overview of pentesting.


Preventing reflected XSS in URL We have just had some pen testing completed against a web application and the one area identified as High Impact and Medium Probability was:

Cross-Site scripting (reflected)

The example given was the ability to manipulate a URL such as:

www.domain.com/application/index.php/<IFRAME SRC=source.com onload="alert(document.cookie)"></IFRAME>

Any data which is actually passed to the application via forms, GET etc are escaped and if you enter the above iframe code into a form and submit or pass it as a GET parameter it "does nothing" but when I go to this URL in a browser, I get varying results depending on the browser ranging from nothing in Chrome and IE to Firefox showing the cookie in a popup.

HTTP response as requested:

GET /application/index.php/%3CBODY%20ONLOAD=alert%28%27XSS%27%29%3E HTTP/1.1
Host: "www.domain.com":http://www.domain.com
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

Obviously I cannot rely on the user using the correct browser so how can I mitigate against this as the code is being passed in the actual URL itself and, from what I can see, is executed before the application loads so I cannot see how I can escape it if it runs in the URL or am I wrong?

There is no genuine reason why anyone should be passing ', ", < or > via the URL so are there server level controls which can strip untoward characters out of the URL maybe using regex in htaccess, for example?

You probably need to google and read about XSS but here's a quick intro. Cross-site scripting is an attack where a hostile site, let's call it H, attacks your site S. H has on it a link to S that has malicious code in it that has been designed to provide the attacker with some benefit (eg: useful information or perform an action). This will likely only work if the user who visits H is currently logged into your site S, but that's OK. Attackers don't care if it doesn't work most of the time as long as it works enough of the time.

One might think that site S can assume that input is always coming from the currently logged in user so S doesn't need to protect the user from inputing dumb things like scripts. But XSS is a means of an attacker tricking a user to appear to input (they haven't actually input it into a text box but the forged request looks similar to that) scripts and other input that is dangerous to themselves. So S must not only protect itself from the user, S must also protect the user from the user because sometimes the user will be a forged link from another site.

Start by reading OWASP's XSS Cheat sheet and look elsewhere for defenses.


Do I need separate revocation certificates for each email address associated with a key? I just created my first OpenPGP key with GnuPG + Thunderbird + Enigmail. The key is used for two email addresses. Now I created a revocation certificate. There is only on of the email addresses included in the filename of the revocation certificate.

Do I need a separate revocation certificate for each email address?

or

Can I use the created revocation certificate to revoke the key for all email address associated with the key?

A dedicated revocation certificate generated with --gen-revoke is created for the primary key and does not include any information on a given user ID, but when distributed will also indirectly revoke all user IDs and subkeys (as they're only valid together with the primary key).


How to update large encrypted files on a server I'm curious how large cloud computing services that might secure encrypted data would update an encrypted file. For example, let's consider a user is using RSA to encrypt a large file, maybe gigabytes long, and stores it on a server. The user then makes a small change to the file. Encrypting this new update again and storing seems like a massive waste of time and resources. How would one counter this problem?

Most encryption algorithms do not propagate changes to subsequent blocks, so you can edit the file in place with the key, and the amount of ciphertext you will be a multiple of a certain size (usually the size of the cipher block or a multiple thereof). The way large encrypted files are typically updated is by having the encryption done transparently, as is the case with filesystem and disk-level encryption.
The only kind of encryption which would force you to re-encrypt everything and re-upload it would be one which uses an all-or-nothing transform, which no modern file encryption methods use.


OpenID connect authentication with cookie authentication middleware [Asp.Net MVC ] In my ASP.NET MVC based application I am using 'OpenID connect authentication' middleware with 'cookie authentication middleware' (session/transient cookie).

While accessing the application I captured requests/responses using fiddler. I logged out of application. However I am able to successfully replay fiddler trace requests captured previously. Is this even a security concern? From the statement it looks obvious yes but when I think deeply, how is it different from capturing username/password in fiddler trace while accessing a bank application?

This behavior does not surprise me and is expected when I look at the way how the middleware pipeline is configured on the server. Basically the request goes to the OpenID middleware component first time when the cookie middleware component couldn't handle it because of a missing cookie, and that is where redirection to the identity provider happens and user is authenticated. After this authentication, the secured cookie between client browser and server only decides authenticity of user. So even though I logged out from the application, the request in fiddler trace still has a valid cookie with which the cookie middleware was able to successfully authenticate request.

The implementation pattern I described above seems to be a standard one, I would like to understand if the scenario I described has any security concerns?

When you use the cookie based authentication it means that your app base on stateless authentication, where stateless means you fully rely on data (cookie) that comes from user agent. In this case it is the most important thing to secure the cookie from stealing.

The case you present here is nothing else like Man-in-the-Middle attack, where you sniff the request and save the authentication cookie. If someone would stole the cookie in other way (like using the XSS or different technique) the result would be the same.

This is why so important is to use all possible security controls to mitigate cookie stealing.

Going back to your case, if you have logged out through browser, the authentication cookie have been invalidated by cookie middleware (overwritten and expired). If someone would send the same cookie (like you did) the only security control I can think of to mitigate this case (please remember about the stateless principle so nothing is stored on server side) is to parse the cookie and validate the expire timestamp (if included in cookie). If expiration time is short enough to be invalid in time of cookie replay, we can react to block the request. If not, we have a broken authentication.


Is it possible to remove data from specific folders on any unauthorized login attempt? I have a Windows 10 PC. I don't want anyone to grab my private data stored on my PC even if they manage to get my login password.
Earlier, I used software that can easily get rid of any administrator password of the OS and log in.
Is there any kind of software or method to wipe our personal data on any sort of unauthorized access to a system?

No. If you can access the system to remove the administrator password, then you can simply access the drive without the method/software to delete the files.
Since you ask about specific folders, you can protect those by encrypting them with something like VeraCrypt and set a unique password for it. That way, if someone gains access to your system they do not automatically gain access to those folders.


Is there a known Facebook auto-posting bug? A minister of Singapore (Vivian Balakrishnan) was found to be in breach of electioneering rules, when several posts were made on his Facebook account on "cooling-off day" (September 10th, 2015, the day before the elections).
He blamed this on a Facebook bug. Story.
Is this plausible? Have there been other known instances of this bug occurring? Or was this Singaporean politician victim to an exceedingly-rare bug? I am a casual Facebook user and not a security expert, but I have never heard of Facebook itself making the mistake of auto-posting to someone's page. (Although I've heard of rogue apps/games doing so.)
Update: According to Channel News Asia:

Facebook has confirmed that a bug in their system led to "recurrent auto-posting" on Dr Vivian Balakrishnan's Facebook page., causing a post to go up on Cooling-Off Day, when candidates are not allowed to campaign offline, or online.
In an email to the media on Friday (Sep 11) a spokesperson for Facebook said, "A bug in our technical system led to recurrent auto-posting on Dr Vivian Balakrishnan's Facebook Page. We are sorry for the inconvenience caused."

Note though that the above news outlet is wholly owned by the Singapore government. I can find no official statement from Facebook.

Without an official statement from Facebook how these posts were made, we can only speculate.

Many organizations which use Facebook professionally for social media campaigns, like election campaign offices of politicians, do not use Facebook directly but use software tools to post content. Such tools can be configured to schedule a time and date when a prewritten message is posted.

It is quite likely that these posts were made through such a tool. A bug in such a software which gets the posting date wrong might be conceivable, but in my opinion human error (someone in his social media team doesn't know how to use the tool or wasn't aware of the cooling-off day rule) is far more likely. But in both cases the problem is on the politicians side.


How can someone track work activity? Problem:

Recently we had an interesting thing which happened at work. My colleague was playing some Flash games at work and after some time someone from organization remarked about that and asked to oversee him. The situation is curious, because we are the IT department and while there are more IT specialists in our organization, I was under impression that there is no observation of employees. While it in itself is a trivial matter as we just laughed and dismissed that, I'm still curious how someone can find out activity on computer?

I had tried:

Now, I have administration privileges on my computer. I had removed all sharing and team viewing options in Windows 10 just in case, though most were off either way. I had checked ESET antivirus and could not find anything unusual there either. I had checked the installed programs menu and could not find anything unusual either, all the bare basics and I could say roughly what each software is responsible for. It doesn't seem anything to be installed on my end either. I have only suspicion that my activity could be potentially observed in internal network and through data packets someone could observe that someone is roughly doing.

Question:

How my activity on computer could be observed in my case? Is there anything that could be done in order to protect my privacy?

To me there are 3 possibilities:

Endpoint surveillance program, one that is hidden from the user. Even with admin privilege, you might have missed it. For all I know it could be custom made, or even part of the OS.
Real world observation, people talk.
Firewall/traffic monitor. Someone maybe just saw flashgames.com coming from a certain IP address and made the mental connection. It's not hard to imagine.


Mitigating the new attack on WPA2 involving PMKID A new attack was discovered which allows cracking a WPA2 passphrase without needing to capture the 4-way handshake. While this doesn't weaken the password itself, it does mean that an attacker can begin their cracking attempts without needing to force deauthentication in order to actually capture the handshake. I am wondering how this can be most effectively mitigated.

Since this attack requires roaming, is it enough ensure that 802.11r is not enabled and to set rsn_preauth=0 in the hostapd configuration to disable 802.11i/RSN/WPA2 pre-authentication?

This doesn't seem like an effective mitigation as disabling roaming would simply mean that the 4 way handshake has to occur any time that the AP the client is connecting to changes, so it would mean that any time roaming actually occurs, the original vulnerability would still be a problem.

Unless the roaming is not actually needed or the roaming vulnerability is somehow worse than the attack on the 4 way handshake, I'm not sure that this suggested mitigation is particularly effective.  If you don't need roaming, then there is no reason not to turn it off though.

Caveat, I'm not an expert on WPA2, so I'm working off a basic reading on the subject, so if anyone who knows more wants to chime in to either confirm or deny my analysis, that would be great.


Systematic exploitation of software components My question is rather generic. People are likely to downvote the question and admins will be tempted to close it at off-topic etc. But, I couldn't help myself asking the question to seek some fruitful answers.

Numerous software bugs/vulnerabilities/exploits are being found everyday. Security forums and mailing lists are getting overwhelmed by receiving the amount of posts researchers/users/engineers are posting everyday. CVE/NVD databases are getting filled up at lightening speed. What has surprised me for quite a while is how people are finding so many bugs in a short span of time, unless a large number of software are systematically explored/hunted for loopholes. For example, this guy has reported six bugs in this year so far.

As far as the bug-hunting techniques are concerned, what I can think of are the following:

Black-box fuzzing (for both open and closed source products (COTS))
White-box fuzzing (for open source products only)
Symbolic execution guided search (not so scalable, to my knowledge)
Reverse engineering (hectic, quite a lot of man hours involved)
Hitting a bug by-chance (probably applicable to the cases reported by most of the end users)
Code walkthrough (needs access to the source code, suited for internal auditing or open source products)
Static analysis tools that helps in finding bugs of known patterns
Dynamic analysis tools (not much familiar with this)

Still I wonder if any combination of all of the above can lead to discovery of so many bugs at such a rapid rate. Is/Are there any major techniques(s) I am missing?

I think this is probably a purely numbers game - there are a lot of people whose sole occupation is looking for security holes. Many of these people work for security consultancies and security service companies, and the kudos of finding and reporting is worth a lot to their brand.

There are some fruitful strategies as well - for example, fuzzing input parameters can often cause unexpected crashes and error messages and these may not be security issues, but they certainly suggest that further investigation would be useful. Chasing product update cycles is also interesting - software updates are surprisingly rich in security issues quite often because they may be released in exceptional circumstances such as time constraints or lower QA testing etc.

In the end though it's just the number of people and the number of hours applied I suspect.


How to determine and compare risk in methods for document exchange Lets say you are talking to a representative of a bank or government institution on the phone, and the representative requests that you send some documents, e.g. document A, B, and C. You ask if you can send the documents by e-mail (method 1), but is told it is not a secure enough method. Alternatively you can log on to the institution's web-site and upload the documents (method 2), or you can send them by physically by mail (method 3).

Is it possible to quantify the risk of these methods somehow? Why would method 1 be less secure than method 2 and 3, when the number and type of documents match what was agreed, and your name is stated on them? Who could possibly interfere the exchange that happens in method 1, compared to method 2 and 3?

Alternatively, why is method 1 considered not to be secure enough?

You don't specify, so I'm going to assume that you want confidentiality (no one but you and the recipient must see the contents of the documents) and integrity (the recipient should receive exactly the documents you sent without any modification).

Method 1: Email

Email is horribly insecure. Every mail server between the sender and the receiver necessarily gets a copy of everything in the email, and unless the email is signed with DKIM, each server could also modify it at will before sending it to the next.

Method 2: Website upload

Assuming the website uses TLS (i.e. it's an https url), uploaded file(s) will be encrypted between your computer and the website's server, so no one in between will be able to view or modify the contents (though they will be able to see that you sent something and they can tell how large it is).

Method 3: Physical mail

There are plenty of people that could interfere with your mail and view or modify the contents, but it comes with a risk of discovery and legal consequences.

Overview

A website upload is the easiest and safest option of the 3, as it is the only method that reliably prevents anyone but the recipient from viewing or modifying the contents.


Can my school computer see my files via USB? I was issued a chromebook, as was everyone at my school, to use for work in class and in case school has to shut down again. We bring it home so it connects to my personal Wi-Fi when I'm at home. I was working on homework and needed to transfer a pdf file off of my tablet to my chromebook, so I decided to just hook it up via USB. Could the school see all my files and pictures when it was hooked up even though I'm on my Wi-Fi? Are the files on my tablet no longer visible on the chromebook once the USB connection is unhooked?

If they just gave you a stock computer without any modifications, probably not. Usually computers do not automatically make a copy of data from USB drives. However it is not uncommon to store metadata about the files somewhere, for example thumbnails and things like what sort order you picked for that drive. Usually the natural place to store this is somewhere in the same directory, so there's not really information being extracted from your drive. But depending on how exactly the computer is configured, some references may remain on the computer even after.
For example, if you open any files they will probably be recorded in some "recently opened files" menu that will remain even after the USB drive is gone. This will only record the name of the file, not the contents, though. You could simply avoid opening your photos, but it's possible that you have some kind of image browser installed that automatically scans every directory and saves thumbnails elsewhere.
Of course the school could have installed some kind of program that does record some or all of data from USB drives. It may be unintentional, such as an antivirus that collects files it consider suspicious (false positives are very common). Or it may be intentional, if the school IT wants to monitor what students are doing "for their security". Furthermore, the computer may be compromised by hackers, malware or viruses, who install evil software without the school's knowledge.
In practice it is rare for schools to spy on their students in such a blatant way (although it's not unheard of), and from what I know Chromebooks aren't considered particularly insecure (if you trust Google...). But there's also no guarantee that it won't happen. The safest option is:

Use your school laptop strictly for schoolwork
Never login to any personal account or enter any personal password on the school laptop
Never let any private files come on to the computer or touch it in any way
Assume someone is watching everything you do on the computer at all times, and will keep a copy of everything you do on it

By this token, I would never plug in a USB drive with personal photos to a school laptop. I would do a secure erase of the whole drive before and after it touches the laptop, or more conveniently just buy a separate USB stick for school stuff (they're like $10).


How can I see if SSL Certificate is Business SSL? I'm trying to see the visual difference between Business SSL Validation and Standard Validation but I see no difference (or I cannot find a site which contains a Business SSL certificate)

Is there a way to see what kind of SSL certificate has been issued?
 - I know about the green bar for example on HTTPS VeriSign for Extended Validation. But I fail to see the difference between Basic and Business Validation.

The issuer flags EV certificates with an entry in the Certificate Policies extension field.


Security of Javascript in mobile browsers Is Javascript on a mobile browser more secure than Javascript on other types of systems? For instance, if I have a site that includes some client-side (Javascript) encryption code, with the intention that it only runs inside a Safari browser on the iPhone (standalone or embedded in an app) or Chrome on an Android device, what are some possible vulnerabilities? Is client-side Javascript encryption as terrible an idea in the mobile space as the desktop space?

Caveats:

Making an app isn't an option. This question is specifically about the security of the mobile browser environment. I do realize that the built-in APIs would be a far better idea.
Assume that the server hosting the code remains secure, or that the person is running the code locally/offline.

Here's what I've thought of so far:

Hijacking of the actual transmission (solvable via HTTPS, except MITM)
Same-origin (solvable via hosting on a dedicated subdomain)

All other attacks (e.g. exploiting a flaw in the iPhone browser) would seem to involve one of these two. Given the general negative attitude toward Javascript-based encryption, I must be missing something. What am I missing?

A jailbroken iPhone or "rooted" Android device is not qualitatively distinguishable from a desktop system. From the server side, you cannot know whether the device is rooted or not; or even if it really is the device you believe it is to be. Whatever issues Javascript-based crypto can have on "desktop" systems also apply to mobile platforms. Of course, any individual browser (not platform) can have more or less troublesome features in that respect, but browsers are actually fairly uniform across platforms (Safari on iOS shares a lot of code with Safari on MacOS X or Windows, for instance).

This does not mean that Javascript cryptography is inherently doomed; only that you have to work within the constraints of that language and its environment (the browser), which are somewhat adverse to tasks for which cryptography is deemed necessary. In particular:

Javascript code runs on the client, and cannot be protected from the prying eyes of the user, if he is intent on reverse-engineering it (code obfuscation can only get you so far, i.e. not very far). If you embed secrets in the Javascript code, your only actual protection is prayer.
Javascript has very little access to the platform facilities, in particular storage space.
Since Javascript code is not stored locally (it can be cached but caching duration cannot be reliably enforced from the server), it must be redistributed anew from the server. Since unprotected data sent over the Internet can get altered, this distribution must go through some HTTPS, and inherently trusts the server for not playing foul games. Presence of HTTPS and trust in the server remove most reasons why cryptography should be done on the client side.

(If you don't trust the server, then you cannot logically use Javascript code sent by that server. The problem of trusting the server is real -- but Javascript is not the solution for it.)
For bulk computational tasks (e.g. cryptographie), Javascript performance sucks big time.

There is nothing in mobile devices that would significantly modify these constraints, as compared to the situation on desktop systems.


Why use usernames and not just email addresses to identify users? Why use usernames, and not just email addresses, to identify users? - What is the main concern or the main case when a security expert (which I'm not) should recommend inserting another layer of usernames, for example, when a native/web application is created?

Your question is missing a lot of context, but what you do say sounds like you’re looking to settle an argument. So my answer will start with “It depends...”

One reason to have unique usernames that aren’t email addresses is to protect privacy when other users can see the username. For example, GitHub profiles indicate the username in the profile URL, and as authorship indicators on commits, issues, comments, etc.

Providing a username as the user’s public face instead of their email address allows them a layer of privacy.

In some rare cases, a service may elect not to collect email addresses at all... since email addresses can be considered sensitive and personally identifiable information. The downside to not collecting an email address at all is that account recovery for someone who forgets their password, or has their account breached, will be more difficult without a verified channel to use for recovery.

Or for the hybrid approach, one might collect
the email address, but store it in the database behind strong encryption. Strong encryption is generally difficult to search on, so having a less sensitive identifier to use that can be store in plaintext would be convenient.


How find the hash creation method knowing password, salt, and resulting hash? If I know the password, the salt (supposed salt actually) and the output hash (sha1 format). How can I find the hash creation method ?

I tried basic stuff like

    sha1(salt+password)
    sha1(password+ salt)
    sha1(salt +sha1(password))
    sha1(sha1(password)+ salt)

... and a lot more, but all failed.

What is the correct tool to look for the hash creation method ? Is the only best option to decompile the software ?

Decompiling the software is probably easiest.

Passwords are typically hashed with many iterations (like 100,000) of the hash function to slow down brute-force attacks that are trying to guess the password. Typically the server-side hashing code looks like this:

hashval = password

count = 0
while(count++ < NUM_HASH_ITERATIONS):
  hashval = sha1(hashval + salt)

return hashval

Depending on the software you are trying to break, you may be able to find the constant NUM_HASH_ITERATIONS in a config file somewhere, otherwise you'd either need to decompile the binary for it, or brute-force it. I don't know if off-the-shelf software exists to brute-force the number of iterations, but typical values, but it wouldn't be too difficult or CPU-intensive since you just try hashing it, and if it doesn't match, hash it again up to some limit like 1 million

hashval = "password"

count = 0
while(count++ < 1000000):
  hashval = sha1(hashval + salt)

  if (hashval == "3a58f2b..."):
    // We win!

that should run in a few minutes, and try it a bunch of times with different permutations for how the hash and salt are combined. Note that there are lots of things whose output looks the same as SHA1, so unless you know for a fact that it's SHA1, you may need to try those variants with MD5, SHA2-256, SHA2-384, SHA2-512, PBKDF2, BCRYPT, SCRYPT, ...


How to block web-sites from viewing browsing history within firefox? How can I block websites in Firefox from viewing my browsing history within my browser cache? For example; I've done some Google searches that Amazon is now starting to use to target advertise; the issue here is that Amazon is able to view my history for Google; how can I prevent this at the browser level?

They can't view your history as such, they can only create a "cookie" that identifies you on one site then observe that cookie when you visit other sites which they have access to.

Technically there's the do not track header, but this requires them to honour your preference and technically they might ignore it.

There's also extensions like Cookie Monster and Ghostery which allows you to physically discard cookies in certain conditions, such as when they're not for the site you're directly visiting.

Physically blocking the cookies is probably the most effective way to make tracking difficult, but plenty of legitimate functionality depends on cookies so you have to accept that your browsing experience may be degraded. Also, they could use other metadata such as your IP to track you, albeit with less accuracy.


Detect Proxy and Tor exit nodes from an IP in python I have a database (hadoop) of the users who access my website (their IPs) and i want to check if those users either use proxy networks or the TOR network and block them.

I also want to differentiate between an legitimate proxy and fake proxy. In case of tor i want to block all tor traffic.

I also have request_headers in the database and i can see X-Forwarded-For for some of the records. So that i can extract the forwarded ip and the original one but how to detect this proxy is a legitimate or its a tor ip?

This script can be used to get the list of a list of possible Tor nodes that might contact one of your servers. This is basically a list of tor exit nodes which contacted that ip address :
But for your use case this is there :
https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=YOUR_SERVER_IP&port=YOUR_PORT

This is a very raw python snippet that should work for you:

import requests
YOUR_SERVER_IP = '1.1.1.1'
YOUR_SERVER_PORT = '80'
USER_IP = '2.2.2.2'
data = requests.get('https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=' + YOUR_SERVER_IP + '&port='+ YOUR_SERVER_PORT)
if(data.status_code == 200):
    responsedata = str(data.text)
    ip_lists = responsedata.split('\n')[3:]#1st three lines are comments
    if(USER_IP in ip_lists):
        print("Tor usage detected")
    else:
        print("Not Tor")
else:
    print("Unable to connect . Error code :" + str(r.status_code))

Ideally you should save the data on disk and then query it because:

This list is updated only after 16hr.
You cannot query more than 4-5 times in 1hr. (Not really sure about the exact number of times and duration)


What is the security problem of Options FollowSymLinks in the Apache configuration? What is the security problem to use Options FollowSymLinks in the Apache configuration?

We use the following configuration:

AllowOverride None
Options None FollowSymLinks

If you enable following of symbolic links, and an attacker gains access to something allowing him to create arbitrary files on your webserver, he could then create symbolic links to any file on your system (e.g. /etc/passwd, configurations files of databases, ...)


Is there a simple example of an Asymmetric encryption/decryption routine? I can understand Java, Perl and JavaScript code very well. The rest, I have not studied, but I guess I could figure out how to read/translate.

I would like to know what the simplest of Asymmetric routines are. Is it really too complex to want to worry about?

I am just really curious how it is possible to have an encryption-only key! It just seems amazing to me that it could resist reverse-engineering so I want to know how it works!

Is it too complicated for that.
What is (one of) the simplest standard Asymmetric encryption routine(s) that I can look up an implementation for?
If you happen have any minimal code examples that would be nice.

I already checked the Wikipedia paragraphs on How It Works, but there was no mathematical breakdown or description of implementation, just lots of implementations. I did not really want to randomly pick which one to look at, neither did I want to take the most common one which I expect is most robust and most complicated.

Any thoughts?

As far as RSA goes, this provides a good example that can be followed and shows corresponding examples of input and output. This demo application will walk you through the various steps and allow you check the work. Sometimes just clicking your way through something in steps like that will help. For Wikipedia articles, you need to look at the actual algorithm article: RSA for the math that corresponds.

Implementation wise, you can pull this together clearly in Java in under 30 lines.

For your understanding, there is no such thing as an encryption-only key. Rather, there are two equal keys that reverse the operations of their partners. We arbitrarily assign one of the pair as private and one as public. Things encrypted with one key can be decrypted with the other key. This is the principle used with signing.

It is not an issue of anti-reverse engineering that makes the keys safe, but rather a mathematical concept that you can't reasonably check the massive keyspace (when the key uses a really large number space) to find the matching key. There's no real speed-up for factoring work.

There are other asymmetric key algorithms to learn, but as you're staring out I'd try understand RSA, the oldest and most common, first.


Database Security Best Practices for E-Commerce Site Possible Duplicate:
  Securing an E-commerce site

I'm developing an e-commerce site in a LAMP environment. Is it advisable to separate data on to different servers (i.e. to have one server as the web server and another server to house transaction and other customer data)? In other words, from a security perspective is there any reason why I should not house all the data both for the e-commerce webshop and all backend customer and transaction data on a single machine and even in a single database)? [with daily backups of course].

Thanks in advance...

Peter

The main reasons are that you want to put as many obstacles in the way of an attacker as possible, and put different security measures in place for your database server than for your web server.

In general, web servers - being exposed to the public internet and all that - are considered fairly vulnerable. Therefore, you want to keep as little sensitive data on those servers as possible. It would be tragic if a vulnerability in your web server configuration allowed access to the raw database files, or the backups etc. This is why most organizations put the web servers in a "DMZ" - a zone which is not fully trusted. The DMZ is often separated from the rest of the infrastructure via separate network segments and a firewall.

You also want to be able to have different security settings for your database server; often, different people should have access, and different apps should be installed. This is easier to achieve with a separate system.

I often explain this decision by reminding people that they don't leave their wallet on display in the car - you lock it away!


Appilicability of Theoritical Computer Science/Formal methods in Malware research I would like to know the importance of Theoritical CS/Formal methods in Malware research. Due to the large volume of new malware variants received per day (~50,000 samples/day according to McAfee), malware researchers are heavily dependent on dynamic analysis (i.e. running the samples in a sandbox and monitoring their behavior) and moving away from static analysis and Reverse engineering as these approaches are very time consuming and sometimes becomes very challenging due to  obfuscation/encryption.

I found a very useful talk (BlackHat 2010) by Greg Hoglund on Malware attribution where the speaker talks about the importance of bringing in the malware authors and their networks into the picture which gives valuable information than just analyzing the binary itself.

My question is:

If malware researchers move towards analyzing the behavior of malware authors and their network, in the future, does theoretical CS/formal methods has any importance in malware research.

Thank you.

What makes you think that formal methods or theoretical CS will be relevant?

I think a better question is: what tools from computer science might be relevant to this problem?  My answer to that question would be: statistical machine learning methods may be highly relevant.  (You could also look at stylometry -- author identification -- if you are interested in the attribution problem.  However, that may be a challenging research problem.)

Generally speaking, formal methods and theoretical CS are not used much in malware research.  On first impression, they do not seem very relevant to the malware problem.  Today, most malware research happens in the systems community, which focuses on tools, applied work, methods for software analysis, and so on.

To learn more about current research, I recommend reading the research papers on the subject.  You could look at the top conferences (e.g., Usenix Security, IEEE Security & Privacy, ACM CCS, NDSS) as well as conferences focused specifically on this problem (e.g., DIMVA, LEET, WOOT, etc.).


Why should servers be placed outside of the corporate network? In an answer to How do you deal with massive port scans?, user tylerl said:

  ... And you, like a wise IT admin, run all your servers elsewhere on the internet, not inside your corp network, for a whole raft of reasons I won't go into here

As a not-so-wise IT admin, what reasons are these?

Having all your corporate servers in the same network is a bad idea because if one of the servers is compromised, the attacker can easily spread out to the others. Servers are often configured to be secure on the front end, but when it comes to servers communicating with each other, there are various ways to find vulnerabilities. Also the sensitivity of data is often not the same. While a web server is important for the availability, a database server often contains valuable customer data. Separating these is a good idea in any case.

Specialized hosting providers for specific servers are mostly able to keep their servers more secure as well.

Thanks to the internet, there is no reason not to separate servers, unless your application is so time dependent that for example database servers need to be accessed directly.


Why is GPG encrypted message size not proportional to number of recipients & file size? I have noticed that when I am using GnuPG to encrypt a file for multiple recipients, the size of the encrypted message does not seem to be directly proportional to the number of recipients.

For example, a file that I tested is 836 bytes in plaintext.

encrypted for 1 recipient, it is 1090 bytes
encrypted for 2 recipients , it is 1619 bytes (810 bytes per recipient)
encrypted for 9 recipients, it is 4738 bytes (526 bytes per recipient)
encrypted for 51 recipients, 26,397 bytes (517 bytes per recipient)

Since encrypted data should look random, I am thinking that the difference is not due to compression.  Not all of the 51 keys are the same key size/algorithm, but I do not see how this could account for such a dramatic average file size.

How is it that I can encrypt an 836 byte file for 51 people, so that they can all decrypt my file back to its original size without appending at least 836 bytes per recipient?

Because the entire message is not encrypted separately for each recipient.

Instead, a single symmetric encryption key is chosen at random, the message is encrypted once using that key, and then the encryption key is itself encrypted separately for each recipient, using that recipient's public key, and appended to the encrypted message.

Each recipient decrypts the message by first using their private key to decrypt the symmetric encryption, and then decrypts the message using that key.

Since keys are typically much shorter than the plaintext, this saves a lot of space. (It also lets the recipients know they've all decrypted the same message. If the messages were encrypted separately for recipient, a devious sender could send different messages to each recipient, pretending they were all carbon copies of the same message.)

With your data, adding the second recipient added 527 bytes. That second recipient probably had a 512-byte key, plus 15 bytes to identify the recipient. Successive recipients will have had different key lengths and different identifying data, so the amount added for each will vary.


Connection between PIN/password and encryption keys in Android I am trying to piece together some information about the security system in Android. Particularly about how user's password/PIN is connected with encryption keys in file-based encryption mode. I'm doing this for my university project. I've found a lot of useful information on the Android source site. But some things are still unclear to me.

How is passwords/PIN information connected with keys, which are used to encrypt files?

  The stretched credential is the user credential after salting and
  stretching with the scrypt algorithm. The credential is actually
  hashed once in the lock settings service before being passed to vold
  for passing to scrypt. This is cryptographically bound to the key in
  the TEE with all the guarantees that apply to KM_TAG_APPLICATION_ID.

Where does Android store this key: in hardware or some not accessible memory?

  The secdiscardable hash is a 512-bit hash of a random 16 KB file
  stored alongside other information used to reconstruct the key, such
  as the seed

What algorithm does Android use for reconstruction the key?

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


What are the effects of the Chrome Web Developer extension hijack? Today, the owner of the rather popular Web Developer toolbar noticed it had been hijacked and replaced with a malicious version. He disabled it, but the malicious version (diff) had been in the wild for at least an hour already.

What did it do while it was active (besides ad injection)?
What should I do to keep further ill-effects at bay?

Do I need to sign out/in of sessions for any webapps? Revoke keys? Change passwords?

From the Twitter account you have linked, the author says:

  I don’t know for sure yet, but it looks like it may have just been adware being injected. I’m still looking into the possible impact.

You have also asked whatever you should sign out of sessions, revoke keys and change passwords. While I do not have access to the malicious code, and am unable to tell what the code did, I feel pretty confident to suggest that you should end all sessions (to prevent session hijacks), and to change your passwords.

I would say that it is much easier to change passwords than later have to deal with your accounts hacked.


How should multiple system-generated, centrally managed passwords be distributed securely (if at all)? In a system where a single admin user is responsible for the creation of multiple (up to 500) user accounts, including passwords and these user accounts do not have an associated email address how would you approach the distribution of login details?

Currently the admin must choose a password for each user. This results in one or more scenarios:

the admin using the same password for each user;
the admin not creating accounts because the process is laborious;
the admin writing down the passwords (or otherwise storing these) for later distribution.

I'm considering a change to the system whereby we generate a unique code/passphrase for each user so that the admin doesn't have to create each one. We would then allow the user to download these details (i.e. a list of usernames and passphrases) for later distribution. Obviously if we did this we couldn't hash the passwords as we do now. So I think this is a classic usability vs security question. Is our proposed change insane? What haven't we thought about? Am I being excessively paranoid/not paranoid enough?

Further background: Each user added must have a unique username within the system. Email addresses are specifically not gathered because the users are under 18 (some are as young as 6) and it is company policy to reduce the personal data associated with each user to the absolute minimum. This has the benefit of meaning that unauthorised access would be very low risk. There is very little to be gained by accessing the system unless you are the correct user and no personal data could be obtained beyond the user's first name.

I'll give it a go:
Distribution
My suggestion would be to leave the distribution system the way it is, especially since there doesn't seem to be a more secure method of safely distributing passwords.  If you truly wish to distribute the passwords using a web server, I would recommend supplying each user with a time limited unique link.  The user enters the link into a browser, and is logged in but is required to enter a new password before normal access can continue.  This simulates a typical reset password exchange through email, except the one time unique link is printed on paper rather than sent through email.
Unique Password Creation
My suggestion would be to create a simple table in your database of choice that has two columns: username and password.
I use postgresql, but as far as I know, all database systems have a unique qualifier for a column constraint.  You can either have a random password generator output passwords and check them against the current ones in the database... or you can issue a UUID as a password.  A UUID is guaranteed to be unique, and if combined with the weblink idea in the distribution section would only need to be entered once.  In any case, the random password generator combined with a list of current passwords is fairly easy to implement and automate.  Furthermore, the initial password table can easily be exported or even directly linked to the web app database's password table.
Administration Changes
If implementing a database table with automated random password generator, the web app admin simply needs to enter in a new username and the system will create a password.  If implementing a unique weblink method of initial password distribution, the paper distribution will only change in content... instead of a password, there will be a link.
Legal issues and dealing with minors
In some localities, there are specific laws detailing information/computing systems and minors.  If you are not aware of the laws in your area, I strongly suggest finding out if running a system that may include Personally Identifiable Information (PII) of minors has any special security and/or reporting/record keeping implications.
Questions
Does any of this make sense? Helpful? or just confusing?
Addendum
Upon further consideration, I realize that I left out some specific security concerns as well as a few suggestions for implementation.
Database Password Store
It is poor security practice to store plaintext passwords.  There are at least two decent choices when storing passwords in a database:

Store a one way salted hash instead of the password.
Store the plain text password in an encrypted column using the data owner's public key.

In this particular use case, of centrally generated and unchangeable passwords, I would recommend storing the passwords in an encrypted column in a separate database and separate system from the web application.  Of course, the web application's password column should contain the salted hash of the password as per usual security consideration.  Further, exporting a column of passwords in salted and hashed form as a csv vector or table is easily automated with the only administration requirement of the data owner entering in the private key's passphrase.
If the weblink idea is utilized, then there is no need to track plain text passwords, as the admin would never generate one.  But then, the admin would not have a record of the plaintext password.  However, in most cases, access to the actual plaintext password is unnecessary.
Data Growth Rate
Per description of your use case, it is assumed that your data store will grow slowly or not at all.  It seems that you have a rolling enrollment in the application with a static total number of users over time plus or minus some buffer.  If true, then scalability considerations beyond the current number of users are not applicable.
Further Reading

PSQL Crypto Reference
Children's Internet Protection Act


Is there any reason for using private key 2 times when creating security hash? One of the payment solutions for the websites provides the following way of creating security hash for payment link:

hash = sha1(private_key + payment_params_json + private_key);

Is there any particular reason for using the same private_key twice?

This construct can (crudely) protect against a length extension attack, which in particular affects hashes built using the Merkle-Damgård construction (such as MD5, SHA-1, and the SHA-2 family).

The gist of the attack is that an attacker who knows H(s || m) and m for a hash H, secret s, and message m can trivially forge a hash of the form H(s || m || p || a) where p is the internal padding used by the hash function and a is an attacker-controlled string. This may seem difficult to exploit in practice, as p is typically raw bytes such as \x04\x04\x04\x04. However, consider a message such as a set of HTTP query parameters: username=x&admin=false. With this attack, you can forge a "signed" message for username=x&admin=false\x02\x02&admin=true. Depending on how the parameters are parsed, the URL parser could easily use the latter value of admin rather than the former.

Hashing the secret at the end of the message is, presumably, an attempt to defend against this type of attack. Since the attacker doesn't know the secret, they can't use a length extension attack since they have no way of forging H(s || m || p || a || s) without knowing s.

That said, there are existing cryptographic constructs that are proven secure for use as message authentication codes. In this case, HMAC is probably the cryptographic primitive they want to use, as it has a strong proof of security.

This type of home-grown construct is evidence that the authors of this service are not well-versed in cryptography. If they were, an HMAC would be a natural and obvious choice for such a situation. If they are comfortable publishing these kinds of embarrassing home-grown constructs in their public documentation, I would personally worry about the cryptography they deploy and use internally.


Adding custom data in X.509 certificate I am using SSL with client authentication. I need to send some extra data while sending the client certificate? Can I send it in the certificate? Can I use the extension fields in certificate for that ? The amount of data to be send is very small. Usually an id and some permissions. This something i should send only initially. Is there any other better way?

While you can stuff about everything you can imagine in ad hoc extensions in a certificate, this is rarely a good idea. In particular because the certificate is signed (by the Certification Authority which issued it), so whatever you put in the certificate has to go through the CA first.

Certificates are about authentication and this does not live well with authorization. Certificates are long-lived entities which cannot be altered on a whim; the only way to "modify" a certificate is to revoke it and issue a new one; not only must this be done by the CA, but it is an inherently asynchronous process: it takes at least several hours, more often several days, to propagate revocation information with any kind of reliability (and some clients do not verify revocation at all...). For anything related to permissions, you want a system which reacts quickly, because when you want to remove an access authorization, you want to remove it now, not next week.

If, in your protocol, the server has something to say to the client, then it seems more appropriate to send the data in the SSL tunnel, after the handshake, as part of the inner protocol (in the same way that HTTPS is HTTP within a SSL tunnel).


How to remove quarantined virus securely? There is a file found by antivirus program and it was put into the virus' quarantine section (its not a false positive). Now I don't know how to handle this "quarantined" files.

What is the best practice and secure way to deal with them? Delete from quarantine, or let them in there?
If I delete a file from the quarantine, does it mean that it goes to the "recycle bin" of the computer and is thus still existent on my PC, and could be recovered by some tools like Recuva?  Or will it be gone forever?
What happens if there are files in the quarantine and you accidentally uninstall the antivirus program from your PC, what happens to the files?

Although a lot depends on the anti-virus software, I'll try to answer your questions:

  1) What is the best practice and secure way to deal with them? Delete from quarantine, or let them in there?

Do you plan to study the virus and its working? If yes, then you might want to keep it (This will require a restore of the file).
Do you think it might be a false positive? If yes, report it to your anti-virus vendor for a re-evaluation, and if it turns out to be a false positive, you can restore the file(s).
If you don't plan to do anything with the file (and don't want to restore it either), you can delete it.

  2) If i delete a file from the quarantine, does it mean that it goes to the "recycle bin" of the computer and is thus still existent on my PC, and could be recovered by some tools like Recuva? Or will it be gone for ever

This largely depends on the implementation of the anti-virus. No reputable vendor would send the file to recycle bin.
Can they be recovered? Potentially yes. Even if the anti-virus program performs several iterations of deletion on that part of disk, the file could be potentially recovered using specialised techniques and tools.

  3) What happens if there are files in the quarantine and you accidentally de-install the antivirus program from your PC, what happens to the files?

It should not affect your system, as the files are stored in a binary format. More details can be found here.

EDIT:
As user user21820 points out in the comments, there's nothing to worry about if the file in the quarantine is deleted using multiple overwrites.


show previously hacked passwords with John The Ripper I tried to crack my windows passwords on the SAM file with john the ripper, it worked just fine, and it shows me the password. But when i try to hack the same file again, john just tells me :

Loaded 4 password hashes with no different salts (LM [DES 128/128 SSE2-16])
No password hashes left to crack (see FAQ)

How can i see my previously hacked passwords ??!!

To see previously cracked passwords, from the file hashed_passwords.txt that contains hashed passwords, we use this command :

john --show hashed_passwords.txt


chipTan in combination with bank's portal or mobile application I use chipTAN for authentication in banking-context because I think it's the better second factor.

Till now I use the bank´s portal via a browser on my PC.
In future I want to use the mobile application provided by the bank.

Now is the question is the mobile application more insecure than the bank's portal?

If this isn´t the case, is there a difference between use the bank's portal via a browser on my PC or via a browser on my mobile phone?

It's difficult to say if the app is more or less secure than the web portal without access to security testing data, there is no default 'x is more secure than y' scenario. It depends on many factors.

There may be a difference between the portal you use on your PC and the portal you use on your phone.  Web applications will often deliver a different UI based on the user agent and it is possible that some of these underwent different levels of security engineering and security testing. Again though, there is no way we can tell you without carrying out a security audit of the application.


How to protect against random number generator attacks I am using custom hardware on which i'm using the random noise from an ADC converter and a few other seeds. I combine these in an algorithm and have tested it against FIPS PUB 140-2 for a random number generator. It has passed the test but I'm reading up on RNG attacks and do not fully understand these attacks.

If people would mess with my seeds is there anything i could do against it? the hardware is in an insecure environment so if an attack would go through the trouble of opening it, finding the sources and so on, there is nothing i can do against it is there?

Is there anything you can do to make your RNG secure other than choosing multiple seeds?

Let's start with the disclaimer: I'm not a cryptographer, creating your own RNG is usually a bad idea, blah, blah.  That said I have an idea:

Try measuring entropy of the RNG:

https://crypto.stackexchange.com/questions/10404/estimating-bits-of-entropy

When it gets too low due to an attacker (or cosmic rays) you stop providing random numbers until entropy reaches acceptable levels.

How much entropy?  Depends on your key size.  A 256 bit key with 20 bits of entropy is no more secure than a 20 bit key so I would suggest a target entropy equal to the biggest key size you will be working with.

Hardware being in an insecure environment is not a solvable problem in my eyes.  Aside from esoteric RNG attacks, the most straightforward approach would be to gain control of the device and compromise your encryption from there.


I had SSL certificate on my site but still it has been hacked...how to prevent this from happening? I used SSL certificate on my site but still it has been hacked.

How do I prevent this from happening?

Do SSL certificate come with a waranty which would compensate me because my site was hacked?

An SSL certificate protects users of your site from having their communications intercepted by a 3rd party. I think it is likely that when you say your site was hacked, this isn't what you're talking about. An SSL certificate does not validate the content of your site, nor does it prevent anyone from accessing it as intended or otherwise. Controls for these are outside the realm of SSL.

There is no warranty regarding SSL certificates other than potential civil liability. Unless your certificate itself was compromised by actions of the issuer, you have no case against them and no warranty is implied.

As far as figuring out what was insecure about your site, how you were compromised, or what needs to be addressed to fix it, you need to have forensic analysis performed on your compromised machine. A review of the website code for the site in question may also be in order.


Being anonymous on the Internet I change my IP, and then I want to access a website with a new identity I also need to delete the cookies. Would that be enough? Are there any other ways to store information and get it back with the next request?

Use the Tor browser.

There are many ways besides cookies to track browsers, especially if you have Javascript enabled. The Tor browser pervents most of the more common browser fingerprinting techniques.

This site explains how browsers can be tracked, and has a feature to test if your browser is vulnerable.


Future proof encryption possible in theory? Let's say I have a message that I want to keep safe for the next 100 years. Is it theoretically possible?

Let's say the message is unique (raw picture data, raw video video data, raw text data) and the key is unique. Can anything prevent (near)future brute force attack?

TL;DR in bold:

We don't have crystal balls to predict where technology will take us, but the purpose of cryptography is to develop algorithms that have just this kind of resistance on a very fundamental level.

Mathematically speaking, in terms of "honestly" brute-forcing a single plaintext from a single ciphertext, knowing everything that would otherwise be needed to decrypt the plaintext other than the key, a 256-bit block cipher should be considered uncrackable by the laws of thermodynamics; our Sun will not emit enough photons in its active life (before it becomes a black dwarf) to enable a computer that works at the electron level with perfect efficiency to try every possible key in the 256-bit keyspace. The computer would be starved for energy after trying about 2^218 key values, meaning that if it tried keys perfectly randomly without replacement, and the key was also chosen perfectly randomly, it would only have a one in 275 billion chance to have found the correct key, given roughly 5 billion years before the Sun goes nova.

There is, however, one distinct disadvantage to the use of any computational hardware or software in existence today; it is already obsolete. It would be foolish to assume that any binary implementation currently used to encipher messages, nor any computer, language or even logical structure used to develop or execute that binary code, will still be in existence in 100 years. We already have problems with the availability of hardware that can read or write storage devices that were universal standards only 20 years ago, like floppy disks and tape drives. Even power plugs have changed fundamentally in the last 50 years, and those plugs and receptacles (and the exact specs of the power they use) are only regional standards as it is. Hell, 100 years ago we were riding horses, not driving cars. So, if you plan to encrypt something and then store the device used to produce it, I can virtually guarantee that in 100 years everything about the device will be so obsolete it will be unusable.

Given this 100-year expected timespan, I would rely on one of the simplest and yet most secure ciphers known to man; the one-time pad.

Simply create a numeric "alphabet" relating a number value to every character symbol you wish to be able to encipher (don't forget any needed punctuation, such as spaces, commas, periods, single/double quotes etc; you must not use more than 100 symbols, but most fully-formatted English-language messages will be well underneath this limit, even with capital letters). Then, gather a series of numbers, from zero to 99. You will need one of these numbers per character of the message. These numbers must be genuinely random; serious users of one-time pads usually gather bit data from environmental sources, such as measurements of background radiation detected on a radio telescope. For today's purposes, you could purchase a 100-sided die and give it a roll around the inside of a bowl to produce each number. It should also be acceptable to use a CSPRNG, provided that it is properly seeded from a source of true entropy (provided that the seed value is discarded after use, you probably won't need enough numbers from the PRNG for an attacker to be able to predict them). Make sure the memory is fully cleared from any electronic device used to generate random data.

To encrypt, take the random pad, the numeric alphabet, and the message you wish to encrypt into a place where you can't be seen by anyone else or any surveillance equipment (you know, just in case). Take the first character of the message, look up its alphabet code number, then get the first number from the random pad, and subtract the random number from the character code. If you end up with a number less than zero, subtract that number from 100. Look the resulting number up on the alphabet chart, and write down the character as the first character of the ciphertext. Repeat with the second character of the plaintext and the second number of the random pad. Continue through the message until you have encoded every character of the plaintext message. You must have used every number of the random pad, in order, once and only once.

When you're done, you burn or otherwise completely destroy your copy of the plaintext, and physically secure the random pad and alphabet. This is important; nobody should be able to get their hands on the random pad for 100 years, but they must be able to get to it in 100 years. The alphabet is not technically a secret, but it's inclusion with the ciphertext is a clue as to the use of a one-time pad (leading people to go searching for the pad), so I'd recommend keeping it with the pad. The ciphertext itself is perfectly secure in its encrypted form; you can chisel it into the stonework of the Supreme Court building if you wanted (and could do it fast enough to finish before the DC Metro Police took you away). It could be any of a number of alphabet ciphers, lending a little entropy to mask the discovery that it's a OTP in the first place.

To decrypt, someone must have the ciphertext, the same one-time pad and the same alphabet table that you used to encrypt. They take the ciphertext's first character, look up the number in the alphabet table, then add the number from the one-time-pad and modulo by 100 (simply truncating the hundreds place wherever it shows up). They turn the resulting number back into a character using the alphabet, and write it down. They then continue, character by character and number by number. Again, they must use every number of the random pad, in order, once and only once.

The one-time pad is a very old system, first being described in 1882 and re-invented in 1917, and it has the ultimate advantage; it is provably impossible to crack. Being genuinely random, there is no mathematical pattern to any of the numbers of the random pad (which forms the "key" of the cipher), and because each number is only ever used once (if you have more than 100 characters you will see the same two-digit number in the pad twice, but you can never predict when), the pad itself is never repeated. Thus, any attempt to decipher the message without the exact same pad is futile; it could produce gibberish, or it could produce a message of exactly the same number of characters, but whose content is something completely different. The only way to be sure that every character of the message is decrypted correctly is to have the exact same sequence of random numbers that encrypted the thing in the first place.

The disadvantages that keep it being used more universally are that it ideally requires a pad of infinite length (to handle any number of messages of any length), and there's a large possibility of offset error; someone can miss some or all of a message sent by the other person, so one person has crossed off fewer numbers on their pad, resulting in all further messages between the two parties being indecipherable and no real way to recover without exchanging a new pad. In your case, these are moot, but pretty much every other cipher system invented in the last 100 years has attempted to mitigate these disadvantages (primarily the infinite-length key) while trading as little as possible of the ideal security of the system.


Could my boyfriend be hiding his encrypted emails inside of my inbox? is it possible that my boyfriend could be hiding his encrypted emails inside of my email inbox with my email address and I can't read them? And if it if that is possible is there way that I can decrypt and read them?

Hiding emails in your inbox would not be a smart move. Email accounts are free, so there's no need to use another account to store them.

Any email that is stored on your account should be visible to you. Even if those emails are stashed on another folder (not on inbox, for example). You can access all folders and see if there's something suspicious. If you find something suspicious and encrypted, you probably won't be able to decrypt without the key.

If you suspect anyone is using your email account, change the password immediately. This is an easy way to lock anyone out.

But I don't think your boyfriend would be using your account to hide emails from you. Does not make sense.


A Different Approach to PKI After yet another failure of the public key infrastructure, I was thinking about how broken the whole thing is. This business of undeniably associating an identity with a public key, and all the work we put into achieving it, is starting to feel like ice-skating up hill. Forgive me, I'm mostly just thinking aloud here.

I started thinking about the ToR Hidden Service Protocol and their method for solving this. The 'hidden service name' (which is typed into the address bar like any other URL) is actually derived from the public key - so you end up visiting sites like kpvz7ki2v5agwt35.onion - but you have no need for certificates or PKI, the public key and the domain alone are enough information to prove that they belong together (until you are able to generate collisions, but that's another story). Now clearly there is a problem with this - the whole point of the DNS is to provide a human-readable mapping to IP addresses.

Which leads me to my final, possibly flawed, suggestion; why do we not use an IP address that is generated from a public key? (The other way around sounds more convenient at first, but can't work for obvious cryptographic reasons).

We have a HUGE address space with IPv6. A 1024 bit RSA keypair is believed to have around 80 bits of entropy at the most. So why not split off a an 80-bit segment, and map public RSA keys to IP addresses in this segment?

Some downsides off the top of my head;

So an attacker can generate a key pair, and know immediately which server that key pair would be used on, if such a server existed. Perhaps the 80 bit space could be expanded to use 4096 bit RSA keys, believed to have around 256 bits maximum entropy, making such a search infeasible (we would unfortunately require IPv7+ with a 512 or so bit address for this to fit however). This attack is also not as bad as it might at first sound, as it is untargeted. This attack could be mitigated by including a salt into the key->IP process, which the server sends to clients when they connect. This salt makes each server's key->IP process unique.
An attacker could potentially brute-force the key space using a known salt until they match a chosen IP. This is a targeted attack, so is a bit more scary. However, using a slow (1-3 seconds ) algorithm to make the mapping from public key to IP could mitigate this. Use of the salt also means that such a brute-force would only apply to a single IP, and would have to be repeated per target IP.

In order to try to stop the mods closing this, I'll do my best to turn it into a question; Is this idea completely flawed in some way? Has it been attempted in the past? Am I just rambling?

Mapping the public key to an IP address is easy (just hash it and keep the first 80 bits) and you have listed the ways to make this somehow robust (i.e. make the transform slow). It has the drawback that it does not solve the problem at all: it just moves it around.

The problem is about binding the cryptographically protected access (namely, the server public key) to the notion of identity that the human user understands. Human users grasp domain names. You will not make them validate hash-generated IPv6 addresses...

Of course there is a deployed system which maps names to technical data such as IP addresses; this is the DNS. You could extend it to map domain names to public key verification tokens (i.e. put the hash of the public key somewhere in the DNS), or even public key themselves. If you use the DNS to transfer security-sensitive name-key bindings, then the DNS becomes a valuable target, so you would have to add security to the DNS itself. At that point, you have DNSSEC, which is a current proposal for a replacement of the X.509 PKI for HTTPS Web site. Whether DNSSEC would fare better than existing CA is unclear; that's switching actors, but the conceptual certification business would still lurk here.

Humans want human-readable names, and public keys are unreadable. All the certificate-based solutions (be they X.509 or DNSSEC or whatever) try to bind a public key to an arbitrarily chosen name. Another distinct method would be to make the public key readable. Strangely enough, there are cryptographic protocols for that: ID-based cryptography. They use some rather tortuous mathematical tools (pairings on elliptic curves). They do not change the core concept (really, at some point, someone must make the link between a societal identity, like "Google", and the world of computers) but they change the dynamics. In an ID-based system for SSL, each server would have very short-lived private keys, and a central authority would issue to each server a new private key every day, matching its name. The net effect would be like an X.509 PKI where revocation inherently works well, so damage containment would be effective.

Yet another twist would be to replace the notion of identity. Since humans cannot read public keys, then, accept it: they will not read them. Instead, track down active attacks with specialized entities, who do know how to read keys. That's the whole point of the "notaries" in Convergence. The notaries keep track of what public key is used by which site, and they scream and kick whenever they see something fishy.

Anyway, the current system is not broken -- not in an economically relevant way. The breach you are linking to will join the Comodo and DigiNotar mishaps; that's a short list. Such problems occur way to rarely to even show up on the financial radar: if you add up the cost of all frauds which used a fake server certificate obtained from a "trusted CA", you will get an amount which is ludicrously small with regards to the billions of dollars from more mundane credit card frauds. From the point of view of banks and merchants and people who do commerce on the Internet, the X.509 PKI works. There is no incentive for them to promote a replacement. If there was a fake Google certificate every day, used to actually steal money from people, then the situation would be different. Right now, we are around one event per year.


What does Same-origin policy apply to? Until now I though same-origin policy applied to AJAX requests using either fetch or xmlHttpRequest, but I just learned that media objects also use this policy.

Are there other things that use the same-origin policy?
Might it be better to think of it as "Anything but script tags use same-origin policy"?

Are there other things that use the same-origin policy?

All cross-origin access is subject to the same-origin policy. But there isn't one single rule that is equally applied to all methods of interaction.
You might find the distinction betwen cross-origin writes, reads and embedding useful.

Cross-origin network access
The same-origin policy controls interactions between two different origins, such as when you use XMLHttpRequest or an <img> element. These interactions are typically placed in three categories:

Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests require preflight.
Cross-origin embedding is typically allowed. Examples are listed below.
Cross-origin reads are typically not allowed, but read access is often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

Here are some examples of resources which may be embedded cross-origin:

JavaScript with <script src="..."></script>. Error messages for syntax errors are only available for same-origin scripts.
CSS with <link rel="stylesheet" href="...">. Due to the relaxed syntax rules of CSS, cross-origin CSS requires a correct Content-Type header. [...]

(Source)
Cross-origin embedding is the most awkward interaction to control. You want to keep the origins separate but you also want to give the users a seamless browsing experience. That's why embedded cross-origin images inevitably  leak their dimensions and cross-origin frames are potentially  vulnerable to clickjacking.

Might it be better to think of it as "Anything but script tags use same-origin policy"?

As you can see, the same-origin policy also applies to scripts. A document can embed a cross-origin script and work with its global functions and variables but it cannot read the entire source code of the script or catch its errors. The ability to embed cross-origin scripts and stylesheets has given birth to vulnerabilities like cross-site script inclusion (XSSI).