How big is the threat of Desktop Linux malware?

First, let's dispel any thought that Linux is somehow magically immune: classic file infectors, trojan horses and rootkits all existed on Unix well before Windows became prominent. I believe there's a number of reasons why classical Windows Desktop-style malware will not get a foothold in the population of Linux desktops. I don't believe any single reason is enough, but taken all together, they add up to something like "herd immunity".

Linux has a tradition of separating "user" and "administrator" roles. It's not mandatory, and it's not impervious, but it's there.
Linux has more sensible file permissions, read/write/execute, and the user/group/other separation, along with setuid. This also is just a small thing, and if you read Experiences with Viruses on Unix Systems by Tom Duff, you see that it doesn't work at all in interactive, 80s-style multi-user systems.
Linux has a very fractured hardware and software base. I run ancient 2003-2006 era hardware at home.  It still works very well. But it means that malware writers can't count on anything as far as hardware goes. Same for software: there's almost always between 3 and 10 candidates for any particular niche. Email clients abound, and each has a loyal user base. If that's not enough variation, every distro compiles their own, so no consistent "build" is present on a critical mass of desktops. Also, versions of everything, including the kernel, change far faster than Microsoft changes things. For any particular candidate software in a given niche, many versions exist in the wild. It's also not that uncommon to compile whatever yourself, so you've essentially got an uninfectable version of whatever utility.
Linux has a better tradition of separating data from executable files. /usr/share contains documentation, /bin and /usr/bin contain executables, /etc contains configuration. Everything gets different ownership and permissions. Again, like file permissions, not mandatory and not solid, but it exists.
Linux does not have the array of special cases that Windows has. From multiple-rooted file systems ('C:' vs 'D:') to specially, magic files names that appear in any directory ('AUX', 'CON', etc) to "long file name support", Windows requires a good deal more care when programming. These special cases also provide niches to hide files, or get things to execute.
Magic file name extensions. This one has always boggled my mind - who thought it was a good idea to make a file executable by part of its name? Also, who thought that hiding the extension from a user is a good idea?  How many viruses/phishing attacks came about because you can execute a file named "Threesome.jpg.exe", but the file browser hides the ".exe" part? Yes, another small thing, and yes, you can configure it away, but nobody does. For a long time, Microsoft didn't enumerate what extensions made a file executable, so every once in a while, a new kind of file-infector would crop up.
Linux has far better documentation. Yes, plenty of "Head First", "For Dummies" and somewhat more advanced titles exist for Windows. But you've always got the source for Linux. Anyone can verify that some particular documentation is accurate. Nothing gets handed down from On High. I'm thinking of officially-sanctioned things like the Inside Windows NT series, which seems like it's gone through 3 authors and 6 or 7 editions. All that fluff, yet nobody has officially documented the NT native API. Just so you don't think that I'm hating on Microsoft, Oracle has the same sort of problem, as did DEC in the past.

Some of these are social (traditions), some are at least a little technical (file extensions) but have a social component. There may be more, but I think any two or three of the differences above make Linux users into a less vulnerable population.


Can someone explain how sshd does privilege separation?

29266, the unprivileged child

This one is the privileged one, as the process title shows sshd: test [priv], the 29268 is unprivileged postauth child (user is already test instead of root).

But the main place where you can use privsep is before authentication:

root     11759  0.0  0.0  69928  6056 ?        Ss   Feb07   0:00 /usr/sbin/sshd -D
root     10071  0.2  0.0 119280  7096 ?        Ss   10:56   0:00  \_ sshd: unknown [priv]
sshd     10072  0.2  0.0  71272  3016 ?        S    10:56   0:00      \_ sshd: unknown [net]

There you see the privileged process running under root privileges (10071) and net-child (sshd: user [net], running under sshd user, and usually under some sandbox which prevents most of the privilege escalation attacks, it there was a hole in the code.

So as already mentioned by tylerl, or you setuid is used to drop/change privileges from root to sshd or your user. But note that you need to point out to the correct process when trying to understand this constellation. Image is usually more than thousands words:

Where in the image corresponding to your example:

the first privileged is sshd daemon (your pid 28389)
the second one privileged is monitor (your pid 29266)
you don't have in your ps unprivileged network child (mind pid 10072)
the user privileged is child (your pid 29268)


What all security do i need to check to secure my application?

Let's start with whether you need anti-CSRF tokens if you are using JWT tokens. The question is rather, if you are passing JWT token via cookie or not. If you don't pass the token via cookie, you don't need anti-CSRF tokens.
Regarding what you need to consider to do make you application secure. There are different approaches to application security. I would advise to download the OWASP Application Security Verification Standard and to implement at least all Level 1 requirements. Yes, there are many, but not everything will be relevant for your application. This is also a great point to start learning about application security too.


does HTTP PUT data get encrypted over TLS (HTTPS)?

Your curl command.first triggers a DNS request to resolve someserver. So even if the whole will get encrypted man can still get this information.

Then a TLS tunnel is created to this server to the port you specified (5000 in your exemple). This would trigger certificate exchange and keys exchange to encrypt the HTTP request itself.

The whole HTTP protocol being encrypted in the TLS tunnel, none of their methods would be available for a man-in-the-middle.

You can verify it by using tcpdump or wireshark while running your command.


has there ever been router virus able to send SMS (text)

First, if your bill has truly unauthorized charges, then you are most likely the victim of cramming.  If you didn't personally ask for the service, then you don't have to pay.  Have your service provider remove the charges.

Next, is it technically possible for a router to send a text message?  Yes.  Sending a text is easier than you think.  Basically, send an email to  TargerPhoneNumber@ServiceProvider.com.  Here are some examples.

AT&T: number@txt.att.net.
T-Mobile: number@tmomail.net.
Verizon: number@vtext.com.
Sprint: number@messaging.sprintpcs.com or number@pm.sprint.com.
Virgin Mobile: number@vmobl.com.
Tracfone: number@mmst5.tracfone.com.
Metro PCS: number@mymetropcs.com

So, sure... anything that can send an email can send a text.  That would include a router.  But! This isn't about technical feasibility.  This is about your ISP removing charges for services you didn't ask for.  AT&T was forced to pay $105 million for allowing third parties to cram fraudulent charges onto their customers bills in 2014.  Skip the technical wild goose chase and tell your network provider to reverse the charges.

Good luck!


Will this sandbox my user's javascript from my web IDE properly?

Use 2 separate hosts. On the IDE host deploy you services that provide IDE functionality: Editing of JavaScript, saving, comparing, etc. When user want to see how his code works, deploy it to another host, say USER host. Browser should load users code from this USER host and execute it. If you need to call some services on USER host from your IDE script, allow CORS requests on your USER host.


Secure encrypted storage of values that allows DB lookups?

I have faced a similar problem, for which I implemented the following mitigation. I would greatly appreciate input as I do not claim that this is necessarily an excellent solution.

TL; DR

Store IDs as HMAC(ID, master-key) and each user's password is used to derive a per-user key to encrypt master-key.

Adversary capabilities / limitations

It protects against an adversary capable of reading all at-rest data, but not one that can read memory (e.g. intercept inter-process communication between the web server and the CGI).

One-to-one salts hinder searching

Efficient searching in your case requires indexing and searching for a single value. By salting each ID number you have to calculate HASH(search query, salt) for all salts which is (a) inefficient when done for each search, and (b) ineffectual from a security perspective as described below.

Tiny search space

The primary issue lies in the fact that the search space of ID numbers is so small. Brute force attacks on hashes are, in addition to other means, mitigated by increasing work factors (a.k.a. stretching) with PBKDF2, bcrypt, scrypt, etc. However the search space is in fact so small that any significant-enough increase in work factor for adversaries would be too inconvenient for users (e.g. 30s+ per search).

Change the problem

My approach was to modify the problem to one of protecting a secret key. HMAC allows for both data (the ID number), and a key. IDs are stored as HMAC(ID, key) while searches are performed with HMAC(search, key). This requires exact matches, but can be made case-insensitive with uppercase(ID) and uppercase(search). A brute-force attack with a 256-bit key is infeasible even without increased work factor.

How do we protect the key? Query-API users are authenticated, so their password can be utilised (after salting and stretching) as the 'input keying material' (IKM) for HKDF. HKDF allows for independent keys to be generated from a single entropy source (the IKM) by inclusion of 'contextual information' and a salt. For the function HKDF(IKM, context, salt) where IKM = PBKDF2(password, rounds) we then calculate HKDF(IKM, 'Authentication', 'user-specific non-secret auth salt') and HKDF(IKM, 'KeyWrapping', 'user-specific non-secret wrap salt'). The former is stored in the database much like a regular password-authentication hash and the latter is used to wrap (i.e. encrypt) the master key used in the earlier HMACs (note that each user has their own wrapped master key).

Each time a session is authenticated, the unwrapped master key is wrapped inside an encrypted session. You can use HKDF with the (already secret) session ID to derive encryption / storage keys for the session. Unlike passwords which need to be stretched (incurring a second or two's delay upon authentication), session IDs can be generated from a CSPRNG (make sure to use HttpOnly and secure flags).

This raises another problem in that we need to initially wrap the master key for every user without actually knowing their password. Upon creating the user in the database they should have a private / public key pair created. The private key is encrypted with HKDF(IKM, 'PrivateKeyEncryption', 'user-specific non-secret PKI salt'). Each user can then have the master key given to them by an administrative user. Upon logging in the system checks their pubkey inbox for any new master key and then wraps it for next time. You could actually just use the asymmetric approach, but it's computationally more expensive.

Caveats

It is impossible to reset lost passwords without requiring an administrative user to give the master key to the user.
I'm NOT a cryptographer - there may be vulnerabilities that result from having multiple ciphertext instances of the same plaintext (EDIT: see first comment). If so, can this be mitigated by using random-length entropic prefixes and suffixes? Or is an IV sufficient? There may be other issues that I have completely overlooked.
This relies on ephemeral secret keys (password upon logging in, session ID on each request) being stored in memory. I'm not sure how your cron job will function; one possible solution is to have it use asymmetric encryption with knowledge of a public key whose private key is encrypted with the master key that all users can access (any authenticated session can then move keys into the database).
Does your threat model require such extensive engineering? Complexity results in more places for things to go wrong.


Are these SSH passwords of hacked servers?

I'm seeing the posted link and it seems to be an Indonesian facebook page, where the group writes IPs and credentials of different servers. I think so these servers don't belong to the group, but the group itself discovers them by sharing their credentials. I don't know what they do with them, but then the servers are most likely hacked for some purpose.
Similar attacks are performed by brute forcing an SSH connection through specific tool (Hydra, Medusa, ...), as you are seeing in your computer. So, it is very important to have a strong SSH password (alphanumerics>=10), to define a specific user for the SSH connection, and to disable the root/admin account for SSH logins. You can find a lot of posts on how to protect a SSH server:

http://www.tecmint.com/5-best-practices-to-secure-and-protect-ssh-server/

Unfortunately it's common to find out similar group of crackers (pay attention, not hacker), but it's the first time I see a clear fb page.


Can I safely trust my Anti-virus protection?

There are two distinct cases you should consider:

Your AV software blocks malware.
Your AV software removes or cleans malware.

The first one means that it was able to remove the threat before it executed, e.g. it detected malicious code in a file you were in the process of downloading. As such, your system should be safe. No malicious code actually executed on your machine.

The second one means that the malware executed on your machine, but was later removed. At this point, malicious code has executed on your machine, so there's a chance it could still be infected (e.g. with a kernel-mode rootkit that your AV software can't detect). At that point it's probably time to nuke it from orbit.


Should security-critical code be reused or rewritten?

The important thing is maintenance. Regardless of whether you reused existing code or wrote your own, you will achieve decent security only if there is someone, somewhere, who understands the code and is able to keep it afloat with regards to, say, evolution of compilers and platforms. Having code without bugs is best, but in practice you must rely on the next best thing, i.e. prompt fixing of bugs (especially the bugs that can be leveraged for malicious usage, also known as vulnerabilities), within a short time frame.

If you write your own code, then the maintenance job relies squarely on your own shoulders. And that job can be very time-consuming. For instance, if you decide to write and maintain your own SSL/TLS library, and use it in production, then you must understand all the peculiarities of cryptographic implementation, in particular resistance to side channel attacks, and you must keep an eye on published attacks and countermeasures. If you have the resources for that, both in time and competence, then fine ! But the cost of maintenance must not be underestimated. Reusing an existing library, especially an opensource one that is widely used, can be quite cheaper in the long term, since maintenance is done by other people, and widespread usage ensures external scrutiny. As a bonus, you cannot be blamed for the security holes in an external library if half the World shares them.

To sum up, the question is not really about code reuse, but about maintenance effort reuse.

(I write all this independently of the great pedagogical qualities of writing your own code. I encourage you to do your own implementations -- but certainly not for actually using them in production. This is for learning.)


Certificates are just the public key with some added context. The name of the key, signatures, usage guidelines, etc. SSL/TLS depends on that context. Otherwise the host you're connecting to won't know whether the key genuinely belongs to you or not. The SSL trust mechanism is built on the concept of explicitly trusted certificates and then the implicitly trusted certificates that they sign.

But if you're not using SSL or TLS, then encryption can still happen without it, but trust has to happen a different way. SSH is a good example of this: SSH still uses public and private keys, but since there is no hierarchy of signatures, the added information that certificates provide wouldn't be useful, so the key is sent bare. Instead, the client asks you whether or not to trust the server's public key the first time it connects, and every time thereafter checks to see if the public key matches what it saw last time.  This can happen because SSH does not use SSL or TLS for its encryption.

But if you're using the SSL protocol, the protocol dictates that the public key must be presented with the added context of the certificate. That is, the certificate is the container that the public key must be placed in for SSL to use it.

If you have the private key, it's trivial to create a self-signed certificate using a tool like OpenSSL.


What is the difference between http and https with a self-signed SSL certificate?

The purpose of the warning is that by using HTTPS, there is an expectation of proper security, but a self-signed or expired certificate has vulnerabilities that the user needs to be aware of.

The "risk" is that one thinks they are properly secured, but they are not fully secured, as opposed to HTTP, where one knows there is no encryption at all.

There would not be a warning for HTTP, because there is no security (i.e. encryption) to compromise.


How to acquire DNSSEC root trust anchor from IANA?

You can download the Root Zone file on the IANA website (HTTPS). This file contains the root keys you need. You can use grep to get the DNSKEY.

$ curl -s https://www.internic.net/domain/root.zone | grep "^\.\s\+[0-9]\+\s\+IN\s\+DNSKEY" > root.keys

$ dig +sigchase +trusted-key=./root.keys @8.8.8.8 eesti.ee


Is it possible to get an sql injection after importing a sql dump?

Restoring from an SQL dump is an SQL injection.
When you dump a database, you create a script which then executes on your database. This script contains the entire schema, as well as all the data. What you essentially do is tell the database: "Here is this script, execute everything there."
If an attacker can modify your SQL dump in any way, then they can insert, remove or modify any part of the database, since their code would essentially run with DB admin privileges upon restore.


Your list is a great start! I'd argue enough risk assessment to justify a privacy/security denial request in most organizations. In addition: Are you looking at one country or multiple country's laws? How about Network segmentation? Privacy violations? Controls to insure confidential or company secrets from getting leaked? Even simple data such as products ordered to your company could reveal insights to competitors.


Don't use JSONP at all - use CORS.

JSONP is obsolete and has always been more of a hack fill-in than a thought-out technology for resource sharing. The modern and widely supported alternative is CORS (Cross-Origin Resource Sharing). You will most certainly be able to replace all your JSONP use cases with it.

With CORS, you don't need to wrap your JSON in a callback function anymore (e.g. cb({"foo": "bar"})), but keep it as is. Instead, you send an Access-Control-Allow-Origin header to indicate to the browser which origins you want to give access. Since every CORS-capable browser sends an Origin header in their cross-origin requests, you can produce the ACAO header dynamically, depending on where the request came from. Once permitted, the client will be able to read the response content, no matter what content type. So you can just use send regular JSON.

Sample cross-origin request from supplicant.example to a JSON API at server.example:

GET /foo.json HTTP/1.1
Host: server.example
...
Origin: https://supplicant.example
...

Sample response:

HTTP/1.1 200 OK
....
Access-Control-Allow-Origin: https://supplicant.example
Content-Type: application/json
...

{"foo": "bar"}

Not only does CORS provide better security over JSONP, but it gives you the ability to work with arbitrary HTTP methods (PUT, DELETE, etc.), you can give access to particular headers, and much more. Mozilla has an excellent introduction to what CORS can do.


How does encryption force a processor to "pause"?

Your question sounds a little vague to me, so I can think of two things you might mean by forcing it to pause:

A programmed pause - in the event that you don't have access to the password hashes, and you're just trying to type a password into the device, the device can just arbitrarily wait a certain amount of time before telling you whether you succeeded or not.  This amount of time may increase with each unsuccessful attempt, though commonly the first few times have little penalty, due to human tendency to mix up password or type things incorrectly.  If someone has access to your password hashes, and is using their own software to test all combinations (a brute force attack), then they don't need to include that pause, and it will have no effect.

Computationally expensive password checking - certain hashing strategies require a LOT of computation* to verify the the password is correct.  These are intentionally used for password checking because you can't write your own software to bypass this.  While it may seem like it would be a bad idea to force your users to wait for this expensive computation, having to wait one whole second actually isn't that big of a deal for the valid user, but it's a huge deal when dealing with a person who is trying to guess the password by brute force, as that penalty is incurred for every single incorrect guess they make.  I should mention that while this may seem to just be a pause from the user's perspective, from the computer's perspective, it's a massive amount of work, which just doesn't happen to have any visible results drawn to the screen.

*a lot of computation compared to the few milliseconds that most operations take - actual delay may only be a second or so, depending on hardware.


Javascript - Client side encryption / key storage

(To be clear: this only protects users in situations that the attacker only gets read-only access and protects users who haven't used the site since an attacker replaced the javascript with a malicious version. It does not protect users from you being malicious from the start unless the user painstakingly verifies / records all javascript that your site delivers them. If that last part is important to you, there might be a way to use ServiceWorkers to alert users whenever a new version of your site's javascript is executed, etc, but that's for another question.)

You can store encryption keys locally in the client with localStorage or IndexedDB. The encryption keys could be strings that your client javascript uses.

On supporting browsers, for increased security you could use the Web Crypto API (+ IndexedDB) instead. With the Web Crypto API, you can generate keys in javascript and use them for encryption/decryption, but the javascript code can not get access to the raw key material no matter what. That means even if an attacker gets access to your server one day and replaces the javascript with a malicious version, they can not replace it with a version that leaks users' keys. (However, they could replace it with a version that makes clients download their files, decrypt them, and upload them back to the server in the background on the next time they go to the site. This would take time and could be noticeable to users and/or you, so it might give you enough time to patch the issue before all user data is leaked.)


Does the OpenID Connect Core specification incorrectly define the OpenID Provider and Relying Party in terms of human participants?

No, the definitions are correct.

Keep in mind that a relying party does not authenticate but gets authorised through the process where the end user first authenticated and then supplied an authorisation (in the form of a token) to the relying party.

More clarification on your final comment:

The OpenID provider does not Authenticate any Entity, it is specifically an Authorisation Server capable of Authenticating a human END USER.
The Relying Party is an application, either running on a server or on a user's device.  A human User needs to have Authenticated prior to a token being provided to the Relying party, hence the work End User in the definition.


Isolate a Virtualbox VM from local network

VLANing it is the best bet as it keeps it protected behind your firewall, but isolates it from the network.

The DMZ is next since it puts it in the open, but completely separate from your network (note that this isn't the same as simply using a DMZ ip address on a consumer router that simply allows a particular IP to be connected to, but doesn't isolate it from the internal network.

The third option strikes me as particularly difficult to implement and risky as a missed rule would allow access and the information is still traveling across the internal network.


You must use the secured HTTP connection i.e. HTTPS. I don't have working example but have a look at the classes under the package  javax.net.ssl.*.
Here I believe the server already supports it. If this is not the case then you have to get the server to supports it.


Is there a benefit in measuring randomness? How would it be done?

Oh boy, philosophy time. What is randomness? Can randomness be measured? What is a signal anyway?

Intuitively we can say that Thing A is more random than Thing B if it has more higher entropy. Entropy is one of those concepts that's easy to define and talk about, but actually measuring it from a data set is a statistician's nightmare. If your RNG outputs aaaaaaa... either your RNG sucks lemons, or you hit the one in a 10-n chance. With only one data point, it's impossible to tell.

For any statistical analysis of randomness to be at all meaningful you need at least a million samples generated in a lab environment where you can prove that your RNG was properly seeded for each sample. And even then you have to be very careful about which statistical tests you use because they all have a bias towards certain types of patterns. Trying to draw any conclusions about the quality of the randomness with less rigor than this will be ... inconclusive at best.

Bottom line: measuring cryptographic entropy in practice is hard and best left to researchers.

So that's the theoretical answer. In practice you can get a very rough idea of the amount of randomness in a string or file using the methods mentioned in comments / other answers: run it through a compression tool (which is a sub-category of Kolmogorov complexity tests), or one of the entropy-estimating stats tests mentioned in @EdwardBarnard's answer.

This type of thing is probably good enough for distinguishing an encrypted file from a plaintext file, but probably couldn't tell the difference between a compressed file and and encrypted file, or for that matter between a properly encrypted file and a badly encrypted file.

As for detecting covert signals, you're kinda out of luck if you're looking for a general solution. Tell me which off-the-shelf statistical tests you're using, and I'll design a steganography method that fools it. To have any hope of detecting this, you need to know a fair amount about the statistical properties of both the carrier signal, and the expected hidden signal, and design a detection algorithm around this. And of course the more noise naturally occurring in the carrier signal, the more places for covert signals to hide.


"Breaching Privacy Laws" - What could this mean?

As you said, you require personal information, transferred over a public internet connection. Anyone may get to know that this specific user had an interaction with the website, plus some of his personal data.

IANAL, but depending on the jurisdiction of the client's customer, this may well break some privacy law. Especially here in Europe we have quite a strict view about that.


What would happen if a public key server is compromised?

Anybody can upload anything to the key server network, and there is only minimal verification of syntactical correctness. Do never trust anything on the key servers without further verification!

Whenever you fetch a key from the key server network, you should verify it for validity, for example through comparing the key's fingerprint with the key's proclaimed owner through an already established, authenticated (not necessarily private) channel: by meeting him, through a video or voice call, by sending a letter.

  Is this even possible?

To consider what a malicious key server might be able to do, you have to consider different attack models.

Keyserver hosting false keys should not be a problem, as you need to verify them anyway. Search the key servers for president@whitehouse.gov, I don't believe a single one is Barrack Obama's.
Keyserver modifying keys will send keys with modified or added OpenPGP packets like user IDs or signatures, but your OpenPGP client will realize that and stop importing the malicious key, and tell you so. At least GnuPG is doing so. If the primary key is modified, this would result in a changed fingerprint, and resembles an added key, not a modified one.
Keyservers omitting data is well possible and a problem. A key server could hide a given key you should not see, or even prevent you from fetching a revocation certificate. This can only be prevented by fetching the key from multiple and if possible trusted servers using HKPS to prevent man-in-the-middle-attacks.

  Would that be detected quickly?

In case of omitted information, only if you notice it on your own, for example because data's missing on one server but hosted on another, and reconciliation does not take place for a given time (give servers some minutes up to several hours to fetch up on all updates).

You can realize that there are fake keys, but this is not really a key server problem but a problem with verification. You will realize modified keys because of warnings/error messages in your client application.

If you realize a key server is acting weird, and keeps on doing so, consider reporting to the SKS mailing list, which probably is the place most other key server operators get together. At least it might be removed from the SKS key server pool, which is default for most OpenPGP setups.


This blog post (Microsoft has totally embraced the document-by-blog fashion, apparently) describes the encryption format used by SQL Server. That's for SQL Server 2008, but, for backward compatibility reasons, the same format must be supported by SQL Server 2012. Block cipher mode of operation is CBC, there is an IV, and it includes some provisions for integrity check (a SHA-1 hash included in the encrypted data: that's a homemade construction which cryptographers will frown upon, although there is no flagrant weakness in it -- but, in these matters, you never know...). The blog post does not tell what kind of padding is used.
There does not appear to be any documented way to specify any other mode, either during symmetric key generation or when doing the encryption itself.


Hashes can be cracked using brute forcing. That means that you test hashing every possible input until you find one that generates the right output. To stop this a hash function used for password storage or key derivation needs to be deliberately slow (so that testing a lot of inputs take a very long time).

A site like the one you mention can also store a big list of known pairs of common inputs and outputs. Therefore they don't need to do a brute force every time someone sends them a hash to crack - they just need to look it up in the table. To stop this you use a salt (so that even a common password gets an unique hash).

You will note that they do not know the value of all hashes, just common ones. An example:

5f4dcc3b5aa765d61d8327deb882cf99 is correctly reversed to password, because that is in their database.
039c004d00c02a193144e96b3e8aa4ba can not be reversed to the random string tUGPP*yq24p+EgpQ that I just generated, because they can not fit all billions of possible random strings into their database.

So how do you protect yourself against sites like this? Use a slow hashing algorithm and a salt.


How can I use certificates to secure my webservices? What is available to javascript?

If you want to secure WS'es with fat client (standalone app, mobile app, other server) you can use WS-Security protocols suite. It's widely used in SOA's and other enterprise deployments. It provides strong auth, and some security and anti-replay solutions in standarized fasion.

But if you wan't to use JS the you would have to stick with authentication token and ssl. I guess.


Could receiving a URL link, not clicking on it, ever pose a security problem?

Many browsers send "pings" to any links on a page by performing a DNS query on them to populate the cache. This makes clicking the link faster because the IP is already in the DNS cache. In theory, a bug in this code could be exploitable simply because the link is there. In practice, this isn't an issue. Just because a link exists doesn't mean it can do much to you.


Random token and email confirmation key of 10 chars sufficient?

If you add limited validity period (like 20minutes) for these keys (csrf, email confirmation) then I would say it is sufficient.

Also this is assuming you do not keep any history of the keys.


Back in the days many viruses infected almost every binary they could find but these days are gone. The majority of malware is quiet now and tries to hide itself in a preferably unobtrusive place like the System Volume Information directory which is by default locked for every user even the administrative ones. This directory is a good place to hide because it exists on every modern (and not so modern) Windows system which makes the majority of all systems targeted by malware. This is not the case when it comes to recovery partitions. They aren't present everywhere and to infect them in a way that enables them to survive the restore process might be not the easiest thing to do.

So technically there are for sure viruses that infect the recovery partition because they infect all or random binaries but they will infect the recovery partition "by accident" and mostly in a way that won't survive a system restore from that partition. I have never heard of a malware that is targeting recovery partitions in particular.

A malware developer who specifically wants to realize this needs to know how the recovery process works and this process will differ from vendor to vendor and maybe even from model to model . This increases the expense for malware greatly.

I think the general problem here is that an infected file on the recovery partition might not cause an infection on the restored system. There are some binaries but the majority of the data is in my experience stored in a image of the partition that will be restored. When the malware infects the binaries and they are executed to start the recovery process they will only run on the already infected system but after the reboot they are gone. So the attacker needs to manipulate the image and maybe even the recovery tool if it does verify the checksum of the image that is going to be restored.

Overall it is surely possible but not very efficient because it is a very specific attack that won't work on the majority of all infected systems which makes it unattractive for malware developers.


Is Apple compromising network security with its default settings, which allow users to provide network credentials to other users with one tap?

First off - why would anyone consider this a security risk? Apple's implementation of the WiFi password sharing feature is much better implemented than Microsoft's attempt from a while ago. For starters:

You can only share the password knowingly, and with someone you trust: You still receive a notification when your friend wants to connect to your network and also have to both press a button to accept the request and have them in your contact book.
The underlying principle of a pre-shared key remains the same: This isn't changing the functionality through which the client connects to the router (like with a RADIUS server in WPA2-Enterprise) but just removes the requirement for you to speak out the key. In fact, I'd even argue that this method is more secure as you said in another comment since there's no chance that someone you don't trust or an eavesdropper might be able to lift the note with the password or just record you shouting it out to your friend.

Additionally, in an enterprise, you should already be using WPA2-Enterprise with a RADIUS server instead of a PSK. This already seems like a flaw in your current implementation.

Finally, the implementation doesn't automatically share your password with every user in your contact book. It still makes you explicitly approve each user through a dialog box.

And to:

  How could we switch this capability off?

It seems like an inbuilt feature without a way to turn it off. I'll update this answer if I come across anything in the future though.


What is the difference between FTP Brute force with hydra and Metasploit?

Both perform the same basic functionality for FTP password cracking in terms of word lists and brute force attempts. Metasploit has the added advantage that you can perform additional functions after you have gained access to the FTP service however.

I am not sure what the performance difference there will be between the two in terms of pure speed. That could make for a interesting comparison and would be the only area where a specialized tool such as Hydra could gain an advantage I suspect.


Computer worms, propagation and exploiting vulnerabilities

A good example of a self-propagating worm which targeted a specific vulnerability was Sasser which exploited a vulnerability in Windows to propagate.

The author of the Sasser worm was monitoring the updates Microsoft releases for Windows. One of them was fixing something Microsoft referred to as a "Critical Remote Code Execution Vulnerability", which for a malware author reads "$$$ JACKPOT! $$$". By downloading and examining the update he found out how exactly the bug worked.

Every Windows installation has a background program called "Local Security Authority Subsystem Service" (lsass.exe) which starts with the system and listens to port 445. Any other system on the internet can connect to this service. However, they can not do anything unless they send the correct login credentials, so this service is usually harmless. But Microsoft found and fixed a bug in this program: When you send a specifically crafted message to it, a buffer overflow will happen and parts of this message will be executed as a program.

So the author wrote a program which (grossly oversimplified):

connects to random IP addresses, port 445
sends the malicious message including its own code

When the system didn't install the update yet, it would also execute this program which would then do the same thing there.

This is basically how all internet worms work. The author finds a vulnerability which allows to execute arbitrary code. They write a program which automatically searches for vulnerable systems and then uses the vulnerability to smuggle a copy of itself onto the system and execute it.

What do we learn from this? Install any released updates fast, because the moment a software vendor releases an update, the vulnerability is known and black hats will start writing malware which exploits it. You must install the patch before they are finished!


How is danger / badidea / thisisunsafe justified?

It's probably within the spec. The phrase is regularly changed, and it's not something you happen upon by chance. You have to know what you're looking for (e.g. google 'chrome hsts bypass'), which indicates that you're aware of the risk.

The bar for using this is a lot higher than clicking 'Proceed', as it is not documented in the Error Message shown to the user.

In addition, there's really no certifying authority when it comes to RFCs. Parts of them are open to interpretation, and there is no official body that will tell you if you comply with a RFC or not.

Having a way to bypass it for users that do understand the implications is in my opinion wise, as it makes it easier to dissect if your own site is under attack - or if you are simply investigating for instance a phishing attack against your organization.

In short - it's an balancing act between being impossible and really obscure. I think the thisisunsafe is an reasonable balance. Unlikely to be used by unknowledgeable users, yet available when needed.


Why would I ever use AES-256-CBC if AES-256-GCM is more secure?

CBC and GCM are quite different. Both are secure when used correctly, but CBC isn't as parallelizable and lacks built-in authentication. Due to this, CBC is only really practical for encrypting local files that don't need random access.

As for any advantages it might have, CBC doesn't fail as catastrophically if the IV is reused, and it can be faster if implemented on basic hardware.

As for GCM, it's basically GCM = CTR + Authentication (not CBC). It's fast and secure if used correctly, and very versatile, hence its popularity.


The password is known, yes, but you can't run binaries from sideloaded apps. You need to modify the root filesystem to put an app into /Applications and make it tun root code.


SIEM is a tool, an object. Analytics is an action, a verb. The tool can contain the functions for actions (like analytics). The action is not a tool.

It is reasonable that tools for analytics do not aggregate or display alerts.


Are short messages hashed with a HMAC insecure?

No, they would not be.
At least, to this date[Feb. 2020], there are no known vulnerabilities relating to short messages with sufficiently sized keys. If this is all you cared about, feel free to stop reading here. The rest of the answer just go into details as to why it's not a problem.

According to RFC 2104, a HMAC is defined as follows:

As you can see, the key is XOR'd with a known constant, then concatenated with the message. This data is hashed, then concatenated to other data and finally hashed again. If the message m were just all zero's, it would still not give you any information about the key.
This can be demonstrated by a simpler construct, where all that happens is that the key itself is being hashed. One would not have any information about the key, and the best way of recovering it is brute force.


Why include the host in the signature of the Amazon HMAC scheme?

In general, you use an HMAC to ensure that a value isn't changed (ie: it doesn't lose integrity). So including the URL in the HMAC means that Amazon doesn't want to allow it to be changed once the HMAC is created.

In this case, including the URL ensures that a request targeted for one URL but somehow sent to another can be detected because the recipient's recalculation of the HMAC will use the actual URL, not the original URL, and the HMACs won't match.

This check will be in addition to whatever security is provided by encrypted communications (eg: SSL).


Is it considered "hacking" if there is no authorization implemented?

With regards to modern computer systems, if one were implemented
  without authorization, ...and a third party reverse-engineered the
  site to gain access to it, is it considered "hacking"?

Probably.  While the case never resulted in a precedent-setting judgement (due to the suicide of the defendant), United States v. Swartz represents a case where charges under the Computer Fraud and Abuse Act were filed against someone who scraped an online database using guest access:

  According to the indictment, Swartz surreptitiously attached a laptop
  to MIT’s computer network, which ran a script named "keepgrabbing.py",
  allowing him to "rapidly download an extraordinary volume of articles
  from JSTOR."

And from Wired:

  But the feds clearly think they have a substantial hacking case on
  their hands, even though Swartz used guest accounts to access the
  network and is not accused of finding a security hole to slip through
  or using stolen credentials, as hacking is typically defined.


MDK3 warns about WPA2 downgrade - how do I find the key in Wireshark?

Have you found the cleartext?  If not, there seems to be a bug in the code that could explain this.

The interesting code is:

  //Is encrypted?
  if (! (pkt_sniff[1] & 0x40)) {
      if ((pkt_sniff[30] == 0x88) && (pkt_sniff[31] == 0x8e)) { //802.1x Authentication!
          wpad_auth++;
      } else {
          wpad_wep++;
      }
  }
  //Check WPA Enabled
  if ((pkt_sniff[27] & 0xFC) == 0x00) {
      wpad_wep++;
      return rtnpkt;
  }

This code is intended to increment wpad_wep whenever MDK3 identifies either an non-encrypted packet or a WPA encrypted packet sent by a client to the AP - and this will cause the "REALLY BIG WARNING!!!" to be output on the next status update.

But there's at least one bug in the code. If the packet is a QoS data packet then the packet header has an additional two bytes in which case both the frame type and the WPA indication would be two bytes later in the raw packet - and the current MDK3 code is looking at the wrong bytes in the packet. So it's quite possible that the warning you're getting is a false positive due to a client using QoS data packets.


How to protect against mitm attacks in first connection? - no HSTS Preload

every single page that doesn't have HSTS preload is vunerable to mitm attacks in first connection

That's only true if you connect initially to the HTTP version of the website. If you manually add (or verify the presence of) https:// when going to the site, or if you use a browser extension like HTTPS Everywhere, you don't have to worry about being kept on the unencrypted site and MITMed.

If you want to be absolutely sure that you can't connect to a non-HTTPS site, you can configure the extension to block all unencrypted websites. This will allow you to avoid the risk of MITM without needing to manually verify that the website you are on is indeed using encryption.

Unfortunately, it's not possible for a website to prevent this attack on its own without preloaded HSTS. It's entirely up to the users of the website to be aware of the encrypted status of their session.


PHP files browsable: is this a vulnerability?

What you're describing is normal directory listing

In itself, directory listing is not a security issue. If the security of your system is compromised after figuring out the structure of your files and directories, then you're relying on security through obscurity, which is bad. Examples of this bad practice include:

Using secret directory names to access sensitive files.
Limiting the execution privileged functions to only access their URLs rather than using proper permissions.
Leaving special doors/backdoors for developers.

However, as part of a good security policy, after implementing proper security measures, it's beneficial to obscure the working parts of your system. The less you show about your system, the less information an attacker can get on you, which means you're making their job more difficult.

"So, what should I do?" you ask. Simple: Disable directory listing in your web server configurations. In Apache, you go to your httpd.conf and find the line where it says

Options Includes Indexes

Remove Indexes from the line, then restart your apache.


Is it normal for Chrome extensions to demand too many permission?

Well, to quote the extension's description, it isn't just for downloading Facebook videos:

  Download and save videos from any website (not only Facebook videos)
  (…)
  Downloads almost from 99% of video hosting websites

So, it makes sense for it to request permision for other websites as well.

Edit: After downloading and unpacking the extension (extensions are just renamed Zip files), I can see that besides functionality for downloading Facebook videos (using code in js/hooks/facebook.js, it has code for downloading VKontakte videos as well as generic video embeds using the <video> tag and in some cases video embedded using a Flash-based player; code for these cases can be found in js/hooks/content.js.

Some of the code in the extension is fairly obfuscated and I haven't bothered analyzing it all, but it appears to be benign.


Anytime you deviate from a standard install, there's a cost: You need to adjust your mind and tools to deal with the deviation. Precious seconds or minutes may be wasted in critical situations because no one else in the world uses fiddledimdunk as their MySQL root user.

Debian and others rename their MySQL user and that works best if you're running an all-Debian platform.

I've seen people fiddle with their .ssh/config for an hour to get chained ssh connctions working between jump-hosts because they moved sshd to a different port.

If you have a tool that lets you manage everything you need to, and you never need to manually log into your MySQL instance, it might be worth it for you, but I very much doubt it.

Instead, use that strong password you talked about and throw your log analysers at MySQL to detect anything odd going on.


What is secure enough for web applications?

Updated to take into account the zero Internet Access:

As you have mentioned, the switch can be configured to route the ISA server to segregate the application from the users. It looks from your model you are expecting the ISA to run a public and private VLAN through its connection to the switch.

More typically having a dual homed firewall is considered more secure, as traffic on each network is physically separated by the firewall. But basically the app server will connect to the ISA on a network port for the 'protected' side, and a network port on the 'user' side of the ISA will connect to the switch.

You can obviously use access control lists in the switch to provide further controls, however this may be all you need in terms of infrastructure.

One risk to look at is how likely a PC is to be attacked in your environment. Are they left unattended? And unlocked? Your infrastructure may then not be sufficient.

edited to say - if medical/personal data is on the server, and you are in a country with strong regulations in this area you may need to use stronger controls.


You can do it both ways, by initiating the OpenVPN connection:

from a host on your network or the router, to an OpenVPN server.
You need a server on Internet to connect to. This is a service you usually buy, but not necessarily - it can be a free one, a friend, etc. The traffic from this host (or all hosts if you connect from the router) will be secured, up to the OpenVPN exit point (= the server you connected to)
from a host on Internet, to a server you control (the router, or a server in your network).
You need to set up an OpenVPN server yourself or possibly use a functionality of your router if it has one (some ISPs provide this functionality on their boxes)


ufw, system-config-firewall-tui, or firewalld vs iptables

It has more to do with the management systems around iptables that each provides. Firewalld, specifically, was designed to make dynamic loading feasible.  With the old shell-script based iptables tools, if you wanted to make a change you would have to 'restart' iptables which involved taking down all the firewall state and bringing it back up again.  Depending on configuration, you could lose connections, tracking state, etc.

Firewalld lets you add entries on-the-fly and avoids these problems.  It also allows applications to interface with the firewall with a defined protocol, which makes it more usable for many people and allows packagers to help out the user.

It's also a bit of a pain in the neck for an admin who is used to just editing a text file.  The features are a trade-off for ease-of-use at this point.  One expects future improvements here.


I ran a virus on a PC. What should be the next steps?

All the steps you have taken are valid steps for malware-removal.

I suggest, to be 100% sure, you download and use (via a USB is good enough) the program Malwarebytes (the free version is extremely powerful, the "full" version only adds "24/7" protection if booted).

An other program that is handy to have in possession, and use in this case, is our old-school Hitman Pro, a really powerful "Second Opinion" program that is included in a lot of Rescue/boot discs (think of Hiren's Boot Disc as example).

If all those lights show green, I wouldn't worry too much about it, of course, whether or not a PC is infected is always a question, there are always chances you are infected with malware that escapes software, that's the reason why you should always scan/remove with more than one program!


The website's functionality is secure and does not allow arbitrary queries to be run against the database.
However, let's say someone gains unauthorized access to the username and password of the MySQL database (i.e. those used in the database URI).

Not sure if this is what you're implying, but it's not enough that the website's functionality has to be secure - the whole server running the MySQL database has to be secure as well. Your website can be as watertight as it likes, but, to take the extreme case, if the backend MySQL database is running on a publically accessible IP, and listening to requests globally, that username and password will then allow you to connect to it and run all the arbitrary queries you like.
Bypassing the above, other aspects such as password reusability, and assuming everything is "completely" secured and locked down, then yes, those credentials aren't of any specific use. Like pretty much every strategy in this domain, keeping them secret is to add a layer of security should vulnerabilities ever be found that would make those credentials useful.
In practice, locking those credentials down should be pretty easy. So if an attacker has got their hands on them in the first place, the implication is that your setup is definitely not secure, and there's likely a whole host of other vulnerabilities yet to be unearthed.


Standard (or solution) for securing files in a point-to-point integration

Assuming you've setup your SFTP server to use public key authentication only, you're pretty much safe with it.

It is always possible to add another layer of security, for instance, a VPN between your endpoints but, in your specific case, you're just exchanging the risks in one software for the same risk with another one: if your VPN software has a vulnerability or is missconfigured, there is usually no need to exploit the underlying SFTP software to gain access to the system. You're still getting something if the VPN stack runs as a limited (and different) user but that is not typically the case.

In other words, the solution you're asking for (an additional encryption layer) does not provide protection against the proposed threat model (misconfiguration or software vulnerability). In such a case, the best practice is to go for the simpler model since additional complexity is usually more expensive to deploy and maintain and it also increases the attack surface.


How does the authentication in the new UK £1 coin work?

They are using a system called ISIS which also has some more details available here.  It appears to be a form of micro-tagging embedded within the currency itself (based on the comment the same technology has been used in fuels and perfumes).

Basically, a specially manufactured particle is constructed and then mixed as an additive with the coin.  This additive can later be detected automatically.  Since the composition of the additive is unknown, it can't be reproduced easily but yet machines can read the signature of it.

The tagging technology can be used to tag specific coins (this is done for some high end unique items that are tagged), but it would generally be very expensive to do so.  It is far more likely that a standard formulation is used for all coins of a given value.  It would also still very likely require that the coin be directly handled to read as it is not a radio based technology.


Can attacker break out of apparmor jail with the following profile?

Of course. Your profile (And NO apparmor profile) does nothing to limit kernel attack surface. An attacker can exploit the kernel, unhook apparmor, and be out.

  only few directories / files for read / write / flock access, and network
  socket.

Notice that  ? That's adding hundreds more files to your profile. While your profile may look quite tight, it is in fact allowing quite a lot of access.

That said, no massive issues stick out. No UX, no write access to really critical stuff. Those capabilities suck though - you sure they're necessary? Probably are.


Where to find current, live botnet executable clients

Maybe try asking your local countries cybercrime department of the police?

I have no idea if they would answer a question like that but you might be doing useful research that they can use as well, so try to explain the mutual benefit of information sharing!


Compare approaches to match a private key and certificate

Well, yes.  There is a difference between the approaches.

The approach described in Determine if private key belongs to certificate? uses the RSA cryptosystem, which is based on the factorization of large prime numbers and an information trapdoor using the modulus function.  Yet, the same general approach may be used to orther public key cryptosystems (any scheme that has a difficult mathematical problem plus a trapdoor function can be a public key cryptosystem, e.g. you have the ElGamal scheme).

The solution proposed by sslhopper is limited to the RSA scheme (or any other scheme that uses the modulus function as the information trapdoor).  If you look in the openssl manuals the -modulus option only exists in man rsa.

In summary, the first approach is more generic than the second.  This is because any asymmetric encryption scheme must be capable of generating the public key from the private key, but not every scheme must use the modulus function as the information trapdoor.


How can we secure communication of an unchangeable app (Zoom)?

You cannot magically secure applications like Zoom without changing the application and the infrastructure it relies on.

The missing end-to-end encryption you want to have fixed is due to the basic architecture of Zoom, in which media streams are processed and mixed together on a central server (which is owned by Zoom). Only this architecture actually allows it to perform well without stressing bandwidth and CPU of endpoints when many users are involved. With E2E instead the requirements for CPU and bandwidth at each end would grow linearly with the number of users and thus would quickly overwhelm clients.

These kind of restrictions apply to any video conferencing solution. This means that you will not get real E2E with any other solution too, at least not if you want conferences which scale to many users without having excessive requirements regarding bandwidth and CPU power. The best you can get is that you control the central mixing and forwarding server yourself and thus don't need to trust a third party.

Even the broken AES ECB mode could not be fixed without changing application and infrastructure since the server actually expects the encryption to be a specific way and if you change it the communication will fail.

Usage of a VPN would not magically solve the problem. The data would still need to be processed on the servers owned by Zoom.


Can an attacker discover email addresses without gaining server access?

If you've used those email addresses anywhere, particularly on any public access forum, they were likely swept up.

If they were part of any of the multitude of public breaches that have taken place over the years, they were probably swept up.

If they were in friends or family address books and used in "CC" blasts to many places, they were probably swept up.

If they are part of a reasonable guessing algorithm pattern, they may have been generated by spammers.

In general there's no email discovery method, but keep in mind that until that last couple of years, due primarily to Google efforts, federated mail server to mail server connections were generally not encrypted. This allowed content sweeps from anywhere in the path. Due to efforts by Google, about 90% now use encrypted federated connections.

There likely is no threat or concern as long as you don't respond to the emails, either intentionally or unintentionally.


How to recover/log attempted passwords from a failed login

That would be incredibly simple. You could also log the attempted password value. Modify your login function somehow, depending on your language.

Keep in mind, this is untested pseudo code, but the concept will work:

Couple of security things:

private boolean properLength(String u, String p)
{
     return ((u.length > 3 && u.length <= 12) && (p.length > 8 && p.length <= 30)) ? true : false;
}

private boolean properFormat(String u, String p)
{
    return (regex.Valid(u, usernameRegex) && regex.Valid(p, passwordRegex)) ? true : false;
}

private String stripBadStuff(String stuff)
{
    // Just in case or something...
    return EncodingFunction.ToASCII(stuff).regexReplace(badCharacaterRegex, "");
}

And the login:

public String login(String user, String pass)
{
   if (!loginTriesExceeded) // Currently unhandled for example.
   {
       if ((user != null && pass != null) && properLength(user, pass) && properFormat(user, pass))
       {
            if (!userLoginTriesExceeded)
            {
                // Strips potential hacker injection attempts. You may want to find another way to log this attempt. You wouldn't want to log this to a database without parameters/bound variables. That's beyond the scope of this answer. Google it.
                String newUser = stripBadStuff(user);
                String newPass = stripBadStuff(pass);

               // Would be changing DB.lookup() to return true if valid login is detected. DB.lookup(newUser,newPass) will now be assumed that it tests the plaintext password against the salted hash.
                if (DB.lookup(newUser, newPass))
                {
                    // Prevent injection. This will assume DB.lookup() tests the password against the stored hash.
                    return "Hello " + newUser;
                }
                else
                {
                    logInvalidAttempt(newUser, newPass);
                    return "Invalid login.";
                }
           }
           else
           {
                return "User login attempts exceeded.";
           }
        }
        else
        {
            return "Invalid login.";
        }
    }
    else
    {
        // Do nothing, or inform the visitor that they've exceeded max global logins based on their IP / cookie
        return null;
    }
}

You would just use logInvalidAttempt(user, pass); when it fails. So instead of just saying, "login failed," you'd say "login failed" and log the attempt, but be careful not to implement any security flaws with this. You will have to ensure that the data is correctly input.

In general, just sanitizing input is not the answer, but I sometimes add it as an additional layer after everything else has finished, just in case. Not always, just sometimes. The example here is for learning purposes.

Keep in mind that you'll have to write your own logInvalidAttempt() function; that is too broad for this answer.

You can also do this for any Content Management System such as joomla, WordPress, Drupal, Django, et al. They are, after all, open source. So all you need to do is modify the appropriate login function.

You need to also make sure not too much data gets logged. You'll have to cut it off at some point.

TLDR:

Modify login() function.
When the user tries to log in using invalid credentials, log it somewhere.

If logging to a SQL Server database, parameterize your queries.
If logging to an Oracle database, bind your variables and use prepared statements.
If logging to a MySQL database, use prepared statements and bind your parameters.
If logging it to a file, or to any database, don't allow it to insert too much data. You gotta cut it off at some point.

Read logs/database.


Is connection established with two way SSL as secure as SSH?

Unless you have a specific threat model, they both provide equally secure cryptography. There are some differences in how they are used and what threats apply to them, such as TLS typically using the web PKI (Public Key Infrastructure) for authentication whereas SSH relies on TOFU (Trust-On-First-Use). The former trusts Certificate Authorities, whereas the latter relies on at an initial connection that is not compromised. So yes, TLS can be just as secure as SSH.


What cryptographic protocol is appropriate for the case where user needs access to a binary and encrypted configuration files?

If you store a key, password, etc. in the source code you will never be able to reasonably expect to keep it secret unless you also control the system. What you are describing would only be obscurity, obfuscation, or data hiding.

If you want only the program to be able to decrypt, its sounds like a case for using asymmetric cryptography. You may have a scenario where you encrypt the actual data using a symmetric key, but transfer the symmetric key using asymmetric to reduce overhead.

Depending upon your scenario, you could implement an Hardware Security Module (HSM). If you can setup and control the system, the HSM would be the trusted source to hold your secrets and protect the decryption process from the system and application. However, if you do not have physical control then the customer could possibly tamper with the HSM.

If the decryption keys are in the app or stored at the system, and the system is not under your control - the person who controls the system can always access them somehow, you can make it difficult, but not impossible. If you have complete control of the system, you can limit the user privileges to prevent them from loading tools or even reading the files to some degree. However, with a compiled desktop application being shipped to a customer, you will never be able to ensure they can't reverse or find the secrets.


I would suggest that rather than trying to protect the camera from the outside world with a firewall that using a black hole router as the only gateway for these devices would be more restrictive - also if you have a physical device at the router's address then it would make monitoring of egress attempts more visible. Also, point the device to the same black hole for DNS queries.

If you need remote access then use a VPN with NAT.


Is this hybrid (cookie, jwt) authentication method for web applications known and practical?

Refresh tokens
This is quite similar to the refresh token pattern. In it, you have two JWTs - one short lived for ordinary requests, and one long lived for renewing the short lived one. The short lived can not be revoked, but the long lived can. This is a pattern that is commonly used, giving a good trade off between revocability and performance.
Your approach is different in that the long lived token has been switched for a cookie. Let's think some about the benefits and drawbacks of that.
CSRF
If you check that the expired token is valid before you issue a new one based on the cookie, it should technically protect you from CSRF. A CSRF attacker could not create a token, and hence not make a succesfull attack.
Still, I feel a bit uneasy about this. First, you must make a special JWT check that accepts expired tokens. That's a bit messy with room for implementation mistakes. Second, expired tokens suddenly become sensitive data. That doesn't feel so good.
XSS
You could mark the cookie as HTTP only, hence limiting the power of an XSS attack somewhat. This seems to be what motivates your scheme?
I would say this is not worth much, though. The attacker could do a lot with just the token for a few minutes. If more time is needed, just run some JS on the client constantly refreshing tokens, sending new ones to the attacker. Or just run whatever requests you want to run from the client.
Basically, if you have an XSS vulnerability it's game over. You can't really limit the impact of that with a scheme like this. You might stop a script kiddie, but not more than that.
Conclusion
I can't find an exploitable fault with your scheme, so I wouldn't label it "unsecure". But I can't really see a big benefit either. But maybe I am missing something.
What you do create, though, is more complexity. You create new patterns, new things to implement, and you mix different sort of solutions (cookies, tokens) together. It's not very clean, for a lack of a better word.
So for that reason I would go with something more standard instead, like refresh tokens.


Is accepting the current and the previous one-time password a bad practice?

If by previous you mean an OTP that predates one the user already authenticated with then yes, this is considered bad practice. The OTP is meant to be used once, hence the name. The whole point of 2FA is that it represents the "something you have" in the security trinity. Allowing a token to be used twice defeats the purpose of what OTPs are meant to prevent. Turning it into "something you know" which makes it just a second password.

This problem usually doesn't present itself as a brute force issue. For example in the case of TOTP where the time windows are relatively short, brute forcing isn't really used to circumvent it. The use case as an attacker for a site that allows OTPs to be reused, either current or past is interception.

If the client uses the OTP and it is somehow intercepted, the attacker now reduces the problem to username password. Which, if they're intercepting information is likely also listening for these.

In the case of HOTP the problem is even worse, because theoretically the counter or moving factor does not increment very often. Meaning the last or even previous OTP the user authenticated with will likely be valid for a long time. In some cases months depending on the implementation of the server.

If by previous you mean the OTP on or before the current one being generated but not yet used, then no, within limits. Standard implementations of OTPs apply a "window" to overcome sync issues usually. In the case of TOTP, a 5 second window is employed (both forwards and backward) but this, in any implementations that I have seen, always disallows any OTP that is on or before the last one the user authenticated with. If we take the case of a 15s moving step with a 15s window there would be three OTPs that can be used to authenticate over a 45s timeframe, one in the past, one now and one in the future (this assumes the interval is the same as the moving step). The reasoning behind this is elegantly explained in @cornelinux's answer.

For HOTP the window is a "look ahead" window. The last OTP the user authenticated with was allowed if it was within the next 10 OTPs of the previous one accepted, and then the implementation calculates the next 10 from that one for the check against the next OTP entered. It has the considerable good sense to disregard any of the OTPs not used in the window before the one used successfully.

Note:

In HOTP 10 is arbitrary. Usually the factor is about 2.5 times the number of OTPs required to authenticate successfully. So if the user needs 3 HOTPs to authenticate the window will be about 8 OTPs after the current one.

In TOTP 5 seconds is also variable. In some cases I've seen windows as large as 100% of the moving step. So with a 30s step and a window of 30s effectively makes a code valid for 1:30. Again, expanding both before and after the current iteration.


Lock down OS to specific hardware device

Here's a simple solution

On first boot, require authentication from the server. Have a Username which is stored on the device. The server provides a password associated with that username.
On later verification, send that password to the server.
The server sends back a new password which is stored. The client acknowledges receipt of the new password.
On later verification send the new password. If it doesn't work, tries the last known working password.
The server verifies the password is 'latest one that was acknowledged'.

a) If it matches, the server proceeds at step 3. (new password for rotation)

b) Otherwise, this is a copy, that is out of sync with the other instances of your device.

The client would have limited time use of these copies until the Server-verification catches the fraud. The client would have to make further modifications of you image to bypass this protection.

Hopefully someone else here knows how to check some hardware of your ARM device for a serial number, as that would provide a more immediate failure without waiting for an internet connection.

As you admit in your original post, these protections could be altered or removed by editing the contents of the SSD before duplicating.

The best solution would be to move a portion of the functionality to the cloud, so that an internet connection is required for operation instead of simply verification. Of course this is not always a possibility.

There may be specialized hardware out there which I am not familiar with which is

a) Difficult or impossible to copy.

b) Verifies the contents of the booting operating system

c) If OK, passes a decryption key needed to decrypt the application code before it can run.

There may be specialized hardware (again, not familiar with any) that takes this approach instead: Stores the encryption key in a self-destructable storage, so that when the frame of your device is opened, then the device will no longer be able to boot.

Also the device should be powered off at the same time to start the process of making the Memory irrecoverable.

If you are interested in any of these specialized hardware options then you should post a second question with specifics and maybe someone here will know if they exists and what they are called.

Edit: Many Android devices have something called Trusted Execution Environment (TEE) and/or Secure Element (SE) which may be helpful search terms in the category of specialized hardware. See Android Keystore System.


You are focused on the person existing and not the account. Consider that Eve exists, did not send the email, but someone with access to her account did, and has entered an email rule to prevent your emails from hitting the inbox. You could carry on a conversation with that account but not Eve herself.
So I would add:

Account exists, email was sent from the account, but Eve did not send the email (compromised account)
Account exists, email was sent from the account, but Eve does not exist (dummy account)

In both cases, if you reply, you could be replying with the malicious actor and not Eve.
The best response is to contact Eve through some means other than email (call, other contact info, etc.)


Chrome torn down the TLS connection after received server ChangeCipherSpec

Your sequence is weird. When the client sends the ClientHello, then the server will respond with a ServerHello, and then:

either the client and server reuse an existing session, and do the "abbreviated handshake", in which case the server sends its ChangeCipherSpec and then a Finished message;
or the client and server do not reuse an existing session, in which case the server must send its Certificate message and a ServerHelloDone, in which case the client will send a ClientKeyExchange, then a ChangeCipherSpec and a Finished message.

See this answer for a description of the SSL handshakes.

In any case, if you observe a Certificate message from the server, then this is not an abbreviated handshake, and there should be at least a ServerHelloDone from the server, and a ClientKeyExchange from the client. The logical conclusion would be that your network capture tool does not see all the traffic. Therefore, it may miss the "application data" records that you expect.


Is this parameter vulnerable to SQL Injection?

No, the error does not indicate SQL injection.

  String or binary data would be truncated.

This means that the data you try to insert is too big for the column. If the column is of type CHAR(10), you can store 10 bytes in it. If you try to store 20 bytes in it, you get this error. This can happen even if the data is correctly handled and the page is not vulnerable to SQL injection.


Limiting access to data in a web application from IPs outside the network

This is the job of a host-based firewall. While IP based rules are so integral to the system that the built~in GNU/Linux Firewall is named Iptables and the basic slement of a firewall is a list of rules (called a chain) that could easily handle whatever packets of the type you describe that aren't handled back at the hardware router/firewall ip layer, I have to wonder if someone who has so little knowledge of computer security that I have to tell him this is up to the task. Security IS HARD. It requires a lot of skill and very up-to-date knowledge.

You really have two choices. You can contract this out to someone who is an expert in secure firewalls to script rules for you, or you can try to figure it out yourself. I warn you modern computer security on a network is no trivial task. Along with my direst warning against putting people's personal information at risk through insecure network exposure, I offer you a link to the basics of iptables and a book recommendation. Good luck!

http://www.tecmint.com/basic-guide-on-iptables-linux-firewall-tips-commands/

Prentice Hall Unix and Linux System Administration Handbook - Homepage I especially recommend you read Section Two - Networking and focus on Chapters 14-17 and 22. This will just give you an overview, not miraculously make you an expert.


How are HSMs used in payment processing on the server?

@thomas-pornin and @PwdRsch have explained what an HSM can do, but you've clarified that you want to know what they're used for in payment processing.  The short version is - they are used to strengthen the encryption protections that processors use.

Let's assume you mean credit card processors.  The PCI HSM Security Requirements suggests a number of places HSM would be applicable:

PIN Processing
3-D Secure
Card Verification
Card Production and Personalization
EFTPOS
ATM Interchange
Cash Card Reloading
Data Integrity
Chip Card Transaction Processing

Some simple uses can be inferred by the PCI Data Security Standard requirements, which credit card processors must be compliant with.  DSS 2.0 Requirement 4 says that the processor must

  use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks.

So, DSS says web servers need HTTPS.  An HSM can store the private key to make that setup more secure.  IPSec might be a way to meet Requirement 4; it can also benefit from HSM.

DSS Requirement 3.4 says that

  Render PAN unreadable anywhere it is stored... [such as with] Strong cryptography with associated key-management processes and procedures

So, for example, credit card numbers stored to a database must be encrypted.  An HSM can be used to support database encryption.

Payment processors need encryption.  HSMs make encryption... better.


svchost.exe has strange outbound tcp connections

I had the same issue after installing Comodo firewall; svchost.exe was establishing multiple outbound connections to the internet.

I tried to block the process, but since it's a system process, I ended up losing the internet.

The solution was to allow UDP and block TCP for the svchost process.

P.S. running Windows 10 64bit


Is there any risk of login information being compromised after submitting a Firefox crash report?

It is very unlikely that you gave away compromising information. Your active logins, cookies, search history and the content of your visited websites are safe. Presumably, the most relevant sensitive information in your case is the last visited URL (which you had to explicitly agree to submit).

Also note that Firefox doesn't submit crash reports without your consent. In the Mozilla docs you can find details on how the Mozilla Crash Reporter works and how you can understand crash reports.

What does a crash report contain?

A Firefox crash report contains information relevant for debugging such as:

Browser version
Installed extensions
Operating system version and  configuration
Stack trace of the crash (involved modules, functions, etc.)

You can optionally include the URL of where the crash has occurred and a contact email address.

Where can I view my previous crash reports?

You can view your crashes from inside Firefox at about:crashes or locally at ~/.mozilla/firefox/Crash Reports/. All submitted Firefox crash reports are published on crash-stats.

Who else can view a crash report?

Everyone is able to view a basic version of your report but only few users can see sensitive details.

  Some fields, such as "URL" and "Email Address", are privacy-sensitive and are only visible to users with minidump access.

(Source)

So even if you submitted the URL - it's not public, developers will probably never read it given the total amount of crash reports, and nobody will know it was you.


SSL/TLS: Policy Constraints vs. Basic Constraints

First, let's tackle "Basic Constraints" (RFC 5280, Section 4.2.1.9).  These are mostly for the sake of certificates issued for CAs.  RFC 5280 only defines two such "constraints":

Are you (the subject of this certificate) a CA, yes or no?

This one is pretty straightforward.  A CA certificate, by definition, must have a basic constraints extension with this cA boolean value set to "true" in order to be a CA.

Assuming you are a CA, how long of path of certificates can you issue?

This is the pathLenConstraint value, which is a number whose value is zero or greater.  Let's say I wanted to issue to you a CA certificate using my CA certificate, but I wanted to make sure you in turn could not use that CA certificate to issue other CA certificates.  I would add the basic constraints extension to your CA certificate, with the cA value of "true" and the pathLenConstraint value of "0".  pathLenConstraint is the number of "non-self-issued intermediate certificates" that could follow from your CA.  Note that the end certificate (usually a server or client certificate) does not count as part of this number.  So by using a pathLenConstraint of "0" in the CA certificate I issue to you, you can use that certificate to issue other end certificates, but not any intermediate certificates.  If no pathLenConstraint value is defined in the basic constraints extension, then no such limit is imposed.

Now, let's look at "Policy Constraints" (RFC 5280, Section 4.2.1.11).  The policy constraints extension, per RFC 5280, is for certificates that are issued to CAs; this extension is thus not really useful for end certificates (e.g. client/server certificates).  The RFC says that this extension is for constraining path validation to the CA in terms of "policies"; what then are these policies?

Understanding this requires that we look at Certificate Policies, and Policy Mappings.  A "certificate policy" is a fancy way of saying "I, as the CA organization, have some specific policy/terms; it is identified by this OID".  Thus each certificate policy has an OID, and usually some URI that points to more information about that policy.  RFC 5280 defines a "Certification Practice Statement" (CPS) certificate policy, for example, which contains a URI to the processing requirements of the CA (e.g. what their requirements are for getting a certificate issued by them).  I think of them as pointers to the terms of use/end user license agreement types of legalese.

Now, each different CA organization will have slightly (to wildly) different policies, but folks will ask a CA "how do your policy X relate to that other CA's policy Y?"  Especially when it comes to X509 cross signing (see RFC 4158 for gory details).  Thus there is the need for a CA certificate to be able to say "my certificate policy X is equivalent to that certificate policy Y"; this is done using the policy mapping extension, which "maps" the OID of certificate policy X to the OID of certificate policy Y.

Now we have certificate policies, and we have mappings from one certificate policy to another.  The policy constraints extension, then, uses these to set limits/requirements, in terms of policies (and mappings of policies), when walking the list of certificates, from end certificate through the intermediate CAs to the root/trusted CA.  One of the limits, inhibitPolicyMappings, says "ignore any policy mappings after the Nth intermediate certificate in the path"; the other, requireExplicitPolicy, says "if there are more than N intermediate certificates in that path, require that all of them have X policy".

So, to sum up: basic constraints determine if you are a CA (cA = true), and if so, how long of a trust path can you create (limited by pathLenConstraint).  Policy constraints are all about how walking that trust path happens: how many of the intermediates certificates are allowed to have policy mappings, after which the policy mappings of intermediate certificates are ignored (inhibitPolicyMapping = ...), and/or how long can the trust path be, before a specific policy is required (requireExplicitPolicy = ...).

Back to that CA certificate I issued to you, whose pathLenConstraint basic constraint was set to zero.  That would prohibit you from issuing your own intermediate certificates.  And in that case, placing any policy constraints in that CA certificate would be rather useless, as policy constraints modify the handling of intermediate certificates (which you would be unable to issue/create).  Likewise, policy constraints on a non-CA certificate (and end certificate for a client/server) would be useless, for the same reason: they cannot issue/create intermediate certificates.

Now the above is all of the theory; for more information on the actual reality of all of this, in terms of implementations and such, I can highly recommend Peter Gutmann's materials on PKI, such as his X509 Style Guide.

Hope this helps!


Yes, this is entirely possible. What you need is to define the proper configuration setting in ssl.conf file for your Apache web server.

An example of which is:

  CustomLog logs/access_log \
          "%{%Y-%m-%d %H:%M}t %{Host}i %{User-Agent}i %{SSL_PROTOCOL}x %{SSL_CIPHER}x"

where the parameter %{SSL_CIPHER}x displays the cipher that is being used.

A sample output would be something like this:

2015-07-10 23:39 localhost Mozilla/5.0 (some bot) TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384

More information could be found on the documentation:
http://httpd.apache.org/docs/current/mod/mod_log_config.html#customlog


Is it possible to make a web page that contains a Python script?

You cannot execute Python from a browser, browsers don't understand Python. What's more, the browser is deliberately restricted to what it can do on your local machine.

It might be possible to write a browser addin that allowed execution of Python. This is why it is important to think carefully about the addins/extensions you allow.

JavaScript is the language of the web and your browser will execute that. But still it is heavily restricted as to what it can do. All modern browsers run in a sandbox that attempts to ensure that any code that it might execute stays in a specific context. Normally, if you load a script from a web site, that script will only execute in that context and only have access to that site plus some local storage associated with that site. You could not, for example, create some JavaScript that deleted files on the C: drive and have that loaded from a server.


https://www.truecrypt.org forwards to http://www.truecrypt.org

The reason for this behavior is simply a poorly-run website. Today there's no logical reason to not serve a site over HTTPS, though that hasn't been true forever. Currently the only files I could find that are served over HTTPS are the PGP signatures. Though, critically, the page that links to those signatures is not served over HTTPS, which somewhat defeats the purpose.

It has been mentioned more than once that there is significant incentive for an attacker to MITM the truecrypt website and serve a modified version of their software, along with correspondingly updated PGP signatures and keys. And also the refusal of the truecrypt team to serve their website over SSL makes such an attack trivial for a correctly-positioned attacker.

So far, the truecrypt team hasn't cared.


In general if you use https, then the content of the websites you are surfing should not be visible to the company, as the connection between your device and the webserver is encrypted. However they can see, which websites you visited via the DNS queries which happen to be transmitted without any encryption. The same appeals to your phone: As WhatsApp uses end to end encryption they can not see, what content or what messages you get, but very likely they can recognize, that you are connected to the WhatsApp servers.

If you send your passwords only in https connections they won't see those too.

The tethering of your phone should be undetected too: Imagine your phone as a router, from the outside one can only see your router or in this case your phone, but behind that 'router' you can still have a ton of devices. This is because of a technology called NAT.
But this only works if the communication between the laptop and the webserver is encrypted. Otherwise they might be able to identity your laptop via the user agent in the http protocol.

Short summary:
The websites you are visiting can be monitored.
If you use only encrypted connections like https the content won't be monitored.
As WhatsApp is end to end encrypted, they neither can see the messages nor the files which you receive, but they will probably detect, that you are using WhatsApp.

EDIT: As @schroeder and @Steffen Ullrich pointed out:
All of this above does not apply if you trust your companies certificate authority. If you do so, they will be able to read all the content of the packets. This includes the websites you visit and your login credentials. They can see exact the same websites you are visiting.

But at your laptop you are able to decide, which CA's you trust. Furthermore you can see this for example in Firefox if you click the green lock > more informations > Signed by and check wether the signing entity is not your company and if it is a entity you trust.


What you need is relatively simple: you need to ensure that your students' unprivileged accounts are well confined. If you don't have a graphical environment involved, your situation is relatively simple. You should start by implementing the following actions:

ensure users are created without administrative privileges (no sudo, no admin or wheel group)
ensure users are unable to emulate a login screen to spoof your login screen (a classic for university, which I've seen happen)
ensure proper polkitd policy which prevents users from suspending/shutting down the host
ensure you don't run vulnerable/outdated suid/sgid services on the host (see how to list them)
ensure no individual user can deplete the resources of the system (by configuring Systemd.cgroup to impose resource usage limits on the entire session of each user)
strengthen your mandatory access control by installing and configuring properly SELinux (to limit students to a student role where they can only write in their home and in /tmp)
expire accounts when necessary to avoid lingering accounts with eventually compromised passwords (see this question on the Unix site)
you can even run students' sessions in separate containers using Systemd.nspawn which is designed to run fully working systems independently from one another, using Linux namespaces. This is the proper way to jail a session, not chroot

You might then notice that students use the machines for other purposes than those allowed. You can limit access to machines to specific times using pam_time though that might get in the way of students getting their work done and should be balanced against the benefits it provides. Also, make sure that your network administrators know what traffic to expect on this host so they can detect undesirable traffic.

All of this being said, I don't see the point in white-listing specific binaries (useless since students can compile and run their own code) as it may get in the way of students using legitimate development tools, e.g. alternative compilers, building toolchains, code analysis tools, code versioning tools, etc.

As long as users can only harm themselves and you've got strong guarantees of that, the job is done. This isn't exactly a long-term production system anyway, students are only using it to fool around with educational code.


Why does HTTP Basic authentication encode the username and password with base64?

It is not done for security reasons at all, and more as a means of escaping special characters

https://stackoverflow.com/questions/4070693/why-base64-encryption

TLS would be employed for security.


Could server honesty be audited by remote peers without said peers having sole (or any) control of the server?

I can think of several methods, not necessarily independent:

Fully homomorphic encryption, the ability to securely compute on other machines without revealing the data, and possibly without revealing the program itself.

HElib, a FOSS project by IBM
Scarab a FOSS project, though impractical/slow, it is a good demonstration

Secure function evaluation, see External links section of article on secure multi-party computation  for possible implementations

Secure Function Evaluation; incidentally hcrypt also has a SFE project, but there are

SNARK/s, (Succint Non-interactive Argument of Knowledge), the ability to turn a program into a proof, and obtain a succinct that the program ran. Here the input isn't provided by you, necessarily, but the twist is, the input can be provided by the computer running the program, and not revealing that input to you. This is a bit different, but for this application, this detail doesn't matter. The program can be verified that it ran fully.

SCIP (Succinct Computational Integrity and Privacy) is an effort to make this practical. They have designed a virtual architecture called TinyRam, for creating and verifying the program/trace/proof, and are working on a C-compiler to the architecture (see SNARKs for C : Verifying Program Executions Succinctly and in Zero Knowledge (extended version) (PDF)).

See also:

Youtube talks:

Universal and affordable computational integrity - Bitcoin 2013 Conference by Eli Ben-Sasson
Eli Ben-Sasson -- Universal and Affordable Computational Integrity, or, Succinctly, from C to PCP

Answers to Using a proof-of-work system to discourage piracy or encourage donations: (1, 2)


Preventing Users from Using QR Code Password and Scanner for Authentication

This is not really a technical problem but a usability problem. If you have a password policy which requires unique and unguessable passwords and maybe regular changes then users need to find a way to somehow remember the current password. A typical way is to write this down and put under the keyboard or something like this. Using a QR code is just another incarnation of this pattern.

If you make it impossible to use a QR scanner then users will find other ways to remember the password which are likely not safer in any way. Instead you should provide ways so that users can actually both safely and easily handle authentication and don't need to work around broken password policies. Depending on your environment that might be biometric elements like fingerprint, physical elements like smartcards or tokens etc.


How does Cycript / Cydia Substrate hook into processes?

It figured out that is apparently working by adding the DYLD_INSERT_LIBRARIES into the program's launchd manifest and thereby every time the application is started it loads the malicious payload by loading the dynamic library.

Still, are there other techniques how to perform runtime hooking / manipulations on Android and iOS?


Prevent ARP spoofing with dynamic static entry on Linux

I did not analyse your script. However, it looks complex.

Why don't you use ARPtables? It's like IPtables, but for ARP.

Block ARP traffic from all machines (default: DENY)
arptables -P INPUT DROP

Allow router (fixed ARP)
arptables -A INPUT --source-mac d8:d7:21:22:5a:f4 -j ACCEPT

This way you will only exchange ARP packets with your router.

Source: http://linux-audit.com/filtering-arp-traffic-with-linux-arptables/