Reducing crypto-random values to a useless entropy Supposing I have generated random data from CryptGenRandom (or similar PRNG), at what point does futzing with the values make it not-so-random that it's useless? Or is sufficiently random in enough to make it sufficiently random out?

Basically I'm looking at a key generation algorithm that generates an 8 digit 0-9 value from the output of CryptGenRandom. I realize the final output is limited anyway, but it's a protocol implementation to be 8 digits of 0-9.

Put another way, if I need to generate such values, what's the best approach?

EDIT: My first question was more in the general sense and the second was a clarification on what I actually need to accomplish. Suppose I have generated a 256 bit random value. I need to reduce the 256 bits to say 64 bits, but further constrain that to a numeric value (in this case 8 digits).

Removing half the bits has an effect on the usefulness of being cryptographically random (as it reduces the entropy? or is this a false assumption?). Reducing that further to just be numeric values surely has an effect on usefulness as well. Given that then,

Q1: In a general sense if I had to reduce the length of a random value, what methods should I avoid?

Q2: OR more specifically, am I being dumb about generating an 8 digit number?

There are exactly 108 = 100000000 possible sequences of eight digits. The best you can hope for is to select one of these with uniform probability.

The generic way would look like this (in pseudo C code):

for (;;) {
    unsigned char buf[4];
    uint32_t val;

    GetRandomBytesFromPRNG(buf, sizeof buf);
    val = (uint32_t)buf[0] | ((uint32_t)buf[1] << 8)
        | ((uint32_t)buf[2] << 16) | ((uint32_t)buf[3] << 24);
    val &= 0x07FFFFFF;
    if (val < 100000000) {
        return val; /* that's your code in the 8-digit range */
    }
}

Basically, we generate random values uniformly in the 0..227-1 range:

Produce four bytes.
Decode these into a 32-bit integer (here with big-endian convention, but that's arbitrary).
Truncate to a 27-bit integer.

Why 227 ? Because that's the smallest power of two which is greater than 100000000 (227 is equal to 134217728).

At that point, we have a value in the 0..134217727 range, with uniform probability. If it falls into my target range (0..99999999), then that's good, we have our value. Convert that into decimal to get your 8 digits. If the value does not fall in the range, then we try again. Probability of looping is 25.49% each time, so it converges quickly (less than one chance in a billion to loop more than 15 times).

This is the way things are done with Java's Random.nextInt(int). A counting argument can be used to show that it is not feasible to really reach a uniform selection without some kind of loop (namely, no power of 2 is a multiple of 108).

Alternate method: generate a big 160-bit integer, then divide it by 108; the remainder will be your 8-digit code. This method has a slight bias, but less than 2-128, so it is negligible. This method also guarantees a fixed amount of random bytes from your PRNG. However, computations on integers which do not fit in a machine register can be expensive, so this method will usually be less efficient than the loop above.

Remember that what you get as a "key" is hardly worth that name: enumerating all possible 8-digit sequences can be done in a fraction of a second. It will be hard to make some decent cryptography out of that. Such a code will nonetheless be quite good if used as, say, a one-time registration password.


What does Spectre mean for public cloud computing? From a tweetstorm by security journalist Nicole Perlroth:

  The most visceral attack scenario is an attacker who rents 5 minutes of time from an Amazon/Google/Microsoft cloud server and steals data from other customers renting space on that same Amazon/Google/Microsoft cloud server, then marches onto another cloud server to repeat the attack, stealing untold volumes of data (SSL keys, passwords, logins, files etc) in the process.

While Meltdown can be patched, my understanding is that there is no short term solution to Spectre. That seems to make this problem very, very bad. Wouldn't that spell the death of the whole bussiness? On the other hand, my natural instinct in these situations is usually to try to dismiss it as hype.

So:

If I have a sensitive service running in a public cloud such as AWS, should I panic and take it offline right away to stop my SSL keys from being stolen?
Is there anything cloud providers can do in the short to medium term to make their services reasonably safe?
Is there (or can there be) virtualization software that is not vulnerable to Spectre even though the host system is?

Spectre is far harder to use than Meltdown.  In a cloud hosting situation, an attacker needs to know:

What software the target is using
Where in memory that software is
Where in memory the target data is
The behavior of the host CPU's branch predictor
The behavior of the host CPU's speculative execution system
and possibly some other things I'm forgetting

It's also much slower than Meltdown.  (Meltdown can read protected memory at a rate of around 500 kbyte/sec under good conditions.  The Spectre paper didn't give a speed, but the need to train the branch predictor for essentially each byte read means I'd expect a rate of single-digit bytes per second.)

Because of the difficulty in using it, Spectre can't usually be mass-deployed.  I expect three-letter agencies will be making heavy use of it, but it's the sort of thing you'd use in a highly-targeted attack, where Meltdown is better suited for untargeted sweeps for interesting data.

In the short term, probably the best thing that hosting providers can do is make it easy for users to run their own software.  A Spectre attack tuned for Apache 2.2.34 for Debian Wheezy on x86-64 is totally useless against Nginx, or against Apache 2.2.33, or against Apache 2.2.34 built with different compiler flags, or...

A fully virtualized system that emulates all aspects of the CPU should be immune to Spectre, but full virtualization is slow.  Hardware-assisted virtualization may be vulnerable if branch-predictor training is shared between the VM and the host, while paravirtualization, sandboxing, and containers are completely vulnerable.


Is SQL Injection possible in this PHP registration script? I've recently created a PHP registration script for a website that a friend and I are working on. I've read up on the dangers of MySQL injection, and I was wondering if my current code is protected from such attacks, or if additional steps need to be taken.

The relevant part of the code is as follows

  $email = $_POST['email'];
  $username = $_POST['username'];

  $username = strip_tags(trim($username));
  $email = strip_tags(trim($email));

  //Sanitation code I found somewhere..
  function mres($var){
    $conn = get_my_db();

    if (get_magic_quotes_gpc()){
        $var = stripslashes(trim($var));
    }
    return $conn->real_escape_string(trim($var));
  }

  //Sanitize username
  $sanUsername = mres($username);

  //Make SQL query
  $sql = "SELECT username FROM accounts WHERE username = '$sanUsername' ";
  $result = $conn->query($sql);

Thanks in advance,

Shawn

EDIT:

I've updated the SQL query to the following to make use of Prepared Statements

  //Prepare statement
  $prep = $conn->prepare("SELECT username FROM accounts WHERE username = ?");
  $prep->bind_param("s", $sanUsername);
  $prep->execute();
  $result = $prep->get_result();

You're using the wrong approach to prevent SQL injection. Sanitizing inputs can help provide security, but by far the best way to avoid SQL injection is to remove the thing that allowed it in the first place: mixing code and (user-supplied) data in the same string, such that the database doesn't know what was supposed to be code and what was supposed to be data.

There is no need to do this in SQL anymore, and you want to look into prepared statements. The way those work is that you first send the database everything but the actual data; the database compiles the query, and only then do you supply the actual data of the query. What this means is that the user-supplied data is placed by the server into specific slots in the query, and cannot change what the server is doing.

To be more explicit, you send the server something like SELECT username FROM accounts WHERE username = ?. The server processes this query (the titular prepared), turning it into a function that's just waiting for a value for the username. You then bind the specific username to the statement, and execute it. The key is that the server already knows exactly what it should do before it ever sees user data; nothing a malicious user sends can change what the database is going to do (i.e. find rows with the given username and return their username).

Sanitization of database inputs is fundamentally an attempt to mitigate an attack vector by blocking inputs that exploit it. Prepared statements actually remove this attack vector, because they eliminate the conditions that allowed it to exist.

Details of how to use prepared statements vary by language, framework, and database server; look up PHP/MySQL documentation for the actual details.


Simultanous VPN on router I have questions regarding the following setup:

Router is configured to tunnel every connection through a VPN server in country A
Additionally, using the software of the same VPN provider on the operating system of an end device, a VPN tunnel is established to a server in country B

So I guess its: Bob -> VPN through Router in country A -> VPN through Client in country B -> Alice

Is this correct? Is this setup the same like a MultiHop configuration?

What exactly happens if VPN in country B is corrupted? For example, traffic from and to VPN server in country B is monitored?

Thanks!

Unless the VPN provider guarantees it, and possibly not even then, you shouldn't assume that the data just moves from Bob's VPN to Alice's VPN without passing over the wire unencrypted within the VPN provider's facility.  It may even pass over the open internet if the VPN provider has multiple, distributed endpoints.

If Alice and Bob want a guaranteed, encrypted connection they should use a VPN directly between them leaving the provider out of it.  The downside of this is if they set things up directly there won't be a nice prepackaged installer from the VPN provider so the scope for making mistakes is increased.

If the networks in country B are being monitored the people monitoring will be able to see that Alice is using a VPN, roughly how much data she is sending an receiving.  They may be able to infer more through traffic analysis.  They won't be able to see what is being sent and received though.  If it is the government doing the monitoring Alice may get a knock on her door.


How secure is online banking with smart card? How could it be hacked? I have read this question and answer but still uncertain how it actually works and how a user could then be hacked. I'm asking because my brother supposedly was hacked and his bank uses exactly this kind of security.

So my question how could this be done without a huge effort/expense from the hacker? Only way i see is a MITM attack. Spoof DNS, pretend to be banking site and then use the sent login data. But then the attack can still only happen exactly at the same time when you are logged in. In this case he certainly wasn't (family event I was there, so was he...). What are other possible scenarios to achieve this?

MITM is going to be unlikely - the bank should have a SSL connection with a signed cert from a CA, which would alert you with a big red screen and scare you away. It is also possible that you were re-directed to a non-secured version of the site (and a fake/look-a-like site exists), and proceeded to enter your info there, but this should quickly raise red flags with the bank (and while it may not being up the red screen, there should still be some signs, like the missing padlock, to alert you).

What is more likely is some sort of virus on your end that can either install it's own bogus CA and then proceed as above, or hijack the session by stealing the authentication cookies or similar.

It's also possible that the bank itself had another vulnerability elsewhere - this would probably affect multiple accounts, but you may be oblivious to the fact that others had similar issues (but hopefully the bank becomes aware).

You also assume that a MITM attack could only happen when he was logged on - but this may be a false assumption - would a MITM attacker pass on the "logoff" request? I don't see why they would - what if they extended the banking session each time (going to a new page/etc.) instead of allowing it to time out? - unless the bank at some point asks for the password/code again (unlikely from a UI perspective), then chances are you could be unaware that you are still "logged in" (although the bank should have logs as far as when you logged in/out and can check for this kind of stuff).


Does My Neighbor Sniff My Mobile Data Through Wifi i am using an Android phone which is connected to my home Wifi Device(Tp Link) DSL Connection.
Can my neighbour hack my mobile and monitor my mobile traffic through software like WireShark, etc.?

Perhaps we can generalize things a little. Any wifi connection can potentially be breached and the attacker could use the "evil twin" attack so that you send all your wifi traffic to them, and they can use WireShark to collect your packets. This is true of any wifi connection and any wifi device.

There are ways to reduce the risk and to protect yourself, and those protections depend on the wifi equipment involved and your technical skill.

On the other hand, one cannot "hack your wifi" and gain access to the data sent over the cellular network, if that was what you were asking.


Is it possible to prove a certain email has been sent using a certain computer? I can understand that an SMS can be traced to the mobile phone which it has originated from and the phone owner has no chance in court but to claim that someone else has used his phone but what about an email from a PC?

Most emails are being sent using a browser and a web interface let alone the fact that you hardly find a PC outside a NAT. Add to that most laptops are connected via WiFi.

It seems very easy to claim that I have not sent email X and email address Y is not mine. IP address? it means nothing, I am sharing it with lots of people, it might be my wife who sent that email from her laptop or it might be my neighbors who hacked my WiFi.

How can an expert defeat such claims in court in front of a judge?

Experts are experts. What an expert says stands in court as long as:

He is an expert.
The other party cannot provide another expert, who says that the first expert is wrong, and says it in a more convincingly expertish way.

In practice, a email will be reputed to have been sent from a given PC if the context makes it a lot more plausible than any alternative explanation. Context elements include IP addresses registered from the SMTP server side, ease (or lack thereof) to assume that IP address on the client side (WiFi or not WiFi, accessible wires...), presence or absence of log files on the PC... and, more often than not, whether the purported sender admits to the deed or not.

Take note that perjury is a serious offence, so people tend not to deny sending emails when what is at stake (e.g. a commercial dispute) is "less serious" than the consequences of being caught in the act of lying to the judge. The crucial point is that proving whether an email was really sent by some specific individual is a complex matter in both ways: it is hard to convincingly pinpoint on the perpetrator, but it is equally hard to make sure that it will never be decisively proven.

This reproduces the security model of handwritten signatures. It is, in fact, not very difficult to imitate the signature of somebody else; it is also quite hard to actually verify that a signature is proper or not. But handwritten signatures happen in the physical world, with pens and human hands, so they tend to leave traces -- what I call contextual elements. You can repudiate your own signature, but it is risky, because you cannot be sure that nobody saw you, or you did not leave a fingerprint on the pen, or any other of a million possible incriminating details. And trying to repudiate your own signature is severely punished. Therefore, it is often preferable to recognize the signature as your own and assume the consequences.

In the case of emails, the same mechanism is at work. Though actual proofs are often flimsy elements (log entries and so on), denying having sent an email that you did send is risky, and felt as risky, especially since it involves computers (computers are beyond the "magical horizon" of most people). So most cases involving emails end up with producing a few log file entries (that could, indeed, be faked in a great many ways), and the sender crumbling under the steady gaze of the judge.


LSB replacement and its effect on grayscale histogram I used this program to embed some text data in grayscale image, then I compared original and stego histograms in Matlab using imhist function. You can see both on them below:

Can somebody explain to me what exactly is going on in the stego histogram? Why are there 2 shades of blue? Is this how I should be comparing such images or is there a better way?

In LSB-Steganography you store your bitstream in the least significant bit, thus in the first bit of every pixel. doing so you change rgb-values that should ideally not be recognized by human eyes. The more data you put in it the easier it is to be recognized like your histograms shows.


Are there any real instances of threats to machine learning systems? I recently read a paper on The security of Machine Learning.
 Are there any instances of attacks against machine learning systems besides spam filters?

Yes, there are recent examples of attackers targetting ML systems in order to later evade detection. The term used for the study of this effect is "Adversarial Machine Learning". There are a number of papers:

Berkeley, 2010
Berkeley, 2011
IEEE, 2011

One of the techniques discussed is the "boiling frog" technique. Named after the effect that one can boil a live frog without it jumping away to safety if the heat is turned up slowly. Attacks using this method attempt to mistrain the ML system by introducing anomalous stimuli at a very low anomaly factor, but with high frequency. Over time, the anomaly factor increases until the ML system learns to ignore truly anomalous stimuli, at which point the actual attack on the target systems begin. Because the ML systems have been trained to ignore it, the attack goes undetected. (The same technique has been used for years against people and security guards).

This can be done with spam filters, IDS, UBA systems and Netflow analyzers.

For instance: if you have gained the credentials of a valuable user, and you want to be able to log in as that user during a time when that user does not normally log in, you can start logging in using those credentials at times only slightly different from the user's normal pattern while not performing any unusual activity. Once you have seeded the logs with enough logins around the time when you want to perform your malicious activity, you can make your attempt and know that you will not trigger alarms for the anomalous login time. By seeding the logs with non-malicious activity, secondary and tertiary analysis of the activity will support the decision that the activity is not anomalous.


International pentester certification I've looked at the questions regarding certifications on this site and they are essentially asking what to go for.

I hope that my question is distinct enough that is is not considered a dupe.

I travel a lot and frequently, so am looking for a certification that is accepted in many countries. The CISSP would serve this but is too basic. CREST looks interesting but it is UK only.

GPEN cert from GIAC seems nice, but the associated training is rather expensive and I don't want to be paying that much to learn what I may already know.

I am ware of online courses such as those offered by Offensive Security, just in case they have the same stigma associated with them that are associated with online degrees. I was considering paying for the Offensive Security course and taking the GPEN exam, however the OS course seems rather Backtrack specific.

I would really like some recommendations for an internationally recognized pen tester cert that is not at a beginner level.

CREST is now being offered in the US, and Germany is looking to implement it soon. Other countries are coming on board in the near future.


Creating user specific authentication methods in SSH I have configured sshd on an Ubuntu server to use key authentication and it is working fine.
I had to disable password authentication for key authentication to work.
Server is always accessed via remote terminals or putty.

Now all user accounts are able to login with the authentication key and passphrase. But now I want to create only one new user without key authentication. So how should I go about doing this in such a way that does not hamper other users who are using key authentication.

You can use Match in sshd_config to select individual users to alter the PasswordAuthentication directive for. Enter these Match rules at the bottom of sshd_config file ( generally /etc/ssh/sshd_config )

Match User root,foo,bar
    PasswordAuthentication no
Match User Rishee
    PasswordAuthentication yes

This would give root, foo and bar key authentication, and Rishee password authentication.

An alternative is to match by negation, like this:

PasswordAuthentication no
Match User *,!root
    PasswordAuthentication yes

In this case, everyone except root gets password authentication.

Note: The *, syntax is necessary, as wildcard and negation syntax is only parsed in comma-separated lists.

You can also match by group:

Match Group usergroup
    PasswordAuthentication no

Reason for entering Match at the bottom of the file:

  If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another >Match line or the end of the file


Are any and all software vendors who have stored credit card information in their databases subject to PCI-DSS or only some? Is a commercial software vendor who sells software for use in the United States, subject to, or legally required to implement PCI-DSS if their software includes a feature which will allow the collection and storage of credit card information, but which does not do payment processing itself as part of the software's features?

Said software vendor would NOT be processing payment using this software but simply encrypting and storing the credit card information for the purposes of simplification of manual payment processing using  software from another vendor. That is, this hypothetical software vendor is simply producing software which can communicate to other payment systems, but which is not a software based payment system itself. (For instance, perhaps communicates to Digital River or other online payment processing systems, and stores credit card information in a database, in encrypted form.)

First off - PCI-DSS applies to environments, not products.
In other words, it would apply to your website, but not the packaged product you sell to your customers.
On the other hand, it could apply to your customers, who would then need your product to fit in with their compliance.

To this end, the PCI fellows introduced PA-DSS - this applies to products, which can be installed in customer environments (which would then be required to comply with PCI).

Now, regarding your specific product - PA-DSS would absolutely apply, since you store or process card data (even without processing payment).

From the PA FAQ:

  For the purposes of PA-DSS, a payment application eligible
  for review and listing by the PCI SSC is defined as an
  application that:
  a)  stores, processes, or transmits cardholder data as part of
  authorization or settlement;
  and
  b) is sold, distributed, or licensed to third parties


Mobile Hotspot, Smartphone or Router? I am using a laptop with dual boot Windows and Ubuntu. In addition, I am having another Linux distro installed on a usb thumb drive and using it only for certain things.

Generally speaking - if android devices are vulnerable in terms of privacy and security, does that mean that my linux will be vulnerable too if I use the Hotspot from android devices?

Are Mifi devices, all these jetpacks, any better than a smartphone for security and privacy?

Getting a mifi, a good plan simcard and using a Linux distro on a USB should be better than, using my linux installed on the laptop alongside with windows, and using my android phone as a hotspot?

I have access to unlimited data from a broadband provider, but don't have access to their hub3 device and can't configure any settings and I think its very unsecured as it is now. So that's why I am using mobile data for my laptop, thinking its more secure.

Would getting a mifi, mobile simcard and using a Linux distro on a USB thumb drive be a good idea?

EDIT:

HTC One M7 (Sense Version) with Android version 5.0.2
Unlimited mobile data from GiffGaff, O2 Network
Never used google services in my life, have disabled all google apps.

Opera Version 54.3.2672.50220, blocked cookies and allowed only certain sites storing and accessing cookies.

Linux 18.4 LTS 4.15.0-96-generic
UFW status verbose:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

Using three different browsers for different activities:

Opera - Version:67.0.3575.137 (All site settings are blocked, except few sites with allowed JavaScript and cookies clearing at exit)

Brave - Version 1.5.123 Chromium: 80.0.3987.163 (Official Build) (64-bit) (all sites restricted)

Firefox - 75.0 (64-bit) with tracking protection set on Strict

ProtonVPN installed on phone and laptop with secure connection services - still trying to understand should I use vpn on the phone or on the laptop, while using the mobile data on the laptop.

There are just too many unknowns to provide a clear answer to this question. The answer also depends a lot on your threat model - who exactly are you trying to protect yourself against? Family members and roommates? Strangers at Starbucks? Your Internet provider? Google? Government agencies? The important considerations will change heavily depending on what you consider to be your primary threat.

  Generally speaking - If android devices are vulnerable in terms of
  privacy and security

It sounds like this is just an assumption you're making but I think it also requires more elaboration. Is there a specific Android device you are referring to? An old and unpatched Android device from an unreputable manufacturer will likely have as many security holes as swiss cheese, indeed. But a fully up-to-date device that is actively supported by a reputable company (e.g. Google's Pixel line) is arguably more secure than the majority of other devices you'd use on a regular basis - including Windows and Linux computers. Android devices do have significant privacy drawbacks in terms of the amount of data they share with Google, but it is unclear whether Google is part of your threat model or not.

  Does Mifi devices, all these jetpacks any better than a smartphone for
  security and privacy?

Keep in mind that Mifi devices run software too - very likely based on some form of Linux. That software may be old, unpatched, or poorly written just like any other software. So whether a Mifi device would be more secure again comes back to the specific device you are using and your threat model.


Encrypt+Signing data: PKCS#7 / CMS or do-it-your-own way? Currently I'm saving an array of AES keys into a keychain as JSON, saved as a text file / SQL text column:

{
    [
       {
          encryptedAesKey:RsaEncryptedBytesBase64Encoded==,
          signature:RsaSignatureBytesBase64==,
          keyId:0,
       },
       {
          encryptedAesKey:RsaEncryptedBytesBase64Encoded==,
          signature:RsaSignatureBytesBase64==,
          keyId:1,
       }
    ]
    signature:HashAboveKeychainThenRsaSignatureBytesBase64==
}

Only the holder of the private key (say Alice) can decrypt the AES keys. Alice also has her own public key, so she can verify the signature before usage. This protects her against Chuck who might disrupt AES decryption of already encrypted data by creating a random AES key, encrypting it with Alice's public key and writing to where the JSON is saved. But chuck can't sign so Alice won't accidentally use bad data.

The above has been working for many many months but CMS/PKCS#7 seems attractive since it already designed for data security and integrity by defining data envelopes (encrypt) and data signatures (signing).

Question: Apart from interoperability what additional benefits would one have by going the CMS/PKCS#7 route?

Don't roll your own crypto. If you decide to invent your own format, then you are on your own. The history of cryptography is full of people who invented their own format, and failed horribly; and, more to the point, the history of cryptography is not full or people who invented their own format, and got away with it. These things are hard to do correctly, and you cannot test whether you succeeded or not (you can test for functionality, not for security).

CMS (the new name for PKCS#7) has the double benefits of:

having been standardized and deployed in the field for a long time, so its potential pitfalls should have been well understood by now;
being already implemented in a number of framework and libraries. As usual, the software which is easiest to implement correctly is the software which is already implemented correctly.

So, do yourself a favour, use CMS.


Certificate Chain - intermediate and root certificate - installed required? Recently I bought a SSL cert from comodo for my domain - orakoha.com

After submitting the CSR etc, domain control verification etc, I am issued with a zip file containing 4 document which I believe are my issued certificate, intermediate ca certificates and the root certificate.

www_orakoha_com.crt
COMODORSADomainValidationSecureServerCA.crt
COMODORSAAddTrustCA.crt
AddTrustExternalCARoot.crt  (root certificate)

My question are as below

When a browser visit my site (e.g. www.orakoha.com), download my
cert and see that it does not have the issuing ca (intermediate ca's
public key), will it automatically download those intermediate cert
(e.g. COMODORSAAddTrustCA.crt) from my webserver ? or it will
prompt the end-user (using the browser) whether he/she wanted to
install those certs?
If a browser does not have the root certificate of the root ca
issuing the intermediate certs/my cert, what will happen? will my
webserver send the root cert over and the browser will prompt whether
to install the root cert or not?
How do I see what are the root certs that are already installed in
the browser?

In short: the intermediate certificates have to be sent within the TLS handshake (needs proper configuration of the server) and only the CA local at the client will be considered as trust anchors.

In detail:

  ... see that it does not have the issuing ca (intermediate ca's public key), will it automatically download those intermediate cert (e.g. COMODORSAAddTrustCA.crt) from my webserver ?

No browser will download the certificate from your site. If intermediate certificates are missing in the TLS handshake some browsers might try to download the certificate from other sites but you should not rely on it. Google Chrome on desktop seems to do it, other browsers not.

  or it will prompt the end-user (using the browser) whether he/she wanted to install those certs?

No, there will be no prompting. Just an error that the certificate cannot be validated.

  ... will my webserver send the root cert over and the browser will prompt whether to install the root cert or not?

No. It would be stupid if a browser would trust any random root certificate send by a server, because then man in the middle attacks would be simple. Even prompting will not help much because most users will just click through any dialog they don't understand. Browsers will only trust the CA shipped with the browser or provided by the OS and explicitly  installed CA. Installing a new root is more complex and usually involves that the user explicitly downloads, installs and trusts the CA certificate.

  How do I see what are the root certs that are already installed in the browser?

There are lots of information about this on the internet. Just follow the links from the search for "view root certificates browser". Note that the actual ways depend on the browser and OS.


DNS Rebinding attack - does this attack require victim to use an attacker's DNS server for resolution? How will that happen? Usually a preferred DNS server will be set in router's configuration and it will be either the organization's server or some trusted public server. So how would attacker get the victim to use his DNS server to resolve its domain name?

The victim does not need to use the attackers name server, although this can make things easier. The main idea is, that the original DNS record is under the attackers control and thus also the TTL (time to live) of this record:

Victim tries to access web site. To get the address it asks the companies DNS server. Because the record is not cached yet the DNS server recursively resolves the name and returns the record (from the attackers DNS server) to the victim.
If the victim needs to look up the IP address again (which can often be triggered by connection failures on the first IP) it will again ask the companies DNS server. If the record is cached the TTL gets checked. If the record is still valid it will be returned to the victim (with the old address). If it is not valid the companies DNS server will again recursively resolve the name and at the end get the new record from the attackers DNS server.

Another option would be for the attacker to return an answer which contains already both IP addresses (the good and the bad one). The victim will first use the good address. Once this stops working (which can be triggered by the attacker) the victim will retry with the alternative (bad) IP address.


Are there open by default ports with Centos 7's firewalld? My Centos7 firewalld has TCP ports 8083, 8086, and 5000 open.  I don't recall opening them, except for maybe 5000 when first learning about firewalld.

Are there any ports that might come out of the box open?  If not, can you think of anything in common with these mystery ports?

My CentOS 7 apparently came with ports 10010-10020/tcp, and services ssh and dhcpv6 open on the public zone, the default active zone.

You should specify which zone you are asking about, as there are 9 predefined zones, as of v.0.6

8083 and 8086 are both used by ITunes, according to this source.

One of the first tasks when setting up a server connected to the internet is to configure the firewall. In my case, for example, it was a VPS that should only be accessed from my home network, so I activated and opened the home zone to my local network IPs, and closed the (default) public zone to everything, loosely following this guide.


How can a web API for a mobile app be protected from unauthorised access? I have a read-only web API for use with a mobile app. There are no user logins - just searches performed against an API and a set of results returned.

NOTE: This isn't about USERs logging in as the questions I can find are about, but just one log in for the whole API, just to confirm that it is actually our iOS app accessing it, and not some Android app that somone else made and is just using our API.

I'd like only my app to be able to access the API. Even though the data is public, I don't want anyone to be able to use the API.

I was going to add a basic key check to be sent with each request, as many APIs do, a simple key=sjetow3vthw3iulbtq4wv in the request and verify it, but I understand that keys can't be securely stored in iOS apps, like at all....?

Is this impossible to achieve? Say a website like Booking.com and their iOS app - surely it can't be right that there's no protection on their API, and anyone could develop an app againt their API? Can they be secured at all?

Thanks

Any secret you may have in a mobile app is lost to the user. You can't secure anything that is given to the client. On the other hand, a request to your API is the same from any source. The client can send anything.

Given these assumptions, it is impossible to make your API only work with your client. Anybody can extract any identifier from your client and make another app with the same identifiers or secrets to query your API, and you have no way to tell who (what piece of software) the caller is.

And from here, I think it's probably a legal question, you can create a suitable Terms of Service to prevent that and talk to lawyers what can be done to gain legal protection.

Technically the best that you can do is probably using API keys, so even if you don't want to identify individual users, you could still have them create API keys for themselves to connect to your API. This way, you could at least control and possibly ban API keys that you think are against your ToS, and you could also deny issuing a new API key to offending users. But for this you would also need facilities to actually try and find out who those users are (which API keys, technically), and that will not be exact science.


Is there a secure DNS provider? Is there a secure DNS provider? Kind of alternative to DNSCrypt.

There are several kinds of "secure":

If you want nobody near you sniff at your DNS traffic, then you can use a VPN to a trusted endpoint and then use the DNS server there.
If you want to serve your own DNS records in a safe way you can setup DNSSec, but beware that not all clients understand this (they usually fall back to insecure, but some might just fail).
If you want to be sure that you don't get spoofed DNS replies, you should setup your host to only do DNSSec queries and only accept DNSSec replies. Unfortunately a large part of the internet does not protect their domains with DNSSec yet, so you need to either accept insecure (and possible spoofed) replies or restrict yourself to the "safer" part of the internet.
It helps also to use only SSL (https) so that the host name in the certificate gets compared against the name in the URL and you get failures if somebody spoofed the DNS response. Of course this depends on the more or less broken PKI architecture of the internet (e.g. every CA can sign a certificate, no working revocation...).
Or do you want a DNS server which screens the replies so you get rudimentary malware protection. One example of this service is opendns.


Is a second, "old" (dumb) phone dedicated just to receiving bank tokens as safe as "modern" (smart) phone? Are old phones safer / safe / as safe as modern smartphones when it comes to auth-tokens / confirmations tokens?

Is SMS encrypted?

From an OpSec-perspective, I'd argue that a second, dedicated phone (dumb or smart) is a good idea as long as you treat the dedicated phone as exactly that: dedicated to one exact use case.

You minimize the attack surface because you'll be less prone to web-borne attacks  and you'll slightly elevate your security, albeit through obscurity (of your banking phone number). However, all this comes down to how well you operate your second phone.

To expand on that second phone's OpSec, with input from @schroeder and @ste-fu:

Use a dedicated SIM card/phone number for banking (and do not communicate this number to others except your banks)
Do not use it for browsing
Do not use it for messaging/communication with anyone except your banks
(smart phone) Do not install apps on it
Keep it in a secure spot especially if it's a dumb phone without lock screen protection (PIN/pattern etc.)
(smart phone) Disable lock-screen notifications/hide the content
Disable mobile data and WiFi
Power it off when you're not using it. This is not really a necessity, but it will limit you from compromising your OpSec. Human error is always possible.

In regards to your second question, here's an excellent and in-depth answer on SMS interception/encryption.


How does a dictionary attack use it's "words"? Does it assemble/concatenate the dictionary elements into candidate passwords, or does it just use the dictionary elements/words as passwords (which sounds strange)?

I'm wondering about "SmartKey ZIP Password Recovery Professional".

A classic dictionary attack simply uses each element of the dictionary as a candidate.

Using rules to extend the dictionary is common, and tend to vary from implementation to implementation. A rule set might include adding numbers, concatenating other words from the list, or substituting letters for numbers or symbols. Hashcat has a fairly proficient rule set and the wiki entry for rule based attacks can be somewhat confusing, but the basic idea is that for each word in the dictionary, variants of that word are also tried.

I'm unfamiliar with the program you mentioned, but given the small amount of info available on the web page, I'd hazard a guess that it runs a simple dictionary attack (only the words in the list are checked).


Does using ssl matter if I am connected using a VPN? Say I have an internal server that I am using for source control.  If I only access that server through a VPN connection, do I still need to have SSL setup on the source control server to ensure that no one can eavesdrop on my communication with it?

VPN is a Virtual Private Network: it isolates a group of machines from the rest of the world, so that these machines can talk to each other undisturbed by outsiders. If the isolation is reasonably thorough (it uses encryption, and it uses it properly), then communications between any two machines in the VPN will be protected from eavesdropping and alteration from machines which are not in the VPN.

But the VPN will not do anything against attackers who are already inside the VPN. Your desktop system is in the VPN; so is the server you are talking to. But there may be other machines as well. In fact, it is typical, in enterprise contexts, that all remote employees join the VPN, which will therefore contain many people as well as a bunch of corporate servers, and other systems of questionable security (e.g. printers).

Another point is that the VPN is between machines. In the "mainframe model", a given machine may run process from distinct users, with distinct rights. With SSL, the security is from one specific process on the client machine, to one specific process on the server. Even if the VPN uses authentication, it would be inconvenient for the client to get some accurate information on the identity of the server, and vice versa, because the VPN authentication is not made available to the individual process on the involved machines.

Therefore, in the presence of a VPN, SSL is redundant only if all the following characteristics are met:

the VPN provides confidentiality and integrity as well as SSL would (i.e. with correctly used cryptography);
all machines which may connect to the VPN are trusted;
authentication can be delegated to the VPN layer.

If unsure, use SSL and consider the network as hostile. This is the safe way.


What are the recommended steps involved in creating an encrypted file format? I'm developing a pretty standard program which lets users save their work in a custom file format and reopen it later. Now I'd like to add the capability to encrypt the file using a user-defined password and I wonder what steps to take and what technologies to use.

From what I've read on the subject I think I need some way to derive an encryption key from the password, as well as some sort symmetric encryption algorithm which will be used to encrypt the relevant file content. There needs to be some unencrypted data in the file out of necessity (magic/version number, encryption parameters/salts/IVs) as well as some way to verify that those unencrypted parameters have not been tampered with. Finally, on decrypting the file we need some way to verify that the entered password was indeed correct, without introducing a potential attack vector.

So what steps should I take to achieve this?

Which technologies should I use?

What should be the general design of the file format?

The result should be secure enough by today's standards for a target audience of private users and small companies.

It is entirely up to you. In Java for example, there are libraries (cryptographic functions should not be implemented from scratch) for AES encryption that let you use this cipher to encrypt a byte stream with a given key and IV. So most often, even when using libraries, you are still left with the problems you mentioned:

Where should meta information be stored? (Version, original file name, original path etc.).
Where should the encryption parameters be stored?
Where to store IVs
Where to store the salt

It really depends on the application you are creating. I would consider storing the essential information (IV, salt) inside the encrypted file in a custom header. Embedding essential information inside the file has the advantage, that all you need to decrypt it is the encrypted file itself and the key.

You could put the meta information inside the header too, or if your application demands it, store it in an external database. Since meta information is non-essential, encrypted files can still be decrypted even if the database becomes corrupt or lost.

  There needs to be some unencrypted data in the file out of necessity
  (magic/version number, encryption parameters/salts/IVs) as well as
  some way to verify that those unencrypted parameters have not been
  tampered with.

I'm not sure why exactly you need that, but you could reserve extra space in your custom header for a checksum calculated over IV + encryption parameters. That way you could always tell if the parameters were modified. You could however not restore a corrupt IV for instance, at least not without brute force.

  The result should be secure enough by today's standards for a target
  audience of private users and small companies.

If your encryption algorithm is considered safe and you are handling the user passwords correctly (this is the biggest caveat!!), then there is not much you can do wrong with the file format. IV, salt and encryption parameters can be made public (read: stored in plain text). This should not have an impact on the security of your chosen encryption.


Why use a Smartcard for (Two Factor) Auth instead of another medium? I recently installed Bitlocker on my Windows 8.1 machine, using only a password. I was thinking of getting something other than just a password for my storage drive, something physical, like a USB, SD Card, or Smart Card!

I've asked and poked around, and people claim the following:

  When given the choice of a Smart Card and another storage medium for 2FA, or regular authentication, go for the Smart Card, as it is safer.

I can't really find why it would be safer, an encrypted SD Card switched to "read only" with the side switch would just be as safe as the Smart card, correct? (That is to say, a USB drive can be overwritten by Malware, etc.).

Is this advice accurate? Why or why not? Is a Smart Card indeed safer?

A smart card works by keeping a secret hidden and answering a challenge that proves it has the secret.  It, theoretically, should never reveal that secret to anyone and it should be unrecoverable.  There are some technical ways you might be able to get around it, but most of them are destructive to the card.  This means you know if your smartcard has been compromised.

An encrypted USB drive or memory card on the other hand can simply be copied.  There is no mechanism protecting it from being cloned by an attacker.  There are some USB sticks that do provide hardware protection to prevent unauthorized access and these would make a more viable option, but it would be a toss up as to whether even those were as well protected as a good smartcard.


Need To Use Live CD With Mac without Shutting Down Computer (VMWare/Parallels Secure?) I've heard of using Live CDs such as Tails to protect yourself online. Is there a similar setup to this that would work except run a Mac OS? I've done some searching, but have yet to find anything.

EDIT: I said setup, not product.

You can use Tails with Mac OS by using a virtual machine! Think about it this way: in a situation where you want to preserve your privacy, you want to set up your operating system so that it can be wiped/thrown away quickly. That's why so many folks like to do their private operations off live USBs or virtual machines.

Here are a few ideas:

Use a live USB to boot into tails at start up.
Keep an encrypted VMWare image of tails to use while browsing, with proper preparations to delete it if and when necessary. Always keep it fully encrypted when not in use.
Always use full disk encryption on your mac. Turn it off and keep it encrypted when you can.


Could IOT Botnets be Stopped by Static IP addressing the Devices? I followed the recent IOT DDOS against Dyn and noticed that the attack seemed have three rounds of attack and mitigation. Since I'm not well versed in infosec I did some reasearch around DDOS mitigation techniques. From what I could tell it seems mitigation is essential heuristic traffic analysis to filter out humans from bots then IP banning.  Separately, I also noticed that in almost all the media had the same conclusion that IOT devices are insecure and can't/won't be patched for years. If these two assumptions are true, DDOS mitigation in its rawest since is IP filtering, and we are stuck with millions of infected IOT devices (and adding millions more devices that will one day likely be infected), wouldn't it make sense to start giving IOT devices a static IP, and then when it's detected as participating in a DDOS share the IP to others and block it?

Almost all IoT devices of the sort we are talking here (ie, consumer level) are deployed behind home grade routers (or ARE home grade routers) and are using IPv4 and NAT/uPNP to reach the internet.  That means they are sharing an IP with legitimate traffic for one and for another are using a dynamic IP, not a static IP, meaning there's even more opportunities for innocent parties to be caught up in such a blacklist.

Once the glorious world of IPv6 comes, we can likely do just that - assign each one a routable IP address and blacklist them as they get shown to be vulnerable.

One legitimate thing that CAN be done is for ISPs to perform source IP filtering - that is, don't let spoofed packets out, only let packets from IPs within the network.  That will help. Some.


Is writing programs in .NET less secure since they can be easily reverse engineered? I had an interesting conversation recently where I was told that Microsoft .NET is not secure since it is more easily reverse engineered than languages like C. Is there any validity in this?  If I were to write a section of code which I did not want to have reverse engineered, would writing it in C provide that much additional security?  I'm no expert on the subject so I'm interested in what the sage people of IS have to say.

Are you looking to protect the code because of an intellectual property requirement the person/company you are writing the code for has? Then I guess writing it in C could make it a bit more challenging to decompile, but someone with the required motivation and skills would go around that by reverse engineering it using many of the available tools; maybe a dissembler like IDA: Wikipedia - Interactive Disassemler

On the other hand, if you are looking to hide the logic of your application in order to make it difficult to find vulnerabilities, you are going down the path of "security by obscurity", which is quite worthless from an application security perspective. As wireghoul said, this logic would imply that all closed source applications would be secure and open source software would be a disaster. In fact, both have the same families of vulnerabilities and flaws that are exploitable.

I would instead invite you to invest some time looking at Secure Coding Practice Guidlines and Core Security Concepts. A quick lookup on Google about those topics will guide you and there is also plenty of good literature on this subject.


As a non-security professional how should I respond when told my site is insecure? We have a website, and somebody wrote us an email claiming we are insecure!

What should I do

Stay calm, and be nice to the person reporting this. If they are contacting you, they only want to help, so do not threaten them.

Also don't ignore them, make sure they understand that you are interested in fixing this. Explain to them that you need time to do this; ideally you can give them a time frame in which you think that you can have this fixed (right now, it does not seem that you can estimate this, but keep this in mind for future incidents).

If you do not fully understand what they are telling you, you can ask for clarification and a proof of concept (although make sure to formulate it in a way that does not sound demanding. Depending on the country they are in, this might cause them legal trouble).

If you do not have developers who can fix this, either hire someone external or have your developers read up on common security issues and how to fix them (especially SQL injection) for the language (and/or platform, software, libraries, etc) that you use.


Can Passpoint X.509 certificates be used to MITM SSL connections on Passpoint networks? Passpoint/Hotspot 2.0 public networks like LinkNYC require users to install X.509 certificates, for EAP authentication.

Can these certificates be used by the provider to execute man-in-the middle attacks between the user and HTTPS websites that the user is browsing?

Or, are certificates/CAs installed for EAP authentication different from the OS/browser's SSL certificate chain?

If the Passpoint AP provides a self-signed certificate or even a new root CA, does trusting these certificates open the client to MITM attacks while using HTTPS sites on that network?

Also, the screenshots provided by this LinkNYC user here : http://blog.alexflor.es/post/137705262900/linknyc-secure-gigabit-hotspot seem to suggest an entire chain upto a root is provided to be installed on the client. Is the entire chain presented simply because of the EAP-T(TLS) spec (as mentioned in the accepted answer here: Why is a CA certificate required for EAP-TLS clients?)?

The certificates in your linked images are commercial certificates, therefore your device trusts those already by virtue of the fact that the commercial root CA certificate is in its trust store.

The certificate you installed is probably a client certificate, which you use to authenticate yourself with the system.

It's my (limited) understanding that Passpoint systems must use pre-defined certificates as dictated to by the WiFi Alliance, and not ask you to install an additional root CA certificate in your trust store.


Is there a way to mitigate BEAST without disabling AES completely? It seems that the easiest way to protect users against the BEAST attack on TLS <= 1.0 is to prefer RC4 or even disable all other (CBC) cipher suites altogether, e.g. by specifying something like

SSLCipherSuite RC4-SHA:HIGH:!ADH

in the Apache mod_ssl configuration.

However, the problem with CBC seems to have been fixed in TLS >= 1.1; is there any way to (re)enable these ciphers for clients claiming to support TLS 1.1 or 1.2? There seems to be a workaround:

SSLCipherSuite ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH

which does the trick by specifying cipher suites that are only available in TLS >= 1.1. That seems to have the side effect of preventing TLS >= 1.1 clients to use any of the "older" cipher suites.

Is there really no way to explicitly tell mod_ssl to use CBC mode ciphers for TLS >= 1.1, but only RC4 for SSL/TLS <= 1.0? That would seem to be an optimal combination of security and compatibility.

One way to mitigate BEAST is to do nothing. It so happens that though the vulnerability used in BEAST is still there, exploiting it is rather difficult. It requires the ability to do cross-domain requests, with a high level of control on the data which is sent in the request; in particular, it needs "binary" data. Duong and Rizzo did not find a way to map the attack on plain <img> tags (hostile Javascript which produces such tags, with an attacker-chosen path: the path gets in the request, but it is text-only). In their demonstration, they could use two cross-domain holes, one in a draft version of WebSockets, the other in the implementation of Java from Oracle. Both holes have since been fixed, therefore, right now, BEAST does not apply anymore (unless you did not update your browser for more than one year, in which case you probably have bigger problems).

Since relying on the non-existence of cross-domain vulnerabilities is, at best, flimsy, browser vendors have also included some extra countermeasures, with record splitting. When the browser wants to send a block of n bytes of data, instead of putting it in one SSL record, it splits it into two records, the first being very small. Record boundaries have no semantic significance in SSL/TLS, so you can do such splitting without changing the meaning. However, each record ends with a MAC computed over the record data and a sequence number, and using one key derived from the initial key exchange. This somehow acts as a pseudo-random number generator. Therefore, the small record "emulates" the random IV generation that makes TLS 1.1+ immune from BEAST.

Ideally, the split would be 0/n: a record with no data (but still with a MAC), followed by a record with the actual data. Zero-length records are allowed (as per the standard) but buggy client and server implementations do not tolerate them (in particular IE 6.0); instead, browsers use a 1/n-1 split, which is just as good for defeating BEAST, but also works with almost all existing SSL/TLS clients and servers. At least Chrome and Firefox have pushed it last year.

The good solution is TLS 1.1+ but even on SSL 3.0 and TLS 1.0, the BEAST issue can be considered as fixed, at least in the Web context. Therefore, use AES, and be happy.


How do I know that malware on the client computer does not modify data transmitted to my webapp? I am working on a web application and have had an idea of a new feature I would like to add. The feature includes getting data from the user on their open system and receiving it on my server. For the sake of concept I am assuming my server is 100% secure and is guarded by a million level 80 warlocks and my dachshund dog Kevin. So our side cannot be compromised and is totally secure for this question.

The user goes to say a library and uses the computer there. From that computer they request a a webpage from our server. Then in this webpage they enter some data. This data then gets sent to my server and processed. My concern is how can I verify what the user typed in from the keyboard using their fingers is what really was sent to my server.

Lets say I user HTTPS to serve my content, so theoretically this data cannot be read/modified while in transit. But what if on that public library machine the previous day fricken Todd compromised the computer by putting some malicious code inside of the web browser which secretly and discretely changes the data sent to the server. So our user types in the word 'PNEUMONOULTRAMICROSCOPICSILICOVOLCANOCONIOSIS' and sees this being typed in on the screen. He then presses send, but when he does this the malicious code in the browser modifies the data to change the data to be 'ToddIsAwesome' and shows the user their message has been sent with the data he thinks was sent, but actually the data has been modified and the server gets data from the user, but it is not the data the user wanted to send. Is there techniques to verify this sort of thing? The user does not have to send the data from a website, it can also be installed software on a computer. My main concern is to get the data the user intended to send and to detect if modification has occurred from the moment the user types something in to the moment the server receives the request.

Short answer is: You can't.

All your server see is what the computer at the library sends. What programs or processes on that computer that generated the data is impossible for you to know. From the servers perspective, it might as well have been a pidgeon with a telegraph as your legitimate user.

The fact that the user entered a password does not mitigate this. Two factor autenthication with a cellphone does not mitigate this. Malware on the computer could hook into the browser and modify the HTTP requests after the password(s) has been entered.

There is one small thing you can do, though. Have the user digitally sign part of the message on another computer than the library computer, and then enter that digital signature into the webapp on the library computer. This could be his cellphone or a product such as a digipass. Since that computer is out of reach from any malware on the library computer, it is safe. The backside is that the user will have to enter the message he is signing on that device - not very practical for long messages. I have seen banks use this for signing the amount in a transfer, but not the account it is transfered to because that would be to user unfriendly.

That is only a partial solution that is only worth the effort for really high value targets such as bank. The easier solution is just to teach your users to not to do sensitive transactions from a public computer.


Can a CRL file contain multiple full stops in its name? Will a CRL file name such as fred.freddy.domain.crl work for a Certificate Revocation List URL? I cannot find any documentation to state that it will not work.

Closest that I have found is a recommendation that it should not be done in the following article: Designing CRL Distribution Points and Authority Information Access locations. Specifically:

  Now, we need to design a URL form. This means that we need to design the name for CRT/CRL file, virtual directory (if necessary), separate host (if necessary). There is no significant recommendations, except that file name should be simple and do not contain spaces and/or special characters.

Is anyone aware of a specific issue with using a dot notation for a CRL file? It works nicely with a current naming convention that we have and would easily allow admins be able to follow the pattern when creating new Issuing CA's in our environment.

The standards for CRLs specify the format of the file itself, not the filename. I have never heard of any client having issues with multiple dots in the filename - so, as long as it doesn't contain characters that the OS/filesystem can't handle reliably, there shouldn't be any issue.

As a general recommendation, you should avoid spaces and special characters in CA names, including underscores, since there are some products out there that have problems with that. So if you want the CRLs to have filenames based on the CA name, you need to remember that when creating the CAs. I've not heard of periods being a problem, but as a rule I go with "CamelCaseCANames" instead of "no.camel.case.ca.name". But this is an issue with the CA name rather than with the CRL filename.


openssl, create RC4-SHA certificate gmail.com Google, fb,... use RC4-SHA.
How does one create RC4-SHA self signed cert ?

Or even with aes128 key ?
I tried using using "genrsa -aes128", resulting cert was DHE-RSA-AES256-SHA

openssl genrsa -aes128 -out 1.key 1024
openssl req -new -key 1.key -out 1.csr
cp -f 1.key orig.1.key
openssl rsa -in orig.1.key -out 1.key
openssl x509 -req -in 1.csr -signkey 1.key -out 1.crt

The certificate has (almost) nothing to do with the encryption used in the SSL/TLS communication. The only purpose of the certificates used by the websites you mention is to authenticate the server.

RC4, AES-128, AES-256 are the encryption algorithms used by the SSL/TLS channel itself. In this context, SHA is the MAC algorithm name (used to ensure the integrity of the communication).

Both are encryption and MAC algorithms are set up with the cipher suites, which are configured on both client and server, and are (relatively) independent of the certificate. The only dependency is that some cipher suites require a certificate with an RSA key, others a certificate with a DSA key.

If you look at the cipher suite list in the TLS 1.1 specification, there are cipher suites for RC4-SHA, AES128-SHA and AES126-SHA with RSA keys. Any modern certificate with an RSA key should be able to supports these, provided that the SSL/TLS stack you want to use also supports them, and is configured to do so.

(You may also be interested in this question.)

In openssl genrsa -aes128, -aes128 is used to tell OpenSSL how to encrypt the private key it's generating (in the file itself).


Do card issuers give merchants new expiry dates for recurring payments? Recently I got an email from, let's say, “Company X” saying:

  some banks provide updated expiration dates for automatically renewing subscriptions

I find it really hard to imagine that my bank would go around giving out my updated expiration date to companies so that they can charge me more money.

If this were the case wouldn't that be a big breech in security from the banks end?

Do Banks Really Give Out New Expiration Dates?

Do Banks Really Give Out New Expiration Dates?

Yes.

This is a value-added service usually called something like Account Updater (emphasis mine):

  Serving as an automated, dedicated, and secure clearinghouse, VAU works by establishing a streamlined process for the electronic exchange of updated account information among participating merchants, acquirers, and Visa card issuers. So, when a cardholder's information changes, you will receive updated account information which may include new account numbers, new expiration dates, closed account and/or contact cardholder notifications.

("acquirers" means banks in this context)

To get the updated information, the merchant has to have previously performed a transaction with the card being updated, so it's not like someone you've never entrusted your card to can use this process to steal your info.

This is instead seen as a win-win for merchant and consumer.  If your credit card is re-issued for expiration, you don't have to run around to all your recurring subscriptions (Salon, LifeLock) and your stored card profiles (Amazon, Xbox Live) updating them before you can continue to purchase from them.  And the merchants don't have to chase you down or discontinue service because your card changed and you didn't realize that's the card they were billing.

  I find it really hard to imagine that my bank would go around giving
  out my updated expiration date to companies so that they can charge me
  more money.

The bank makes money off of the interest they charge on your credit card purchases.  If your subscription billing is interrupted because of a card change, or you end up not purchasing those  from stores because they didn't have an updated card, the bank loses money (well, "lost opportunity" money).  It's not at all hard to imagine why this is attractive to banks, merchants, and (quite frankly) consumers.


Use a WHERE clause that's stored in a table? Background:
I have a workorder management system (WMS).

The WMS has functionality that allows users to save queries.
The queries are saved in a database table called QUERY (in a CLAUSE column).

An example of a value in the CLAUSE column would be:
((woclass = 'WORKORDER' or woclass = 'ACTIVITY') and contains(description,'$paint') > 0  and historyflag = 0 and istask = 0 and siteid = 'SERVICES')

Scenario:
I'm trying to learn how to properly integrate the WMS system with a separate GIS system (both systems are broswer-based/Oracle/internal systems).
I would like to utilize the saved WMS queries by integrating them into the GIS system's web map. I'll write a GIS web map widget (JavaScript) that would allow users to choose and execute queries from the QUERY table.

From a drop-down menu, choose a WHERE clause name from the QUERY table, extract the value from the CLAUSE column, and use it in a customized filtering tool (to query a GIS table).

Question:
Would the above-mentioned GIS widget be vulnerable to injection? If so, what can I do to make it safe?

I'm new to the IT industry and am  trying to learn how to safely integrate/share queries between systems. Layman's terms would be appreciated.

No, your system doesn't need to have an injection vulnerability.

While you could implement these clauses easily (and insecurely) by doing an "eval", or tossing the result in a WHERE with no validation, it is possible to do that properly. You would parse the to verify it conforms to the proper format, and then build back a now-trusted query.


Basic question about why it's useful to have VPN encrypt traffic There may be a basic flaw in my understanding of how the internet works so sorry if this is a simple question. What type of attack does VPN protect against? For example if a local area network (let's call it alpha) needs to connect to local area network (let's call it beta) that is in a different city, often VPN is used. But why? Let's say it wasn't. Then packets are sent from alpha, they go through alpha's router to the ISP, the ISP sends the to beta's router, and then beta has them. I assume the ISP is fairly secure, for example a person can't easily sniff packets inside the ISP. So at what point does having a VPN that encrypts packets actually become useful? Is it that after packet's leave alpha's router they actually pass through a series of public server before they reach the ISP or something like that?

EDIT: let me reword the question. IP suite guarantees that a packet with destination address xxx.xxx.xxx.xxx will be delivered to xxx.xxx.xxx.xxx. Obviously if the sender or receiver is compromised by a hacker then the hacker will know the contents of the packet but the point of VPN is to secure the packet is in transit. But where in transit is it week without encryption? For example even if a hacker knows the IP address of a router that the packet will pass through he can't trick the router into giving him the packet, or can he? Is the argument we don't know who owns the router so it could have been tempered with so the owner is sent a copy of every packet?

Basically I'm saying if IP already sends it to one specific recipient, why is VPN needed?

The internet is a mesh of telecommunications lines run by different companies which are leased by ISPs which use them to sent traffic from customer to customer. Any one of the ISPs or telecommunications companies can sniff the traffic that goes over their lines or network devices in ways you cannot detect. Some governments have forced (or paid) ISPs to install traffic sniffing devices to collect traffic going through their networks, and others could have been breached by state sponsored or organized crime funded hacking groups.

There's really no assurance that anything going over the web is in any way secure, which is why companies use VPNs to encrypt traffic between offices and SSL is used for websites to protect browsing traffic.


Can root user have access to MySQL data? Having MySQL using auth_socket as default authentication mechanism for the root user scares me, so I change it to password authentication with rigid controls on password quality and documentation.

If a user manage to have root access to this linux machine that has a MySQL database but doesn't have the password to log in into the service, he still can copy/modify/destroy the data?

The root user will have access to, at the very least, the database file that is stored on the computer. This means reguardless of how the service is configured they can copy and delete the data. If your databse is not encrypted by some means he will be able to modify the data too.


GDPR data portability I know one of the requirements of the GDPR is for data portability requests. On a website I have, it has users that includes their address, contact number etc but it also tracks what the user downloads and pages they visit, contact forms they submit.

If Joe blogs submits a request for their data, would I need to give them a copy of every single bit of information I have or just the information they signed up with?

Also one of the requirements is to be able to transmit such data directly from an existing data controller to a new controller without hindrance. How is something like that to work? If the user is on site A and B they should be able to copy their information from A to B or vice versa?

The whole point of GDPR is that the data subject can know what data is collected and what data is processed in order to provide services. So you have to give them all the data you have on the data subject. Why only give them back the data they gave you?

The wording on portability is about using a common data standard and not a proprietary data format that would impossible to use in any other system. You need to export the data in some commonly parseable standard (XML, CSV, SQL, etc.).


Phishing emails and securing set up from compromise? I'm a one-man company and I'm getting a lot of phishing emails very similar to the emails from companies I use.

Some of these companies and the emails we exchange are very unique. How would these malicious senders 'learn' the type of emails and content I send?

Since the increase in phishing emails I've also noticed I'm receiving very few genuine emails from the businesses I used to deal with and as such business has slowed down.

My website is on a shared hosting. I use Webmail using Roundcube to usually send receive emails. I've also set up an Imap email account to my webmail account on my android phone (samsung) - is there any security I need to implement on that? The Imap security type setting for both incoming and outgoing server is set to SSL (accept all certificates) over port 465?

Could they be sniffing out content? If so, what are the recommended steps to prevent and to secure a compromised website/email?

It is highly unlikely that a malicious actor is sniffing email servers around the world to figure out how to craft phishing emails.

What is more likely, is:

your email accounts have been compromised
these companies have been breached, and the malicious actor is simply reading the emails and address book of the compromised accounts
it's not targetted at all and that the malicious actors know the kinds of emails the companies' customers expect and just copy the style

Without specific details, I can't get more definite than that.

As a customer, there is no defence for the last two. The problem rests on the other company's side. You can help by reporting these phishing emails to the companies so they can follow up on their end.

For the first one, the defence is pure account security practices:

choose strong, long passwords (hopefully randomly generated and managed by a password manager)
enable 2FA on as many accounts as you can

If you are already compromised, then you should immediately change all passwords.


What are the possible rules to identify password sharing- to prevent fraud I am trying to build correlation/ potential red flag rules to detect if passwords are being shared or stolen... the primary driver for this is guidance from our compliance team, that much of our frauds in payments have arisen because of deliberate sharing or theft of a co-workers credentials (e.g. in maker checker etc). I was asked to look at a data-centric approach to solve this

some thoughts include
a) password being used at 2 IP addresses that area physically far from each other
b) software application being accessed without physical access swipe record (that would indicate entry into work area)

Any thoughts/ guidance around how to build a comprehensive list of flagging suspects here

I believe you are concerned with multiple people reusing a shared identity, not just the specific case of shared passwords. If you are using some kind of persistent session, you can close the one session when the next one signs on.  You can consider a GeoIP solution to see if your users could have traveled to the new location in the amount of time between the prior logout and the current login, but know that GeoIP systems aren't perfect.

Instead of automatically enforcing an error, you are probably better off defining an acceptable use policy, and telling your users "don't share passwords, don't leave yourself logged in", that sort of thing. Use timing data to enforce the policy.


What is the threat model for AWS EBS volumes encryption? AWS provides the ability to encrypt EBS volumes, the value of which I am wondering about. In the "Overview of Security Processes (October 2016)" whitepaper, page 24, they say:

  Encryption of sensitive data is generally a good security practice,
  and AWS provides the ability to encrypt EBS volumes and their
  snapshots with AES-256. The encryption occurs on the servers that host
  the EC2 instances, providing encryption of data as it moves between
  EC2 instances and EBS storage.

So what is the threat model there? Whom the feature is supposed to protect data from? Bad guys who may get physical access to the EBS server racks and try to scan/analyze/extract the data they need from the myriads of physical disks?

Or, maybe, from AWS admins who have access to the host machines, have control over the RAM and hypervisor where encryption happens and can potentially access the unencrypted data anyway?

tl;dr Auditors

Many data security audits require data to be encrypted at rest. Often the threat model is an old hard drive ending up on eBay or picked out of the dump. If the data is unencrypted on these drives and they are not properly handled/destroyed there could definitely be data loss. There is also the classic "truck backing up into the datacenter" threat vector where people make off with whole servers but no decryption keys.


Can a MITM sniff and see TeamViewer's session? I'm a bit concerned about TeamViewer's protocol security. Before you get started, keep in mind this question is related to TV. I know there are other solutions like SSH, OpenVPN, LogMeIn, etc. but in this specific case the question is for TV only.

Having set that aside, my main concern is that even if the computer has a root CA (like the one Fiddler installs to sniff HTTPS traffic) -or- if you use Wireshark to grab TV's packets, is it possible to retrieve the screen information so you can see it, or is that encrypted somehow?

I know they use some kind of key sharing in the connection negotiation procedure, but I'm concerned also if with the root CA, a firewall or sniffer of some kind can get those keys and decrypt the data. I don't want/need a generic answer such as "Any MITM can sniff all packets so you're not secure" because that's not true. You can sniff them but if you can't decrypt them in any way then it's all good (at least for my question's objective).

Basically, I want to know that even if I'm running through a proxy/firewall/someone-else-using-a-sniffer-inside-the-proxy, the whole screen can't be seen either in realtime or by packet replay. Thanks in advance! :)

(Before you ask, I'm working on an app which works in a similar way, with master servers and all that, and I'd like to know if by using the same key exchange methods and data encryption is secure enough unless someone tries to break the protocol using a special app that mimicks the app server instead, which would take a lot of work and in the case of TV and my app, such app does not exist yet AFAIK).

Team Viewer's website provides the answer to your question.

  TeamViewer includes encryption based on 2048 RSA private-/public key
  exchange and AES (256 bit) session encryption. This technology is
  based on the same standards as https/SSL and meets today's standards
  for security. The key exchange also guarantees full, client-to-client
  data protection. This means that even our routing servers are not able
  to read the data stream.


Is bcrypt(strtolower(hex(md5(pass)))) ok for storing passwords? I have a large database where passwords are stored as strtolower(hex(md5(pass))) (which is a bad way to store passwords, prone to rainbow tables, cheap to dictionary attack, no salt, etc.),
and I'm tasked with switching from md5 to bcrypt,
I have to use a bcrypt implementation that silently truncates after 72 bytes, and silently truncates on the first null byte (whichever comes first), and bcrypt(strtolower(hex(md5(pass)))) would not be prone to either of those issues.
Also it's possible to retroactively apply bcrypt to existing strtolower(hex(md5(pass))) password hashes, without requiring everyone to re-login/switch passwords.
Is it a bad idea? I don't think so, but still want to hear what this site has to say. Maybe there is something important I'm missing.

As a password cracker, I encourage all of my targets to use this technique.
This (understandably!) seems like a good idea, but it turns out that against real-world attacks, wrapping an unsalted hash with bcrypt is demonstrably weaker than simply using bcrypt.
(EDIT: First, to be clear up front, bcrypt(md5($pass)) is much better than md5($pass) alone - so none of this should be take to mean that this scheme should be left as is.)
Wrapping an unsalted hash is problematic from a real-world attack perspective because attackers can do this:

Acquire existing MD5 passwords from leaks - even MD5s that haven't been cracked yet
After simpler attacks have been exhausted, run these MD5s as a "wordlist" against your bcrypt(md5($pass)) corpus, to identify uncracked bcrypts with known MD5s
crack those MD5s outside of bcrypt at much higher speed

And yes - you do have to discover the MD5 inside the bcrypt first. But the crucial point is that that MD5 can be an otherwise uncracked MD5 that happens to be present in some other leak, which you can then attack at massively increased speeds.
This is not a theoretical attack. It is used all the time by advanced password crackers to successfully crack bcrypt hashes that would otherwise be totally out of reach for the attacker.
How this attack works is very non-intuitive for non-specialists, so I strongly encourage skeptics to experiment with a real-world scenario to understand how it works:

Hash a 6-character random password with MD5.
Presume that this MD5 is already present in some other list of leaked passwords, proving that it has been used as a password at some point.
Try to attack the MD5 directly with brute force.
Wrap the MD5 in bcrypt and try to attack it directly with brute force.
Attack the same bcrypt-wrapped MD5, but this time pretend that you haven't cracked the MD5 yet, but instead use a "dictionary" of leaked MD5 that includes your MD5.
Once you've "discovered" that you have an MD5 in hand that is inside one of your bcrypts, attack the MD5, then pass the resulting plaintext to your bcrypt(md5($pass)) attack.

Again, very non-intuitive, so play with it (and don't feel bad that it takes work to understand it; I argued vigorously against it with Jeremi Gosney for an hour straight before I finally got it!)
I don't believe that this technique has an "official" name, but I've been calling it "hash shucking" or just "shucking."
So depending on use case, it's totally understandable why wrapping bcrypt can be attractive (for example, to get beyond the 72-character bcrypt maximum, though this can be tricky for other reasons, including the 'null byte' problem), or to migrate existing hashes.
So if someone needs to wrap a hash in bcrypt, the mitigation for this weakness should be clear by now: your inner hash must never appear in any other password storage system that might ever become available to an attacker. This means that you must make the inner hashes globally unique.
For your specific use case - in which you need to preserve existing hashes - there are a few options, including:

adding a global pepper within your web or DB framework - so, bcrypt($md5.$pepper) This allows you to easily migrate existing MD5s, but that global pepper is still subject to being stolen (but if your web tier is segmented from your DB tier/auth, this might be an acceptable risk, YMMV);
adding a global pepper using HSM infrastructure (storing the pepper in such a way that not even the web app can see, so it can't be stolen)
adding an extra per-hash salt (but you'd have to store it outside of the hash somehow, which starts to get tricky and verges into 'roll your own crypto' territory);
hashing the MD5s with a slow, salted hashing algorithm or HMAC inside the bcrypt layer (not recommended, I'm not even vaguely qualified to advise on how that might be done properly, but is possible - Facebook is doing it, but some very smart people designed that);

For more details, including some specific scenarios to illustrate why this is weaker than bcrypt alone, see my SuperUser answer here, this OWASP guidance on "pre-hashing" passwords which supports my assertion with more clarity, and this talk by Sam Croley discussing the technique.
Password upgrading in general can be tricky; see - this answer and Michal Špaček's page on password storage upgrade strategies.


What is the Best Practice to change a secret password with PBDKF2 I read about recommendations about secret keys (or password as rfc8018 call it), one of them is to change the password from time to time.

I would like to know: is there some best practice for this change of password?

I found this reference in the RFC with the following information:

  changing a password changes the key that protects the associated DPK(s). Therefore, whenever a password is changed, any DPK that is protected by the retiring password shall be recovered (e.g., decrypted) using the MK or the derived keying material that is associated with the retiring password, and then re-protected (e.g., encrypted) using the appropriate MK or the derived keying material that is associated with a new password.

I understood from this text, that I have to re-protect again.
But when and by who this process has to be made?
"re-protect" could be a batch process? Or is there a better option?

In short, how to carry out this process without reinventing the wheel?

Clarifying the reference to password

I believe IMHO, that the word password leads to confusion, I have used the word password since the RFC refers to it as follows:

"In many applications of public-key cryptography, user security is ultimately dependent on one or more secret text values or passwords. Since a password is not directly applicable as a key to any conventional cryptosystem, however, some processing of the password is required to perform cryptographic operations with it.  Moreover, as passwords are often chosen from a relatively small space, special care is required in that processing to defend against search attacks."

Reading the text, I think this password is not related to user passwords (I could be wrong), For me this is a secret that can be used by the entire application, in my case to encrypt a text.

I hope I have clarified the point, Thank you.

In the context of having to enter your password to access your encrypted information: you don't derive the key that encrypts data using PBKDF2.

Every file (or thing) is encrypted with a unique randomly generated "session" key and salt (e.g. a 256-bit encryption key)
that per-file "session key" is encrypted with a Master Key (and salt)
the master key is also a randomly generated 256-bit encryption key

That Master Key is then encrypted with a key derived from the user's password.

The basic goal is that:

each file is encrypted with a cryptographically strong 256-bit key
all the session keys are encrypted with a cryptographically strong 256-bit key
and the master key is encrypted with the user's password

The virtue of this is that data and the session keys are protected with an excellent cryptographic keys, and are not the weak points.

And when the user wants to change their password:

you don't have to decrypt and re-encrypt all their data
you don't even have to decrypt and re-encrypt all the per-file session keys
you only have to decrypt and re-encrypt their master key


Losing the Initialization Vector in Cipher Block Chaining I have written a message and encrypted it using cipher block chaining.

What will happen if the receiver loses the Initialization Vector, or doesn't receive at all?

In a cipher block chain, each block is XORed with the ciphertext of the previous block, not the plaintext. So even if you cannot decipher one block, as long as you have received the complete block intact and correct, you can still use it to decipher the next one.

So, if your receiver doesn't have the Initialization Vector, they will be unable to decipher the first block they receive. But as long as they receive the first block, they will still successfully decipher the second (and each successive) block.


Does SSL/TLS have the feasibility of detecting malicious things during transmission? As per my knowledge the current implementation of SSL/TLS does not have the capability to identify the data is malicious or not during the transmission or before encrypt the data.
If its have , kindly do let me know.

If its not having the trend of identifying of it, then what's wrong on going it that to implement in such a way to get the same time as current SSL/TLS working now ?

As per my knowledge the current implementation of SSL/TLS does not have the capability to identify the data is malicious or not during the transmission or before encrypt the data. If its have , kindly do let me know.

SSL/TLS is just for transport of the data and has no idea of what the data are for. Therefore it can and will not detect "malicious things", whatever these are. But it can detect somebody trying to sniff or manipulate the traffic in between sender and recipient.

  If its not having the trend of identifying of it, then what's wrong on going it that to implement in such a way to get the same time as current SSL/TLS working now ?

Proper detection of "malicious things" can only be achieved if the attacker sets the security flag as defined per RFC 3514. But please note that this is only defined for IPv4 for now. Please also note the date this RFC was issued.


Are Portable Password Managers secure? I have been using KeePass2 for a while now and I think it is a very good password manager. There also is a portable version and I often read recommendations for KeePass where the portable version is praised as a nifty feature.
But is it safe to use any portable password manager on a computer that is not one's own?
How easy is it for an adversary to access the passwords on the insecure computer once they are decrypted?
Is it safe to use if the PC admin is trustworthy (e.g. at school/work)?

My advice would be to simply never open a password database on a system you do not fully trust. If you must, then put the minimum needed passwords in that 'public' database and make sure you have a solid expiration policy in place.


Finding a trojan on an android device An acquaintance of mine recently came to me with strong suspicions that their non-rooted 6.0 Android device had been infected by a third party who has regular physical access to it.
While I have a background in information security, conducting pentests and whatnot, I don't know much about Android forensics. Most of the documentation I've found online is dedicated to contacts / text messages recovery, which does not really fit this particular scenario.

Putting the device under Wireshark and looking at the traffic hasn't yielded anything, but stock ROMs are packed with so many apps that there's a lot of background noise.

Is there a particular methodology I could follow to figure out whether a trojan has been installed on the phone? I'd accept references to books as well.

Thanks in advance!

I've had some years of experience with hacking round in mobile environments, here's some of the methods and notes that may help you in getting up-to speed and keeping your own hardware a bit safer while performing your investigation.
For general threat modal and network sniffing ya may wish to check my answer posted to the question of detecting if a phone is secretly sending data noise will have to be sifted though though if the target device isn't compatible with non-root firewall options suggested there and be sure to pay attention to referenced malware jumping from Android to USB connected PC before attempting USB connected forensics. Another option I don't think I listed there was that DNS look-up monitoring/poisoning may help in sorting legit apps' traffic from non-legit traffic.

Small warning, while I've not seen it in the wild it's very possible that the infected device could attempt to attack the Wi-Fi networks it comes across, so consider making a VAP (Virtual Access Point) to separate the network of the infected device from anything else while performing MiTM investigations. Metasploit and others aren't too difficult to install on Android so be very cautious of that infected device sneezing on others.

Now because you've stated that network traffic is noisy and you'll likely end up plugging it in to a USB for imaging it would behoove you to consider either USBguard or disabling HID entirely and use ssh to interact with your forensic device. However, because malware keeps getting smarter it would be a good idea to only use a cheaply replaceable device for USB based forensics; hint web search "system on a chip" and narrow the available options to boards with x86 CPU architecture to have an easier time loading ADB (Android Debug Bridge) drivers and maintaining a solid connection for imaging the file system.

Note once you've sufficiently secured the device that'll be connecting to the possibly infected device the best thing to keep in mind is that push & pull commands with ADB are just as forgiving as in-file and out-file command line options used with dd, which is to say not very forgiving, so be careful.
Side note, Tripwire and similar file system tools can be very helpful for finding cross platform malware, but that and others would need setup prior to plugging in the infected device... only really applicable if your threat modal is sufficient to require forensic inspection of the device preforming forensics operations on the possibly infected device, and this also stats the line of questioning if the watcher is watching the watcher watching the watched in a trustworthy way... and if we go down that line of thought I'll hit the character limits for posting answers again.

Next up is emulating the imaged device, there's a few options but the AVD (Android Virtual Device) manager that comes with Androids' SDK (Software Development Kit) should be sufficient for this task. Make a backup of the possibly infected device, load a AVD to simulate the target's hardware and restore the backup to the emulated device's file system, then go to town on dissecting memory or setting breakpoints or even attempt to penetrate the emulated device in order to find egress points used by the original malware... it maybe possible to root the emulated device too to test if possible malware has been waiting for that before taking actions... oh and be sure to unplug/unmount and remove power from the physical device that maybe infected once you've loaded it's backup into the emulated environment. So long as you're working on an emulated version of the infected device your actions won't break anything for the client so get as rough with the emulated device as you like, however, if you've the space make a backup of the backup so that bricking the emulated device doesn't require re-plugging in the possibly infected device.


HTTPOnly Cookies: Security Depends on Client Cooperation? I've been implementing HTTPOnly cookie-based session handling and have some questions about what HTTPOnly means.

I realise it's a flag that gets passed around in the HTTP header when setting cookies. I also realise that most browsers refuse to allow modification of said cookies via client-side scripting.

The idea, if I've grasped correctly, is that Mr Example browses to an compromised page, his IE9 browser or whatever will reject any attempts at cookie-theft from the planted script.

However, seeing as the cookie is stored on the client-side, the actual HTTPOnly flag means little for anyone determined right? If it's stored on the client-side, then surely the client can find a way to alter the contents outside of a legitimate HTTP request?

If so, am I right in reasoning that HTTPOnly isn't to protect against non-HTTP modification from the client itself, but rather modification via malicious scripts running on a modern enough client? I.e., not blocking potentially-malicious modification of cookies by the client per se, but unknowing modifications specifically?

Yup, that's the exact definition of a HTTPOnly cookie. Of course the client can do whatever it wants to itself - so this isn't surprising. The goal is to protect the client from malicious websites (as opposed to protecting the client from itself).

This segues nicely into one of the Golden Rules of programming, with extra emphasis on game development: Don't trust the client.


Is e-mail sent from a Gmail address to another Gmail address encrypted? Gmail provides an SSL connection and also encrypts the entire session by default. But if you send a mail, once it leaves gmails servers, it can be read at any point on the internet. But what about Gmail to Gmail paths (i.e. I send an email from my gmail account to somebody elses gmail account). Is that encrypted too, within gmails own servers? Also the same question for gmail chat (chatting with another gmail user).

While we have no visibility of Google's internal security measures, there is a more general answer.

There are two common approaches to securing an email.

You can encrypt the contents at one client, and decrypt them at the other client.
You can set up secure channels and send the mail over that.

Both work in theory, but in practice it is very difficult to be sure that the channel stays encrypted over the whole of it's journey, because you usually don't control each step of the way.

In addition, even if Google were encrypting their internal traffic, they decrypt it at various points so they can read the contents (so they can target adverts at you) so they, or an internal attacker, can access your mail regardless.

So as a general rule, if you need to email confidential information, you should encrypt it at the client.