There are two distinct reasons why a disk encryption might fill the storage area with random data.

If you're encrypting in place, or more generally if there's a chance that the storage area contains plaintext data that you don't want to expose, then the existing data needs to be wiped, otherwise traces of old data may remain in space that hasn't been overwritten by encrypted data yet.

Wiping with zeroes is enough against all attacks that don't use specialized hardware such as an electron microscope. Wiping with zeroes is enough even against all published attacks with specialized hardware for most storage media. In the 1990s, Peter Gutmann demonstrated that data could be recovered to some extent after overwriting it with zeroes, due to magnetic remanence. The effect is rather small and each bit has an independent chance of not being recovered correctly, so it's difficult to recover data, but theoretically possible, leading to the recommendation of random overwrites.
In any case, the remanence effect is so small on contemporary hard disks that overwriting with zeroes is good enough.. For EEPROM, but not other flash technologies, I've seen recommendations to overwrite with multiple passes of random data. For NAND or NOR flash, overwriting with zeroes is good enough.

To put it simply, overwriting with random data instead of zeroes is useless paranoia in almost all cases where it's used.

There's a different reason to fill the disk space with random data, which is if you consider the size of the encrypted data to be confidential. Encrypted data is indistinguishable from random data if you don't have the key. Therefore, in a disk filled with random-looking data, it's impossible to tell which bits are random and which are encrypted. This is only a very small privacy concern since revealing how much disk space is free is rarely a concern.

If you want to start storing data before wiping, it's more complicated: the wiping tool and the disk encryption tool have to know which area they can use and which area is the domain of the other guy. Also, if you were relying on the free space being wiped or randomized, then your disk does not meet your security requirements until the free space has been properly disposed, so you shouldn't be using it.

In summary, overwriting with random data is rarely useful. But if you do want it, you need to wait until it's done.


Are new AMD processors more secure than Intel ones?

They are both about equally terrible and still highly vulnerable to Spectre.

Unfortunately, you would have to have access to confidential design documents in order to even begin answering this question. From (quasi-privileged) anecdotal evidence, AMD used to be really bad with setting lock bits (MMIO/MSR defaults, if I recall correctly), whereas Intel puts a lot of effort into security. On the other hand, Intel has recently gotten rid of a lot of its security personnel and even outsourced the development of the ME to Israel  instead of doing it in-house (for MEv11, I think).

In terms of architecture, they are quite different internally. I can't say whether or not the deep internal architecture (e.g. Intel using ports to send data to execution units, AMD using pipes) is relevant to security, but their co-processors are quite different. Intel uses its Management Engine (now called the Converged Security and Management Engine, or CSME) which, while bad, is not nearly as bad as people make it out to be (it actually does not have direct memory accessnote, at least not by default, for various reasons, though it does have access to VGA and PS/2). The CSME was previously an ARCompact processor running ThreadX, but is now an i486/i586 hybrid (basically a little x86 core) running Minix. AMD on the other hand uses the PSP (Platform Security Processor), an ARM-based core which, if I recall, has absolute access to everything, including memory. Unlike the AMD PSP, the Intel CSME can be disabled, as people have recently discovered.

In the end, CPU security, and hardware security in general, is a new and emerging field. Both Intel and AMD are pretty equally vulnerable to all Spectre-class attacks (the gift that keeps on giving!), even if Intel is uniquely affected by Meltdown. I would say that, overall, both Intel and AMD are really, really insecure on an architectural level. ARM less so, and MIPS less so still. Of course, as we go to the more secure CPUs, we also come with lesser capabilities and performance. I personally go with Intel, mainly because there tends to be more research into Intel processors, so discoveries and leaked datasheets are far more likely to come from them than from AMD. That doesn't mean I consider Intel to be more secure. x86 security in general? Hic sunt dracones.


PGP: Can I just upload my public part of encryption sub key to PGP server?

The best practices are to keep your primary private key offline. Your public key is required to be available, as all subkeys, user IDs (and thus certifications) are bound to it.

As you do not upload private keys to key servers anyway, you do not have to care about offline keys at all. You have to upload the primary public key, but could choose from the subkeys (depending on which you want to be available).


Why use one-time codes for two-factor authentication backups?

Compared with something like SMS or email OTPs, I don't think there's as strong a case to make these one-time-use, but the same arguments still apply.

Let's assume that I have the codes printed out on paper. Then during the recovery process, the recovery code passes through all of the following nodes:

Plaintext: My computer's keyboard, OS, browser
ENCRYPTED BY HTTPS: browser --> server's TLS endpoint (for ex. CloudFront)
Plaintext: TLS endpoint --> networking equipment --> application server
Plaintext: Application server <--> db <--> other internal compenents.

The point is that even with HTTPS, there are a lot of nodes that will have your code in memory (or maybe in logs) as part of the recovery process. If the code is multi-use, then you have to trust that every single one of those nodes is honest and not infected with malware. If the code is one-time-use, then once it's been used, you don't care if it ends up in logs or whatever.

It's not a rock-solid argument, but it's the best I can come up with.


Risks of using UUID to identify user in mobile app

The primary risk is later exposure of the link if the original message is leaked.

A similar strategy of using a unique token is pretty standard for forgotten password resets or pregenerated accounts on websites, with the following caveats:

the token is not guessable (a securely generated UUID should be fine
here)
the uuid/link is one (successful) use only
the uuid/link
expires after some amount of time (the exact duration is tradeoff between user convenience and potential exposure)

See https://www.troyhunt.com/everything-you-ever-wanted-to-know/ for more details of password reset strategies.

For your approach, once the app is downloaded you would then need to generate a second key for future access and store it locally. It would mean that you need to re-issue the link with a new UUID ocassionally if a user gets a new phone or forgot to use it the first time.

Rather than an app, I'd suggest that you do a website with un/pw and then just precreate accounts and send out signup links with a UUID to each user (i.e they set UN/PW on first access). That way you can have one (hopefully easy to remember) domain and website that is easy to access. It also means that the signup links cannot be reused later and can be expired.


According to the Microsoft whitepaper and a few other MSDN blog sources, the following specs are defined:

Key derivation is performed using 50,000 iterations[source] of SHA-1 (increased to 100k in SP2).
Uses a 16-byte (128-bit) random salt.
AES is the block cipher used to encrypt the document.
By default, 128-bit key are used. There is a registry tweak to change this to 256-bit.
The AES block cipher is implemented in Microsoft's CSP / CryptoAPI.

Older versions of Office use RC4, which is now deprecated and not recommended.
In summary, I'd say yes, with a good password this is going to be difficult to crack.
Modern GPU hash cracking tools can reach around 3.2 billion hashes per second on a powerful graphics card. With the default options, the KDF used will reduce that to roughly 64k hashes per second.
Assuming ten characters (a-z, A-Z, 0-9) you're looking at a key space of 840,000,000,000,000,000 (8.4x10^17) possible passwords, so that's around 210 thousand years before you hit a 50% likelyhood of cracking the password.
If you're storing financial information, take a look at these registry tweaks for Office 2007 SP2 that allow you to alter some security parameters. For a decent increase in security, set the CipherKeyBits value to 256, and the PasswordSpinCount value to 1,000,000 or higher. At that point, I'd personally trust it to be reasonably safe against even determined attackers. If you're super-paranoid, you could always put the files in a TrueCrypt volume too!


How do you detect a Memcached DDoS attack on your server?

If you are the one being exploited to carry out the attack, you will see heavy traffic leaving your server from UDP port 11211 and a small amount of incoming traffic from the attacker's machine to said port (with the source IP spoofed to appear to be that of the target). However, it would be best for you simply to configure Memcached so it is not exposed to the internet. This can be done by editing its configuration file and binding it to localhost. If on the other hand you are the target, you will see a large amount of incoming traffic from many servers coming from UDP source port 11211.

If you use Snort, there is a detection rule available for it.


Am I missing any loopholes with my current session managment?

You will be vulnerable to a CSRF attack.

Since you want to be stateless, best option is to use double submit cookie variation. You need to be careful and not to do it naively, please see this question. In short, you will need to tie your CSRF token to a security session:

Generate sufficiently large CSRF token
Include CSRF token inside JWT as one of the claims
Provide CSRF to the client as a result of a successful authentication in a JSON object for example. You will provide cookie containing your JWT in the same step. Cookie can't be read from the client (httpOnly) thus the necessity to provide it in a JSON object or some other format.
On client side store CSRF token in sessionStorage or localStorage and send it to the server on each request that changes state as a header.
On server side validate the value from header and JWT

Your solution for revoking JWT is fine. Be sure to generate new id and issue new token when user changes password.

To minimize possible impact a stolen JWT can have on your application, keep expiration as short as your application can allow it to be.

You can implement a stateless JWT security using Spring Security and should avoid doing it in a REST controller and rolling your own custom implementation. See this as a good starting point. Even though it is for Spring Boot, it can easily be modified so it works with plain Spring.


What is the difference between "missing function level access control" and "privilege escalation"?

Privilege Escalation means that your rights have been elevated throughout the environment. In your scenario, your rights have not been changed. The problem is that everyone can see everyone's data. This scenario is a classic access control problem.


Creating a dummy account for account verification

It is possible that the goal is to compare your current ip when you create this dummy account with the one you use for your real account.

However, this system does not seem practical for a user. Normally a confirmation of the current password, a code or a link sent by email is enough.


how much traffic can a packet filtering firewall _ implemented with iptables _can handle?

Many companies use IPTables as the primary firewall for networks with thousands of hosts. Likewise many commercial firewall products are based on IPTables so yes this is not only acceptable but quite common.

You may need to be consider the bandwidth involved and the number of packets per second compared to the hardware you are using in extreme situations or have a very high-speed connection to the Internet but if your outgoing bandwidth is 20% less than the bandwidth of the ethernet card you are probably using it's unlikely to be an issue for most modern web or office traffic.

Using a modern distro that you feel comfortable administrating is probably the most important issue for distribution source. IPTables is not skewed heavily toward any given distro. A better question to ask here may be which distro is going to be easier for you to secure especially since you are using it as a firewall.

Consider if you need to create separate secured segments when architecting your firewall solution. It's easy to have multiple interfaces on an IPTables-based firewall and more isolation between infected desktops and servers can be really helpful.

Finally do consider using IPTables on all of your linux hosts. The concept of Zero Trust Firewalling, where each system is hardened and has it's own firewall rules tightly configured is much more secure than the traditional flat network design.

Don't rule out projects like PfSense https://pfsense.org/

I like to build mine from scratch but you may find a lot of features in a package like this helpful.

You may also want to look into projects like fail2ban and possibly mod_security. I could go into hundreds of other security projects but these might be a good starting point.


Edit: This is not relevant to this particular question, but an advice on the subject in general.

It sounds like what you really want is a proper authentication mechanism. You should not try to roll your own, as it is considered bad practice. One secure and reliable authentication mechanism is HTTP Digest Access Authentication, which is deeply anchored in the HTTP framework. It is a challenge response protocol, meaning that something along these lines happen, when a user tries navigating to the "upload files" mechanism:

User navigates to http://example.org/protected/upload.html
Server notices that the /protected/ directory or the upload.html file is protected by Digest Authentication and responds with a 401 Authorization required error code. In it is a challenge for the user agent (the web browser) to respond to. The answer is calculated using the challenge, the user's credentials (username and password) along with some other information.
User enters password, leading to the user agent providing the server with an Authorization header, containing the response to the challenge
The server, using the credentials he has stored on the user, calculates the same response value using the same data that he sent the user.
The server compares the received and the locally generated response value, and if they are equal, grant access to the protected realm

All this is done using MD5 hashing as a standard. The application and servers can be configured to use MD5, SHA-X or any hashing algorithm - even iterated hashing, as long as the same procedure is followed on each side of the communication.

MD5 is considered broken, in the sense that it is fairly easy to find collisions. This is not a problem for this authentication process, as it requires a form of a preimage attack to successfully collect the password. This is only possible theoretically with a computational complexity of 2123.4.

If you are intimidated by this, or the scheme does not fit what you really need, at least store your password in a salted, hashed way, i.e. the database contains:

username | hash_function(password+":"+salt) | salt

Here, SHA-256 should be alright.

Please ask for more details on HTTP Digest Auth. if interested.
Also, consider adding your type of server application (Apache?) to the question.


Running Apache as system service on Windows 2003 R2 64-bit

That the PHP engine runs as a user with some extensive privileges is not "insecure" by itself. It depends on the context. If some attacker can induce your Apache/PHP to run arbitrary commands of his own, then you already are in rather deep trouble: this is sufficient to access whatever data the site code uses, to alter the site so as to fool other site users, or to serve as relay for another attack on some other sites. Giving the attacker some more extensive access to the local machine adds insult to injury, but this is not the biggest issue in such a situation.

Running Apache/PHP as a less-privileged user is a good idea, of course -- but believing that this would achieve security is not. It is merely damage containment. It just prevents an attacker who has already taken over your site, to take over the physical machine as well (or, at least, to take it over too easily -- local privilege escalation holes are rather common anyway).


Yes, most exploits are platform dependent. There are details.

For instance, if an attacker targets Internet Explorer, then he targets Windows systems. Most Windows systems run on x86. Moreover, on Windows up to 7, the default IE is the 32-bit version, even if the OS is a 64-bit Windows. Also, at the assembly level, XP, Vista and 7 are very similar (indeed, they can run the same applications, so, from the point of view of the applications, things don't change much).

This means that a single exploit version (32-bit x86, for "Windows") will already work for a vast majority of cases. An industrious attacker will also think about a 64-bit version for Windows 8, or the (very few) users with a 64-bit pre-8 OS who run the 64-bit IE. A very industrious attacker will try to make an ARM version for the Surface RT.

All these platforms are little-endian. IE for other CPU has been dead for quite some time (I used the Sparc/Solaris version back in 2000 or so, but it was a 5.x version).

The important point is that attackers don't need to do much quality assurance. It is not a problem for the attacker if what he sends to a target would not work flawlessly on other machines that he is not presently targeting.


Pokki Sandbox architecture. Is it secure?

Pokki is secure the same way that chrome is.

A Pokki process is severely limited and thus no malicious software can infect your system from within a Pokki without breaking several security layers simultaneously (very unlikely).
There are no tests because the application itself doesn't have anything to do with the sandbox architecture except it runs ontop of it. I fit's a Pokku app then it's secure (in this way)

These security measures only stop malicious software from infecting your system.
It does not secure against anything else.

If you could be more specific about what you're trying to prevent, I could explain further.


how can you inject malicious code into an innocent-looking URL?

I wrote a blog a while back about a security flaw in iOS's Safari Mobile browser. Which pretty much allows you to mask a URL. The hole was fixed with iOS 5.2 I believe and the hole I know for a fact is no longer available in iOS 6.x. But in short people can find such security holes in certain types of web browsers, then use them to their advantage. In the case of iOS it was pretty much just a case of using some sloppy JavaScript with iframes. Like the following.

As you can see there are two URLs: http://www.apple.com and my blog. When viewed on certain mobile Apple devices you will see www.apple.com in the address bar, but see my blog's content instead of Apple's website.


When connecting to internet through VPN what precautions should be taken?

Connecting thorugh a VPN does not provide anonymity. It just provides a different IP address. Any way in which you could otherwise be traced you still be traced.

If you want your VPN-redirected traffic to not be at all associated with your non-VPN-redirected traffic, then your best solution is to keep completely separate profiles for each use. The most complete way to do so is with two separate computers; the second most complete way is by using a separate OS on the same computer (also not that bad), and the third way is to separate out the browsers (not ideal, but less friction).

And then, of course, never do anything within the one profile that you do with the other. No shared accounts, no shared logins, no shared usage patterns, no shared anything. Don't even visit the sames sites.

Often when people's anonymous personae are tracked down (e.g. by a repressive government, etc.) and tied to a real-world person, it's by discovering patters in behavior, speech, timing, or other such side-channel details, or one one persona makes some reference to the other, or by both sharing some common offline characteristic (like the sound of your voice if someone talks to you). The more a given identity does, the more difficult it becomes for that identity to remain secret. The only safety (if there is any at all) is in keeping the anonymous persona sparse and very rarely encountered. It's an extraordinarily dangerous line to tread, so do so with the utmost caution.

Also, and here's a technical detail you don't want to forget: If a "content of interest" is seen by the government coming form a specific IP address, and YOU are seen connecting to a VPN at that same address... well then your secret is not so secret. If your only protection is a VPN, then you're not particularly protected.


7-zip uses AES-256 for 7z archives, the strongest version of AES.

WinZip offers two kinds of encryption: AES encryption (It's good, but windows doesn't support it.) and weak Zip 2.0 (Legacy) encryption, which is the old method. Windows supports it. But that method provides low security level. Do not rely on Zip 2.0 encryption to provide strong data security.

Using WinZIP with AES defeats the initial .zip purpose, since Windows by itself will not be able to extract it.

When using AES WinZIP can use both 128-bit and 256-bit. If 128-bit is used, it's less secure, but a little faster.

It also slightly simpler to check passwords for zip, since many tools are focused on that compared to 7z. Basically, there is some software that can search passwords for zip, and it's more difficult to find such software for 7z-AES.

Standard .zip also has more code execution vulnerabilities compared to 7Z.

So the strongest format is 7Z, followed by ZIP-AES-256.

Conclusion: in the case of encrypted files, there is no sane reason to still use standard zip.


Would re-salting passwords regularly in-/decrease security?

Hash function collisions are not relevant to password hashing. All the password hashing works on preimage resistance, not collisions. You can forget everything about collisions when talking about password hashing.

Salt "collisions" may matter but are better called "salt reuse". You avoid salt reuse by using big enough random salts (16 bytes are enough; GUID are good salts).

You cannot change the salt without having access to the password. If you could do it, then the attacker could do it too, and nullify the benefits of the salts. This would be a serious weakness of the hashing function.

There is no point in changing the salt. The salt unique added value is how it is different from other salt values. There is no gain in replacing a salt value with another value; there can be a net loss if the new value happens to be equal to another salt value, leading to salt reuse.

Namely, when you use random salts, you are ensuring absence of salt reuse heuristically: if you ever generate s salts, in a space of size n (e.g. n = 2128 for random 16-byte salts), then risk of a salt reuse remains low as long as s2 is small with regards to n. Basically, with 16-byte salts, chosen randomly from a good PRNG, you have room for about 264 salt generation instances. If you change salts regularly, more often than strictly required, then you are increasing s, i.e. diminishing your breathing room. Fortunately, 264 is a huge number, so assuming that you do everything else properly, then replacing salts every week (when the user logs in, because you cannot do that without the password itself) will not imply a significant extra risk. It will be useless, but harmless.

If, from multiple hash values with various salts and the same password, the attacker can work out the password itself or reduce its key space (with better success than the simple risk of salt reuse explained above), then this is a cryptographic weakness of the password hashing function. No such weakness is known for usual password hashing functions (bcrypt, PBKDF2...).


How to prevent the device from connecting to the original AP?

DoS is tricky. To answer you, more data is needed... your chipset, that is very important.
I'll quote the well explained text from airgeddon's wiki. It will throw some light to you:

Not all attacks work against every APs and its clients. Sometimes, clients are taken down only partially, while others remain unaffected even on the same AP. It depends of many factors and variables: Chipset used to perform the attack, type of client (Android, computer, Apple device, etc), Access Point, distance and signal to the target, etc. The signal is of greater significance, which must be powerful enough. If you think it is not working, you should try a different mode of attack: mdk4, aireplay or even mdk3 modifying the configuration options ".airgeddonrc" file. More info about the available options on this link

The entire link is here:
https://github.com/v1s1t0r1sh3r3/airgeddon/wiki/FAQ%20&%20Troubleshooting#dos-deauth-is-not-working-what-can-i-do


Json Web Tokens. Headers naming conventions, formatting and security issues

There are a lot of unknowns here but here is my shot at answering based on general security best practices.

  Should I sign my reference token with RSA before I pass it to the
  client?

Signatures can be used for authenticity, integrity, and non-repudiation. In this case, integrity is the only one which seems to make sense. If this is required, you should definitely sign the token. It is required, if the token is self-describing, i.e. contains data which may be manipulated by the client (like a JWT). I wrote blog post on integrity. RSA may not be required. A simple HMAC may be enough for you. Your use case really determines if you need asymmetric crypto here.

  Should I sign my refresh token with RSA? Obviously, like reference
  token, it does not store any critical information and therefore I'm
  not sure of that.

See 1. Since you do not pass it to the client and it seems to be an opaque token. You can get away with not signing this.

  Should I sign my access token with RSA, if it is never passed to the client and is only used on server side? I guess, I should, just
  like in case of hashed passwords stored in database.

See 1. Not passing it to the client, make it impossible to be modified by the client. Integrity may still be required, it depends on your use case.

  What are naming conventions for HTTP header in which I pass my reference token from server to the client? Is it ok to use just some
  arbitrary header like X-Reference-Token?

Yes, it is fine. Since the scheme is custom, I do not think there is harm in using a custom header for a custom piece of token.

  In what header should I pass reference token from client to the server side? Should I use Authorization: Bearer ... (it seems like a
  standard convention) or is it ok to use just the same
  X-Reference-Token: ...

Authorization: Bearer is probably better here. However it seems in 6. that your are using cookies for the reference token, in which case there is no need for an extra header to send it.

  Is it secure (I guess, not) to pass refresh token to the client. And
  if not, how do they store it? Reference token is stored in client side
  cookies and passed with each request from client to the server, access
  token is never passed to the client and is stored in server side cache
  and where should I store my refresh token?

Your scheme is a black-box to me, but it seems like the access token never hits the client, therefore the refresh token should not either. In a regular auth mechanism like OAuth these two tokens require the same amount of security. Not counting the fact that refresh tokens live longer.

  Is it secure to use raw reference token value as a key, by which I get
  access token from server side cache? Let's say, my reference token is
  just some GUID, is it secure enough to use this very GUID as a key by
  which my access token is stored? Or is it more secure to get this key
  from GUID by some transformations?

Again your scheme is a black-box. It seems to me that your reference token is actually a session ID. In which case it should not be a GUID, but a random opaque token, as described here. It is fine to store the session ID as the key to get the access token from your cache.

Anything I described above is based on my very limited understanding of your scheme. Generally, you should not run your own authentication/authorization scheme. It seems to me you have a web application with session management using cookies and an OAuth to access some resources on the backend.

Take a look at OAuth, it may well simplify your life quite a bit.


The first thing I'd look at is, "Is my mail queue full of messages?"

Received: from localhost (localhost)
    by {DOMAIN.com} (8.12.11.20060614/8.12.11) id q0ANsViM026627;

Finding that at the top of your mail headers where your server says it came from localhost doesn't look good for you.

Mail headers showing the path history of a message are appended to the top of a message. If you happen to see a series of Received: lines, read them from the bottom up.

It's common to fake to / from, etc., but a Received line will always give up the last server IP talked to.


Can applying second cipher (including home brew) reduce security

From a mathematical point of view: when you cascade two encryption functions f and g in that order (you encrypt with f, then encrypt the output of f with g), then g cannot make the data less confidential than with f alone, provided that an important condition is fulfilled: the secret key used for g must be unrelated to the secret key used for f.

It is not that easy to make a formal and correct definition of what "unrelated" means here. Basically, suppose that f is applied by Alice, who then hands the encrypted data to Bob, who applies g; decryption would go in the reverse direction (Bob, then Alice). Alice knows the key for f, Bob knows the key for g. By definition, Bob only works on what Alice produced, and Alice uses a key that Bob does not know. Thus, regardless of who much incompetent Bob is, he cannot unravel the encryption done by Alice: if Bob could through using a really poor algorithm, then any attacker could do as well, and that would mean that Bob's incompetence would count as a break on f (the encryption performed by Alice).

This points out that the "unrelatedness" of the keys for f and g can be obtained by either generating both independently of each other, or by producing the two keys from a Key Derivation Function. For instance, there is a master key K, and you run it through a KDF to obtain 256 bits of output; the first 128 bits will be the key for f, the other 128 bits will be the key for g. If the KDF is secure as a KDF, then the two keys will be sufficiently "unrelated".

Using the same key for both algorithms ("AES" and "HomeBrew") could prove deadly. Deriving one key from the other could also be problematic, depending on how you derive them. Deriving both keys from the same source with a KDF that is sufficiently one-way ought to be safe.

The above is the "mathematical" answer. But cryptography does not happen in the ethereal world of mathematics. At one point, you run it on actual hardware. Even with "unrelated" keys, the combination HomeBrew(AES) can still be harmful in the following ways:

Software is secure only insofar as it is reviewed and reviewed again and fixed. This is a time-consuming process. By implementing two algorithms instead of one, you doubled the quantity of code to review, and thus, mechanically, halved the available workforce for the review of either algorithm.
Computing "HomeBrew" might be fast, but certainly not as much as not computing "HomeBrew". By cascading the two algorithms, you increased the computational cost of doing encryption. This may imply increased hardware costs, or higher latency, and possibly degraded user experience. If the user experience is too much degraded, then the user may want to actually skip the encryption step, and then security has been seriously harmed.
"HomeBrew" being, well, home-brewed, it is not compatible with anything else on Earth. When you use standardized algorithms, you may have the choice between several implementations. For instance, is using normal SSL/TLS, you can rely on the existing OpenSSL library, but if at some point you get fed up with the hole-of-the-month feature of OpenSSL, you can switch to another implementation like GnuTLS, which implements the same protocol -- you can do that on one side without impacting other systems, since they all run the same standard protocol. By using a home-brewed algorithm, you squander these advantages. You are now married with a single implementation and must stick with it until the End of Times.
If you use AES(HomeBrew) instead of HomeBrew(AES), you get all the disadvantages above, and you get a brand new one as well, which is that "HomeBrew" now processes the actual plaintext, and may leak information about it through side-channels. In that configuration, you lose all the mathematical security that I was explaining above: incompetent Bob cannot reveal anything about the plaintext when he only ever sees data encrypted by Alice; but if he gets the real plaintext, then anything goes.

  proportionally to your ability to keep the scheme secret and your crypto skills

Neither algorithm secrecy nor crypto skills can be measured or even quantified, so your "proportionally" is meaningless.

This is a fundamental point: as per Kerckhoffs's principle, we use public algorithms because we do not know "how much secret" a given algorithm can be, especially since it is implemented as software, and also exists as source code, and in the head of one or several developers. When we want security, we do not want just security; we also want to know how much of the stuff we have. And we cannot do that with a secret algorithm.


Storing last 6 digits of payment card vs 4 digits

By point 3.4 of the PCI DSS guidelines, truncation is

  generally not to exceed the first six and last four digits

, but specifically depends on whether it would become feasible to regenerate the full card number - for example, by using a hash of the same card number as a test to generate possible missing digits. Storing the first and last six digits would reduce a 19 digit card number to 7 redacted digits, which would be trivial to brute force if a hash was also provided. There is a specific note about this situation:

  Note: It is a relatively trivial effort for a malicious individual to
  reconstruct original PAN data if they have access to both the
  truncated and hashed version of a PAN. Where hashed and truncated
  versions of the same PAN are present in an entity’s environment,
  additional controls must be in place to ensure that the hashed and
  truncated versions cannot be correlated to reconstruct the original
  PAN.

Furthermore, by point 3.3:

  the first six and last four digits are the maximum number of digits to
  be displayed

In order to get an answer for your specific system, you'd need to get advice from a QSA - it's not impossible that you would be allowed to store six digits, but it would be advisable not to, and only a QSA would be able to sign off on the decision.


Native app: login with username and password

The scenario you are trying to implement is not recommended under OAuth 2.0 for Native Apps

  The best current practice for authorizing users in native apps is to
     perform the OAuth authorization request in an external user-agent
     (typically the browser), rather than an embedded user-agent (such as
     one implemented with web-views).

So, given that you've stated you want to implement in a 'secure' way, the best practice is to redirect to the system browser rather than handling the flow within your app directly.

However, if you decide to handle things 'in app' you will need to implement a http client (user agent) as part of your app. That custom user agent in your app would then need to handle the series of requests and responses to perform the OAuth 2 flow that the system browser would normally manage. Part of this would include prompting the user for credentials which would be passed to the authorization server for authentication.


At a cleared defense contractor we actually looked at building these and it is not that hard of an issue. Not foolproof, but fairly reasonable. It was a cyber-security research program and it did not get funding, but I always thought it would be a great commercial idea. At the time (a couple of years ago), to my knowledge, no one was doing this for firewire. Not many for USB, but it looks like the USB market has changed.


SSO authentication & authorization architecture/implemenation

The identity providers usually do not enforce restrictions themselves. That's why your impression is correct that the authorization part is not implemented in IdPs. They rather deliver role/group/permissions information to the application (service provider, SP) so the SP can enforce authorization.

Most IdPs can access a LDAP server to retrieve user accounts, their group membership and check the user's password. Using an LDAP server has the advantage that some applications not capable of SAML, OpenID Connect, etc. might be able to directly use an LDAP server.

Managing even application-specific group membership is very helpful if you have to provide data to be examined during security audits. So I would try to keep group maintenance out of the application.


Is it possible to prove that a TLS server key has changed?

Short answer: If the public key has changed, so has their private key.

Long explination: Modern cipher suites used by SSL/TLS servers have exactly one key pairing. So as long as one of the keys has changed, then the other key has changed as well. So if they have also disabled SSLv2 then you should be good to go. More information can easily be found on the Crypto stack.


To begin with, Wifi spoofing is named as Evil Twin attack. You can find more information about it if you search as "Evil Twin Attack" rather than "Wifi Spoofing".
I have found a good article about the attack: What is evil twin?.
Plus, there is a good explanation about how to commit it on Null-Byte.WonderHowTo. ( for learning purpose only ).

There is no need the attacker to know about your password. In addition, he does not even need to spoof your MAC address. Detecting Evil Twin is already explained well in How would you detect an Evil Twin attack, especially in a new environment? . So you can read it.


Does streaming a game from a dedicated gaming VM still expose my PCs to significant privacy/security concerns from installed games?

The most obvious inroad: The passthrough GPU has full access to main memory for DMA operations, mediated by the IOMMU, and to other PCIe devices in the same domain.
The GPU can emit "translated" memory access requests that bypass the IOMMU translation (as the addresses used are already assumed to be translated), whether that is actually implemented in existing GPUs is something I don't know straight away.
Whether the IOMMU still performs access control checks for translated requests depends on the chipset, but my expectation would be "no", as the point of having address translation inside PCIe devices instead of the IOMMU is to distribute the TLB -- performing access checks would reintroduce the same bottleneck that virtualization awareness in PCIe devices was built to avoid.
Depending on your chipset, it may be possible to disallow "translated" PCIe requests entirely, then at least the GPU would be limited to memory allocated to the VM, but access to other devices remains open.
These scenarios require determined attackers though. Unless you are specifically targeted, I'd expect that the isolation is sufficient to protect your system against the typical invasive software, because while VM breakout is possible for invasive software, actually doing something with this access requires analysis of the outside system.
The biggest threat here would likely be ransomware, but the effort/reward balance for ransomware that sophisticated is not on the side of attackers.
The thing I would expect from anti-cheat software though is that it attempts to detect virtualized environments, and flag them as untrustworthy straight away.
Hiding virtualization completely is difficult, and this is likely to become your biggest problem in this endeavor.


What are the problems with bring-your-own-device related to smartphones?

This is a really broad question that does not have a single answer.  Some categories of challenges and risks include:

Reduced control.  The corporation has to take whatever devices the employees select, and loses control over them.  The corporation may also have reduced leverage to control the software on those devices.
Dependence.  The corporation becomes dependent upon the security and availability of its employee's devices.  It becomes harder for the corporation to manage those devices.
Heterogeneity.  The corporation can no longer standardize on a single device, and instead has to be prepared to support a broad range of devices.  For instance, if the corporation makes internal services available via a web service, it can't just target IE: it has ensure the site will work with all of its employees devices.

Some potential protections that can be considered include:

Server-side security.  Architect services so they are less reliant upon the security of the user's device.  For instance, store data on a server (or in the cloud) instead of on the end-user device.
Work with employees.  Enable your employees to protect data on their own devices.  Provide them with resources and motivation to do so.  Educate them about the need and help reduce the barriers to security.
Web-based services.  Make internal services available via the web and HTML5, rather than as native applications.  (Admittedly, already a common practice.)  The web is the least-common-denominator today.
Specific technology.  There are some products and specific technologies being developed to deal with this challenge.  For instance, one is full-disk encryption or software encryption on the end-user device.  Another is use of virtual machines or other mechanisms to provide strong separation between work and personal usage of a device, so that personal use cannot compromise the security of work data -- and contrawise, so that the employee's personal activities stay private (as they are none of his boss's business).  There are also products to facilitate remote wipe and remote disable, if an employee's device is lost.  However, employers who demand remote-wipe abilities should go out of their way to make it easy for employees to back up their devices -- otherwise, a remote wipe can represent a major loss for an employee.
Establish boundaries.  Companies can help establish clear boundaries.  The widespread growth in always-connected devices (smartphones, etc.) have transformed the way people work, to the point where many people effectively feel "on call" in jobs where a decade ago this would not have been the case.  You see many people checking work email outside of business hours and feeling the resulting pressure.  This may feel more efficient, but there are some reasons to believe that in the long run it impairs employee effectiveness -- so companies can help by establish a healthy culture that encourages their companies to set boundaries and have a personal life outside of work.
Embrace the trend.  Look on the positive side; BYOD is spreading because it brings major benefits, such as reduced technology costs for companies, improved employee productivity, increased employee morale, and increased flexibility for flexible work hours.  So, don't caught up too much in the risks -- the risks must be managed, certainly, but the primary job of security folks should be to say "yes", not to say "no".  IT security departments can think of this as a prime opportunity to gain a reputation as an enabler, not a barrier to progress.


Can someone please explain to me the significance of the number "196"?

196 is a randomly chosen number for a file descriptor that you're opening for reading from and writing to via exec. You can replace it by any number > 2.


Loading a passphrase-protected private SSH key from a file with the cryptography Python module

Like any beginner, I made this more complicated that it needed to be, and didn't read the documentation properly.

The key must be read as bytes ('rb'), and the passphrase must also be bytes-like, as per the documentation.

import SecretString
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives.serialization import load_ssh_public_key, load_pem_private_key
from cryptography.hazmat.primitives.serialization import Encoding
from cryptography.hazmat.primitives.serialization import PublicFormat

def importPrivateKey(private_key,passphrase):
  """
  Imports the private key in an RSA object and generates the hash.
  """
  with open(private_key,'rb') as private_key_file:
    key = load_pem_private_key(private_key_file.read(),
                               password=passphrase.encode(),
                               backend=default_backend())

  public_key = key.public_key()

  print(public_key.public_bytes(Encoding.OpenSSH,PublicFormat.OpenSSH))
  SecureString.clearmem(passphrase)

  return key


First, the attacker can't always spoof the content type. For example, if your REST API supports a web app that uses cookies to hold session tokens, an attacker may try using CORS (cross-origin XHR) or auto-submitting HTML forms to attack users of your service when the victim visits the attacker's page. If making a cross-site request from the attacker's site (which doesn't have CORS permission for Access-Control-Allow-Header: Content-Type), the attacker can't set the Content-Type header. However, if the application just assumes that the content type is something CORS disallows by default (like JSON) and doesn't verify the header, then an attacker can send a request using one of the non-preflighted / allowed-by-default / allowed-in-forms content types such that it will be accepted by a JSON (or whatever) parser. Of course, ideally you'd have anti-CSRF protections, too, but sometimes people think "I only allow JSON and don't let third-party sites send me JSON, so I'm safe" when in practice they also allow other content types so long as the request body is also valid JSON.

Other times it matters come when doing things like letting a user upload files (always something to do cautiously); if you limit allowed file types, but don't actually verify that uploaded file's type is what it's supposed to be, you could experience a variety of types of problems (depending on what you do with the uploaded files). If you do different things with different file types, you may need to both verify that the user specified a file of one of the allowed types, and that the uploaded file is valid for that type.


what freeware tool for java source code review?

Unfortunately you're unlikely to get a free tool to do full code reviews of enterprise applications as Static analysis tools tend to be complex and pretty expensive.

That said there are some things you could look at which do address Java and could be of use to you.

PMD
Findbugs
Lapse+

would be good places to start looking.  also some other options from this list could be helpful.


Are there any examples of network-based application firewalls?

... have a remote network based firewall capable of application level filtering (e.g. block all outgoing traffic from test.exe).

The phrase "application level filtering" is usually used with a different meaning than yours, i.e. filtering on the application protocol level (web, mail, ...) and not on the level of a specific application program.

The exact program which caused the traffic is only known on the host where it is running but is not known inside the network. So no direct filtering can be done based on this inside the network. One could maybe associate the data seen in the network with a specific application instance running on the host if one would have some agent on the host though. But in this case one would run into the same problem as with having a host base firewall, i.e. that one cannot fully trust the host because it might be compromised.


What approaches exist for ensuring security when deploying software in non-trusted environments?

Is it possible to deploy software in such a way that a rogue actor who has physical access to the hardware is unable to glean any information on the code that is running or what is being stored in memory?

No, this is impossible, for the following reasons:

Physical access pretty much always means game over, so this alone would be a strong indication that what you want is not doable.
No matter how much you try to protect your code and the data it produces, in the end the processor has to have access to both the machine code of your program and the data it works with. Even if your code self-decrypts and encrypts every piece of data before it is moved from a CPU register into RAM, the encryption keys must still be stored somewhere (possibly in registers, too, but that only means they're harder to access - not impossible). I can imagine various ways to access this data, such as dumping the whole RAM into a file, running the code in a debugger, suspending the machine and store away the suspended state for inspection after the machine wakes up again, changing the kernel or libc to help spying on your code and so on.

I don't understand what you mean with "will something like a fully homomorphic encryption scheme help with this", but I doubt very much that it will change point 2, whatever it is.

TPMs provide a way to store keys and do encryption and decryption inside the TPM, so the keys aren't exposed, but again, this only makes it more difficult to get at the relevant information, not impossible.


Is there a layer 1, 2, 5 and 6 DDoS attack?

...when I saw 3/4 and 7 DDoS attacks, I figured they were the most popular, but there were also layers 1,2,5 and 6 layers as well.

The OSI model does not have much common with reality anymore, at least not with layers 5..7. Instead you will find layer 4 functionality packed into layer 7 (like with Websockets) or layer 5 (session) functionality within the application layer (HTTP cookies) etc. Therefore you might better refer to the TCP/IP model which merges OSI layer 5..7 into a single application layer and don't look for separate attacks at each of these layers.

DOS of OSI layer 1 (physical) is of course physical too: just somehow damage the cabling, like using a nuclear bomb (either by destroying the cables or by EMP). A distributed DOS would be much harder, because you would need to be of course physically present somehow.  At layers 1 and 2 you also have various DOS attacks against WLAN (just google and you'll find some paper), but distributed DOS would more mean attacks against the underlying control functionality. There might be some "packet of death" attacks which make certain network cards croak but you would need upper layers to get access to these cards first within a distributed attack.


OpenID Connect: How to maintain a single sign-on experience between multiple web clients of the same umbrella application?

You essentially get SSO out of the box with IdSrv4.  Once you're logged in to IdSrv, your browser will send the IdSrv cookie together with each request to IdSrv.  So when your first web app sends an auth request, you'll be asked to authenticate at level of IdSrv - at that time, that auth cookie is created and (depending on the flow you're using) a code and/or tokens are returned to your client app.  When your second web app sends an auth request to IdSrv the browser sends over the auth cookie together with that request, so you will still be authenticated at level of IdSrv (assuming the cookie hasn't expired) - code and/or tokens will automatically be returned to your second client without the user having to provide his/her credentials again.

I would advise against reusing the same client ID (and thus client secret) across various web apps: in case the client secret is exposed for one web app, it's exposed for all, and that's something to avoid.

The identity token is typically very short-lived - the only reason to hang on to it (after using it to authenticate at level of your client app) is to pass it to the endsession endpoint as an id_token_hint when you're logging out.

Hope this helps :)


Maximum protection on a computer network?

Pragmatic advice. The best advice I can give you is not technical advice; it is organizational.  You don't want to lose your jobs.  That's understandable.  The best way to meet that goal is, Don't try to do this yourself.

Your company almost certainly has an IT department.  Contact them to ask them how they'd like you to secure your home PC and what practices they want you to follow them.   Then, do what they say.  If you follow their guidelines, then even if something bad should happen, you should have good protection against being fired.  Hopefully few companies would fire a valuable employee who acted in good faith and followed the rules faithfully.

Technical methods for hardening.  If you want technical advice, you can find all sorts of advice on how to harden a Windows PC.  Here's my top list:

Enable Windows automatic updates.
Get anti-virus software and enable it.
Turn on a firewall to block all incoming connections, except for the sync software.  A google search on Windows Firewall should provide directions on how to do so.
Take regular backups.
Follow the advice listed in this question: If you have to write an information security guide for non technical users, what would you cover?
Install Secunia PSI and set it to scan your computer for unpatched software periodically.  Follow its advice to update any old software it finds.
If you want to be extra-cautious, you could follow the advice here: Quick steps to Windows 7 OS hardening.

If you follow the steps listed above, you should be among the top 5% of security practice, perhaps the top 1%.


Can local Admin on Windows be given restricted permissions?

Quite a lot of enterprise software tries to do this. For example, firewall or VPN software can have it's configuration locked by a central admin, and a local administrator cannot modify the settings through the GUI.

However, this does not stop a determined attacker with local admin access: they can still edit the registry or config files directly. I never liked this approach, but in a practical working environment, a lot of users do need admin rights, or you interfere with them doing their work.

One interesting variation on this approach is to heavily restrict the host OS, and not give out admin rights at all. But power users can run a guest OS inside a virtual machine, and they are allow full rights on this. I've not seen this implemented in a commercial environment, but I think the idea has merit.


Secure data in memory (C#.Net application)

The first thing you need to consider is how you are managing the sensitive information in your code. As an example if you manage your password(plain text) using a string data type, there is a high risk that some one can grab your password from the memory. Because in .Net, the String data type is immutable and you do not have any control over it.

So the best way to manage sensitive string data in a .Net app is by using the SecureString class. It is managing string data as byte arrays and you do not need to worry about data conversions etc.. You can use the Dispose() method when ever you finish your work with sensitive data.

        // Instantiate the secure string.
        SecureString securePwd = new SecureString();
        ConsoleKeyInfo key;

        Console.Write("Enter password: ");
        do {
           key = Console.ReadKey(true);

           // Ignore any key out of range.
           if (((int) key.Key) >= 65 && ((int) key.Key <= 90)) {
              // Append the character to the password.
              securePwd.AppendChar(key.KeyChar);
              Console.Write("*");
           }
        // Exit if Enter key is pressed.
        } while (key.Key != ConsoleKey.Enter);
        Console.WriteLine();

        try {
            Process.Start("Notepad.exe", "MyUser", securePwd, "MYDOMAIN");
        }
        catch (Win32Exception e) {
            Console.WriteLine(e.Message);
        }
        finally {
           securePwd.Dispose();
        }

  What is the best encryption algorithm for our case?

I hope you are not using encryption in passwords ? Passwords need to hashed using good salt and good hashing algorithm. Do not use MD5 or SHA1 because these are weak hashes according to the current standards. At the moment we can consider the PBKDF2 is one of the best hashing algorithms available. The AspNet Identity framework using the PBKDF2.

You can use AES algorithm to encrypt your other sensitive data. But keep in mind to secure your keys. You can use the .Net Key container for that purpose


My WebSite is being attacked, should i be worried seeing the logs?

Setup Fail2Ban, or it's equivalent, to monitor your weblogs and automatically block the IP address from people doing stuff like this. Always keep an eye on your logs but have plans in place for what to do when things happen.

Every system on the Internet gets scans like these pretty much daily if not hourly in some cases. Learn how to harden your server and applications so you don't have to worry and test it with everything you can. There is a lot to doing security well but tools like Fail2Ban can help a lot.

https://www.fail2ban.org/wiki/index.php/Main_Page


Strange activity on my computer, possibly hacking?

It appears that you have some malware on your computer which is performing something which is known as Blackhat SEO / SEO spam.

Search engine optimization is the process of making a page appear higher up on the page ranking when someone makes a search query.

Malicious SEO uses methods such as backlinks from hacked websites, performing automated requests from malware-infected PCS and other methods to attempt to trick Google's algorithm into ranking a page higher.


Can I detect OS and browser spoofing on webserver side?

This may not be possible directly from Apache however analysis of the network HTTP packets themselves may reveal details such as TTL and TCP Window Sizes that would indicate that they don't match up with the platform/browser.  I am sure some Intrusion Protection Systems (IPS) offer this capability out of the box.


What you might not have thought of or read about is that Debian backports security fixes from newer versions of software to current versions. For instance, one of the Spectre-associated CVEs on Debian's security tracker shows all supported Debian versions, including oldstable. Although these really old Debian versions won’t be receiving brand-new kernels, they will be getting security fixes backported to the stable kernels.

In the case of RabbitMQ, you can see from the package tracker that security fixes have been made for the old versions in Debian Stable.

Additionally, if you do need a newer version of this program than the one in Stable, you can install it from the “stable-bpo” branch or follow the directions in this Server Fault question to get it from Testing or Unstable. This is usually the safer alternative to installing the package from the project website directly.


How is the digital certificate sent alongside digital signatures?

Most externally signed files (such as authenticode, PDF, etc.) use embedded signed PKCS#7 container that contains signature and related data, such as signing certificate, chain, counter signatures (signed timestamps). Here is a top-level ASN.1 definition of signed PKCS#7 (RFC 2315):
SignedData ::= SEQUENCE {
    version Version,
    digestAlgorithms DigestAlgorithmIdentifiers,
    contentInfo ContentInfo,
    certificates
       [0] IMPLICIT ExtendedCertificatesAndCertificates
         OPTIONAL,
    crls
      [1] IMPLICIT CertificateRevocationLists OPTIONAL,
    signerInfos SignerInfos }

Signature itself and (optional) counter signatures sit in signerInfos field and related certificates sit in certificates field.
Digital signature without public signing certificate is useless, because in this case you don't have any means to validate the signature. Thus, as a rule, public signing certificates are ALWAYS attached to signature.


TLDR: if someone mimics my company mail, does he need to be part of the company to do so? does he need a company mail

Maybe.

The question is, is your company mail server configured to reject mail coming in from the outside with From: addresses containing @mycompany.com?  If so, then the attacker needs to be on your company network to spoof email from your boss to you.  If not, then anyone can send that email and tack your boss's name on it.

The more common case is that mail servers are permissive, and do not block email from the outside with a "local" From: address.

You can look at the Received: headers to see what path the mail took to you (bearing in mind the attacker can prepend fake ones, but those starting with your mail server are generally reliable.)


What asymmetric encryption algorithms are in common use beside RSA?

ElGamal is an asymmetric encryption algorithm, which is used in OpenPGP.

Almost all usages of asymmetric encryption is for key exchange (by encrypting a random string, which is then used as shared key in symmetric encryption algorithms). There are key exchange algorithms which are not asymmetric encryption algorithm, the most well-known and used being Diffie-Hellman (in a nutshell, DH is like an asymmetric encryption algorithm in which you do not get to choose what you encrypt -- the one who encrypts "discovers" the seemingly random data which has been encrypted once he has done it -- but that's good enough for key exchange).

ElGamal and Diffie-Hellman both have variants which use elliptic curves. Same principle, a bit more maths, better performance.

There are many other asymmetric encryption algorithms, e.g. McEliece and NTRUEncrypt, but they are less used for various reasons (too recent, too old, not studied enough to be declared secure, patented, too slow, public key is too big...).


Allowing the execution of arbitrary code in python

If its on their machine then that eliminates a major attack vector but doesnt necessarily eliminate all of them. I would want to make sure that it is indeed them typing in the formula. There are all different types of scenarios to think about here. What if somebody sends them a spreadsheet and they open it up? Will it execute? What if some social engineering is done and somebody cuts and pastes something without knowledge? How educated are your users? What if someone types rm -rf /? Will they lose all of their data? None of these may be applicable but you get the idea. This would really require you to look at the system as a whole and determine what type of things could possibly go wrong and if its worth the risk. My instinct says there is probably a much safer to do what you are trying to do but without seeing the exact design it would be hard to say.


Plausibility of DNA sequence for encryption

A major problem with modern biometric authentication is the fact that it uses things like your fingerprint as a password. Unlike a real password, a fingerprint is not sufficiently secret. Biometric identities can be used for usernames, which merely need to be unique to you, but not passwords. There are a few issues with using DNA as a private key or any other secret value:

You leave exact copies of your DNA on everything you touch.
The human genome does not vary much, making brute force a risk.
People who you are related to have an even more similar genome.
DNA actually changes over time in an individual, so it is not static.
You cannot revoke your DNA and change it after compromise.

You leave your DNA everywhere
A good private key or password is something you know, something which you need to voluntarily reveal. "Private key" implies that the key must remain secret and its knowledge allows someone to identify as the original holder. Unlike a password-encrypted private key on your laptop, you leave your DNA around everywhere. In your breath, excretions, skin cells that fall off in the millions, oil, hair, saliva, tears, etc. This makes it pointless for a private key that, as the name implies, must remain secret.
From a recent case where DNA was used to incriminate an individual, three judges pointed out the risk to people's privacy when DNA left unintentionally can be used as evidence in a criminal trial. Regardless of the outcome of this review, the fact that we leave DNA is still there:

The Majority’s approval of such police procedure means, in essence, that a person desiring to keep her DNA profile private, must conduct her public affairs in a hermetically sealed hazmat suit. Moreover, the Majority opinion will likely have the consequence that many people will be reluctant to go to the police station to voluntarily provide information about crimes for fear that they, too, will be added to the CODIS database.... Majority's holding means that a person can no longer vote, participate in a jury, or obtain a driver's license, without opening up his genetic material for state collection and codification. Unlike DNA left in the park or a restaurant, these are all instances where the person has identified himself to the government authority.

It doesn't matter if the government decides whether or not this evidence is admissible. What matters is the fact that the evidence, in the form of DNA, is left over in the first place for anyone to take and analyze. Worse still, once your DNA is "compromised", it cannot be revoked!
The (lack of) genetic variation in Humans
Only a tiny fraction of DNA differs between each person. While DNA itself contains a lot of information, any prototypical human genome is going to be extremely close to your genome. If you use your genome for any sort of cryptographic purposes, the differences will be small enough that brute force becomes feasible. In other words, there's just too little difference between us. Not only that, but your family will have an even more similar genome. Even if random genetic variation were great enough to prevent exhaustive search, do you really want it to take nothing more than both your parents to give up their genome to make it possible to "calculate" your genome? Or your siblings?
A large amount of human genetic differences comes from what's called SNPs, or Single Nucleotide Polymorphisms. These are individual bases in DNA which are known to vary between people. Currently, there are only a few hundred million known polymorphisms. While a hundred million may seem huge, people who are ethnically related will have far fewer genetic differences. A good key will differ equally between users, regardless of whether or not they are related by family or race.
Jumping genes (transposable elements)
There's another problem. If you are analyzing DNA down to each individual base pair, you'll find that it actually changes over time! Small self-reproducing elements called transposons are sequences that copy themselves and re-insert themselves in different areas of our genome. They do this slowly and rather randomly. Over time, this means that even our individual cells won't have the same DNA as they had when we were born. Likewise, even identical twins won't have perfectly identical DNA as a result of this phenomenon. This is not a problem for most modern genetic sequencing, which only counts specific variations on specific genes (called alleles), but will be a problem for anything that requires exact accuracy down to the individual base pair. 40% of DNA is transposable!
DNA as a unique identifier
Now, what could your genome be used for? Identification and authentication. While it's very easy to discover your DNA sequence, it's quite impossible to copy it into another person's body. No matter how much I try, if a single cell of mine is extracted and its DNA analyzed, it will show the DNA I had at birth (ignoring jumping genes), not your DNA. This makes it possible to prove an individual is who they say they are, given sufficiently careful DNA examination. It's like a SSN, but much, much more difficult to use for identity theft. Knowledge of your DNA doesn't let you impersonate it.
DNA is not the only thing that can be used for identification. The pattern of veins in your hand are unique to you, and unlike fingerprints or DNA, are not left all over everything you come into contact with. You need to explicitly place your hand on a vascular scanning device, which is less intrusive than a retina scan. This is actually a technique that is used in Japan. While this is still more private than DNA, it is still better used as a username than as a password, since it can still be obtained surreptitiously.


XSS with style attribute background-image

OWASP's XSS Filter Evasion Cheat Sheet clearly states that the cases you mention are for old browsers

  Deprecated Tests (Works on IE 6 and older browsers)

  These are the tests that have only been confirmed to work on IE 6
  unless specified otherwise and do not work on any modern browsers as
  of March 12th, 2014.

Remember, though, not all of your users use up-to-date browsers.

One example is the <img src="javascript:alert('xss')" /> attack. I never thought I'd worry about it until one of our clients reported that whenever he tried to access one order's page on their inventory system, he'd get redirected to a pornographic website. I found the offending row in the database, but was never able to reproduce the redirect until I learned that he used IE6.


Using public key infrastructure or hashing for personal identification privacy?

Something very similar to what you say already happens: eg driving licences.
I prove my identity through possession of a birth certificate / passport, which is validated against a government database (Top level certificate?), and am then provided with a [possibly provisional] driving licence.

From this point on, at almost any time that I need to validate my identity I can do so by showing a driving licence.

For an even more general scheme (although at the moment I can't think of much that a passport isn't enough for?), the main problem seems to be finding an issuer everyone is happy with - many people here in the UK have an issue with the amount of data the government holds about them already. The idea of a single certification authority with access to even more detail than currently held would really worry civil liberties organisations.

Alternatively, perhaps you're discussing a less general scheme than a driving licence, in which case I suggest a 'company/student ID card' as an example? To do this, one uses a higher authority (passport&driving licence) to validate their identity to the company, who then issue a sub-certificate (company ID card) which henceforth they use as suitable proof that the person is indeed a member of staff.


Send your employees to Google's Gmail for business benefits page. http://www.google.com/enterprise/apps/business/benefits.html?#security
It says "When you put your data in Google Apps, you still own it, and it says just that in our contracts."


What is a good way to generate a one time pad, and is this a good way?

A one-time pad is an encryption mechanism consisting of combining a stream of key material with the data to encrypt, using a reversible operation; this combination can be very simple, and even doable by hand (without a computer), and still retain security as long as the key material (the "pad") is as long as the data to encrypt, and is never reused (that's the "one-time" part).

Security is relative to how much the key material is unpredictable to attackers. The mathematical beauty of the OTP is that there is no upper bound for that: you can reach information-theoretic security, i.e. achieve perfect protection against computationally unbounded adversaries. Well, you might. Things can become a bit unclear once we begin using infinities.

"True" randomness can be defined as that which cannot be predicted by any attacker. It is unclear whether true randomness can exist at all:

Right now, physicists work under some assumptions, one of which being that there is an unavoidable level of incertitude in where things are and how fast they go. This is Heisenberg's uncertainty principle. While this interpretation of the real world has been very successful for the last century, and allowed many stupendous technological advances (including the computer you are using to read these lines), it still is a theory in the strong sense of the term: it is "true" as long as it works well at predicting behaviour of physical systems. Whether Heisenberg's principle is fundamental, or a mere illusion due to our imperfect analysis of some underlying mechanism, remains to be seen.

In a sense, Heisenberg's principle guarantees us existence of randomness only through the usual Argument by Authority: many very smart people with blindingly white lab coats say so. But not all were convinced. Famously, Albert Einstein, one of the smartest physicists to date, was unconvinced, and expressed so in his famous quote: "God does not play dice with the universe". Of course, we can retort that for all his smartness, Albert has been dead for more than 60 years, but that's a rather feeble argument.
Maybe more importantly, in the case of OTP, the supposed randomness has been measured, since it became the very macroscopic object that is the OTP. What matters for security is how much that pad is not known to the attacker, but since the pad has been used, it has existed in the tangible, human-sized world, e.g. as a piece of paper with printed ink. This is bound to leave some traces. For instance, if you printed it with a common printer, then remains of the data may linger in the printer memory. If you wrote it down with a ball pen, the pressure of the pen may have let a readable depression in the paper sheet below the one you were writing on. If you burned the paper down in the chimney, the carbonated remains might still leak some information (I saw that one in a MacGyver episode, but it turns out to be a real thing as well).

Thus, in a quest to True Randomness, we must not only defeat Albert Einstein, but also Sherlock Holmes. Physics may come at our rescue, this time the second law of thermodynamics, which can be interpreted as the assertion that information really gets lost over time. Thus, physicist are ready to agree that if we got an unpredictable piece of data at some point, then we may hope to completely suppress it, so that it won't be uncovered by an inquisitive adversary. Possibly.
Even if we obtain really random events, in the sense explained above, these events may still be biased. In any practical setup for OTP, the key stream must be uniformly random, so there is a need for some unbiasing. Unfortunately, generic unbiasing mechanisms (namely, hash functions) are "normal" cryptographic objects, which live in the computationally bounded world of security. We do not know how to make a hash function that would still fulfil its unbiasing role even against a computationally unbounded attacker.

(We can make perfect unbiasing if we know the exact distribution of the source random data from which we want to remove any bias. But since we do not even know whether random sources really exist, pinpointing that distribution could be hard.)

Fortunately, there is no practical need to reach absolute unpredictability. This is because computationally unbounded attackers are mythological (in the true sense of the term: we make stories about them, but we have never undeniably met one). The points above may seem excessive in their nitpicking, but that's nothing with regards to how utterly unrealistic an unbounded attacker is. Infinity is kind of big; remember that.

So, for practical purposes, you just need randomness which is unpredictable by actual attackers, not mythical ones. This means that a cryptographically strong PRNG will be sufficient. It won't deter God, if He wants to spy on you. But He already can (because omniscience), so what would be the point anyway ? You create an RNGCryptoServiceProvider instance -- so, just use it. Once it is created, it will happily spew megabytes of data at a high rate. There is no need to add random delays or any other ritual dancing step.

Programming is the art of not goofing up, and yet there is plenty of room for that. For instance, a CSPRNG like RNGCryptoServiceProvider, or /dev/urandom on Linux systems, produces bytes, which are values in the 0..255 range. Extracting random characters out of these bytes can be done correctly, or poorly. If you have an alphabet of 40 signs, then you could imagine that you just need an Euclidian division of each byte value by 40 and keep the remainder (the '%' operator in C#, 'mod' in VB.NET). While this would produce only values between 0 and 39, these would be biased, even if the source random bytes are not. This is because 256 is not a multiple of 40; thus, remainders 0 to 35 would be somewhat more probable than remainders 36 to 39.

The correct way to generate random values in the 0..39 range from source bytes in the 0..255 range is to use a rejection method. When you want to get a new random integer in the 0..39 range:

Obtain the next random byte x.
If x < 240, then return x mod 40.
Otherwise, loop to 1.

In other words, you must discard some possible input values, and get additional bytes when such a value occurs.

As a final note, one-time pads are grossly impractical and cumbersome. They were used in the pre-computer era because there was nothing better at that time. But now they are mostly an historical curiosity, and a mathematical concept for reasoning about infinities.


Yes, you can combine several authentication methods using the Satisfy {any|all} directive.

To apply BasicAuth only on some URLs, matching a pattern:

SetEnvIf Request_URI ^/webservice/* do_basic_auth
<IfDefine do_basic_auth>
    AuthName "Authentication"
    AuthType Basic
    AuthUserFile /somewhere/.htpasswd
    Require valid-user
</IfDefine>


How dangerous is it to store password in plain text on sites like GitHub?

I do this as well as I work on a project stored on Github from different locations. However, the moment my code goes into acceptance or production, the password is changed to something random. So for testing/development, I don't really care about my database credentials being in there, as they are only valid on my development machines and no data in there is confidential.


Is my Google Drive still secure if Chrome was heavily compromised?

From my point of view there are two things to consider. First, how did these extensions get installed on your computer in the first place. Second, if these are malicious what information could they have accessed.

I can't speculate how the extensions were installed, but they didn't just come bundled with the official version of Chrome. They had to get onto the machine somehow, possibly from another compromised program or from something you installed not knowing these were bundled with.

As for what information they could access, there is pretty good sand boxing within Chrome. It's very unlikely the plugins were able to access the disk contents on your computers, which is a good thing. They can however see information transmitted to/from websites. I'm not sure exactly how chrome stores session data for google drive. I would guess this is locked down pretty tightly given Google has control of the code running both server side and client side. I would gets session data was safe from these extensions but I can't say for sure. Regardless I would recommend changing your password for google drive and enabling 2 factor authentication (if its not enabled). Personally I like the Authy app for 2 factor (but there are other "TOTP" apps).

Finally, the security between Google Drive and iCloud is going to be similar. I don't think changing provides is going to provide any direct benefit. The main difference is with provides is the integration offered by each service and the devices you use. iCloud implements a useful 2 factor authentication workflow that prompts you to approve new devices/logins from an existing (approved) iPhone/Mac/iPad. In practice this seems to work well for me and is easier that launching an app and typing a code in before it expires.


Is it OK to hash sensitive data, given hashes provide no confidentiality?

is it OK to assume the hashed data remains private when using the correct hashing algorithm?

It depends. It is easy to derive the hash from the data. So if there is only a limited number of options in the data it is easy to try all to find out which data item a specific hash means.
Even if there is a huge number of possible options but most of these highly unlikely the privacy can be broken in many cases by simply trying the more probable options. That's also the idea behind effective password brute-forcing: try the most commonly used passwords and their variations first.

If so, what's the name of the property that provides this safety?

The relevant properties which makes brute forcing hard are the slow performance and the choice of salts. Proper use of salts makes it impossible to precompute the hash of many inputs. Slow performance then makes it impossible to simply try each input.

SHA256 also provides non-reversibility, but is easy to bruteforce. Is there a name for this property?

Performance. SHA-256 is simply very fast and that's why it is possible to try lots of inputs in a short time.


Actually, there are some means by which you could make an attack more difficult or limit the impact of a breach here.

One is using per-user secrets and storing them separately.  The server would only see them in memory and some form of server sharding by user could be used to limit the number of per-user secrets exposed to a single compromised server.

Another is using a separate KMS system that generates or validates tokens.  That system would have to be hardened as well, but an attacker would then have to breach multiple layers of your system to steal the secrets.  In some KMS systems the keys are stored in the TPM so even a soft compromise of the KMS wouldn't leak the keys.  They'd have to steal the hardware itself so offline attacks of your tokens are effectively designed out.

Bear in mind that the token system may not be the weakest link here.  It's good in isolation to harden it, but to have effective overall security you need to make defense choices based on a threat model of the system this component is deployed into.


Is using a phrase from a book as a password such a bad idea

Yes, it is a bad idea. The number of books in the world is quite finite, and efficient password cracking software can make billions of guesses per second against an offline password hash. It is not at all difficult to try every single possible combination of phrases in every single digitized book in the world.

The length of the sentence itself doesn't matter either. This is because an attacker will be taking entire sentences and phrases at once and hashing them. They will not try to brute force it from scratch.


Can CORS Anywhere able to bypass CSRF protections?

Nope!

Bypassing the Same Origin Policy (and other data exfiltration attacks) and CSRF attacks are both impossible using the CORS Anywhere service.

Both of the attacks you describe require the attacking page to be logged in (authenticated) as a victim user in order to be useful. (If you aren't signed in, you could just access the page normally with a web browser without any 'attacks')

As a result, cookies, which make someone logged in, need to be sent in all the attacker's requests.

In the case of a Cross-Site Request Forgery attack, this is done by the browser automatically unless otherwise requested. However, the attacking page never actually gets to see the cookies of the victim page.

To use CORS Anywhere, you send a request to CORS Anywhere, and it will forward your request to the target site. If you, as the attacker, cannot see the cookies of the victim page, you cannot send those cookies to a service like CORS Anywhere. As a result, CORS Anywhere cannot send the cookies to the victim page, and so the victim page wil respond as if you are signed out. The attacks you describe cannot be performed while signed out.

  tried changing Content-Type:application/json to Content-Type:text/plain but it not worked. The response come as Content-Type:text/plain not allowed.

This can maybe be bypassed, but not using CORS Anywhere. :)


Word of advice: It's great that you are reaching out, but medical data
  is particularly sensitive and handling should be done by an
  experienced developer and the code should be peer reviewed. There is a lot at stake here and too many things can go wrong.

That said you need to take several aspects into consideration.

The first thing you need to do is a threat analysis. What threats do you need to protect yourself from?
Most likely you will also have to follow legal requirements. What are those? How are they checked?

On a more technical aspect, you will most likely need to consider these:

Upload and download need to be via HTTPS, preferable with a modern cypher suite.
Your S3 buckets must be private and access should only be allowed via signed URLs
Singed urls should be handed out by your application after checking that the user has indeed access to this resource. Validity of this URLs should be short, so that they can't be bookmarked or passed around.
How you encrypt the data is highly depended on your use case. I can only give you hints since I don't know where you need to take your application

If you encrypt in the backend, you need to setup a key management. It also means you will have to download the files from S3 to the backend, decrypt it, before you pass it to the client.
Client Side encrypt is possible, but again, key management is important. This will also have an impact on who can share files. If only the client has the key, they are the only one to decrypt it.
In both cases, you still have the issue that once the client can view the data in unencrypted form, it is available unencrypted and no longer protected.

Last but not least: do not implement your own cryptography. Select a popular library, make sure you understand it well, and keep it up to date with the latest security patches.


I see various issues with your approach (in no particular order, and most likely not a complete list):

It seems like you're deploying the application without SSL/TLS. If that is the case, you must not rely on the client side, as a MITM can replace your (secure) client-side implementation with anything he/she chooses.

There is no way to create a secure web application without SSL, as the client would then load your application through an insecure channel. If your application is deployed through a secure channel (not sure if angularjs supports offline deployment), ignore that.

If you use SSL, that will probably mitigate all other attack scenarios as it protects against MITM and replay attacks. The only thing that could be an issue is Authentication, given you do not use client certificates. But usually session tokens are sufficient for web applications, as the server is properly authentificated (given you use a proper implementation).
You wish to secure against replay attacks, but only use timestamps for requests. If an attacker is able to record and reply a request fast enough, the server will consider the request valid. Depending on your actual data this may or may not be a problem.

To prevent that attack, add a request counter or store the timestamp of the last request on the server (and require a greater timestamp than the stored one).
Besides your actual HMAC, you are not salting your passwords, that way an attacker with database access is fatal for your application and your user's passwords. I'd strongly encourage you to salt your passwords.

Also, it is usual practice to hash passwords many times to increase the workload required for dictionary attacks against the hash.
From what you write it is not clear that you include the message/request content into your HMAC. But I assume you are aware of the fact that a HMAC only verifies the integrity of the data it is generated with.
You do not use truly random keys for HMACs. Given today's computing power it is likely that weak passwords lead to a crackable HMAC, as possible hashes are easy to compute. Hashing multiple rounds might help a tiny bit (and salting if the attack is against multiple users), but it is crucial you install some brute force prevention at last (maximum number of illegal requests per hour or similar, then block the source IP).

However, I personally would never trust anything soley based on user passwords.

So, personally, I would recommend against rolling your own crypto and for sticking with SSL/TLS. While that basically means that every client-trusted CA can certify a MITM, I think that that risk is by far lower than a MITM certifying himself by delivering a malicious webapp to the user, replaying requests or cracking the HMAC's secret.


Side Channel attacks leverage information gained from observing or interacting with a system in a way other than anticipated by its creators. Often this is done to infer information about encryption keys or other secret information.

Some of the most common side channel attack vectors are:

Timing
Power monitoring
Error handling analysis

Examples for the mentioned include:

AES cache timing attack to determine encryption keys (very good paper by DJ Bernstein)
Differential power analysis against DES to determine encryption keys (famous paper by P Kocher)
RFID passports' error handling is exploited to infer nationality -> privacy breach (link)

While Wikipedia states that:

  ... a side-channel attack is any attack based on information gained from the physical implementation of a cryptosystem ...

I would argue (along with Bernstein and others) that side channel weaknesses may also emerge from design. In the AES example this is due to the fact that it is pretty much infeasible to write constant-time performing code for general computing while maintaining efficiency.

So to come back to your question; while you exploit a side channel attack in an implemented system, the root cause for its existence cannot generally be attributed to implementation only. You will have to look at a specific system and its implementations, and you may find that the answer to the question depends largely on where you place the boundary between design and implementation.

(If the design of AES had guaranteed static computing times, the timing attack would not have been feasible on any correct implementation as an example...)

You may, however, have differing implementations of AES which are or are not vulnerable to a timing attack, to answer your question about systems A & B (System A may enforce static computing times while B does not).

With a well-defined attacker model I would say that you could define a side channel resistant algorithm. Please clarify that question tough - not sure I understood you fully..

Edit: Some more fun and interesting reading in this brief and easily readable article. :)


Isn't microtime() or mt_rand() sufficient for password reset?

This paper shows several attack methods on PHP's random functions. At the end of the paper you can find an example of a secure token generation function.


How to verify data from localStorage on a server

You need to authenticate the user's mobile device (thus implicitly authenticating the suer).

I suggest that you generate a fresh, random 128-bit string (using a cryptographically secure PRNG), store that on the device, store it on a server-side database associated with the user, and use that to authenticate the device.  The device can connect over SSL and then send this 128-bit string to authenticate itself to the server.  If you are using HTTP, one very convenient way to do this is to put the 128-bit value in a secure, persistent cookie and use HTTPS.  The 128-bit string can be stored on the device permanently.  This way, the user never needs to log in again.

Alternatively, you could authenticate the device by having the device generate a fresh client cert, and then connect using SSL with this client cert.


Without sounding pretentious or even giving you a dummy answer that sounds too simple, what you need to do to really see the "meat" of the vulnerability, as well as mitigation solutions and other details, is to drill down into the hosts that contain the vulnerability.  Click on the vulnerability itself and then on the plugin ID#; this will give you a generalized idea of the vuln.  Next, click on an IP address of one of the hosts that is affected and it should tell you last time this vuln was observed, as well as how to mitigate it based on Tenable's recommended actions.


Stateless authentication with JWT: refresh token is not stateless

One of the main criticisms of stateless session tokens is the lack of a secure logout. Having a separate access/refresh token allows a compromise. You can greatly reduce the amount of database access, while having a secure logout function with a 15-minute delay.

The design doesn't do anything to protect against session hijacking, i.e. malicious capture of the token. Just use SSL, it is ubiquitous these days.

You can reduce the amount of round trips with some care. Many client HTTP libraries allow you to perform proactive authentication, which avoids the extra round-trip to get a 401.

I agree that it's not a particularly sensible design. Most web site are database heavy anyway, so checking a token on each request isn't much more overhead. And while the basic concept of access/refresh tokens is secure, I worry that the extra complexity invites implementation flaws.


How to hide my platform from a browser to keep my privacy?

It's virtually impossible to do this on your own. There are dozens of fingerprinting vectors that can be used to detect the operating system you are running or uniquely identify a browser, and sometimes even your individual hardware irrespective of the OS you use. Paradoxically, any changes you make to your browser configuration actually make this worse. In addition, TCP option fingerprinting makes it such that your browser alone is incapable of hiding the platform you are using, because the mere connection that comes from your operating system leaks the operating system (and even system uptime).

There is a solution, however, which is to use Tor Browser on the highest security setting. Every Tor Browser installation attempts to be indistinguishable from each other (it has a large anonymity set). It's not perfect, but it's far better than nothing. The use of Tor as a proxy also defeats TCP fingerprinting.


Model for multi-tenant data encryption where the application owners or cloud providers cannot see decrypted data

From what I can gather, in your process data are placed in the care of the cloud-hosted service in unencrypted form (ie. they may arrive by TLS socket, but are then delivered to the hosted service without encryption). The point being, clear-text data are exposed in the hosting service at some point in time, so you can never guarantee to your customers that you can't decrypt the data, because you've had the plaintext at some point, however brief.
If this is not the case, then you're using end-to-end encryption, and focussing your attention in the wrong place. Instead, you need to think about how your customer can upload encrypted work-data that can only be brokered to the on-premise agent by the cloud service, but not decrypted.
In your proposed model, there is potentially nothing to stop me, an independent 3rd party, from generating agent-data that could be interpreted as coming from a valid source (assuming I can get a hold of the agent's public-key) .. this is why authenticated exchange protocols exist, where both parties share their public keys(s), so that the sender can be satisfied that only the recipient can decrypt the symmetric data key, and the recipient can be satisfied that the data came from the sender.
As you've hinted at in your question, most data sharing in public-key cryptography are hybrid schemes, whereby asymmetric encryption is used to secure a randomly selected symmetric key. The symmetric key is used to encrypt the data. Some relevant information would available on crypto.SE., eg. kelalaka 2020 https://crypto.stackexchange.com/a/81704/77149.
One such example is from Libsodium's crypto_box construct. (However, any governance or standards you need to comply with might restrict the cryptographic primitives you're allowed to use, which may in turn preclude the use of this library.)
To achieve this, both parties exchange their public keys 'somehow', and then use the combination of their own secret key and the counter-party's public key to derive a shared secret.
If you're doing the encryption on the cloud-service (and not on the client's work computer), you now have the client's secret key sitting exposed in the context of the cloud service... which is why AWS KMS et al. exist. These services ensure that the secret keys are better protected from other processes in the host's context. If you did use KMS to secure the data encryption key, you would have to hit KMS every time you wanted to decrypt something. Instead, you might use KMS to secure a longer-term key, and then use this longer-term key to secure keys for adhoc data operations. I discuss this in a separate answer.


Why isn't Secure Remote Password protocol being used in REST APIs?

Much of the adoption of technology is dependent on economics, and SRP is no exception.  Software shops are generally not going to spend or money on a specific technology which does not provide any sort of novel benefit.  For example, the benefit SRP would provide to an organization would be that they do not have to store passwords in their system.  OpenID already fulfills a similar role.  Choosing SRP means that an organization will have to incur the costs of developing the implementation, accept the risks of not implementing it correctly, and would provide no additional benefit over the cheaper method (OpenID, etc.)

SRP does not violate RESTful practices, as far as I'm aware.