Is a C plugin safe if I read it through an echoing parser before?

In order to make C code "safe", even against a malicious developer, then you have to fix the core issues of C, which have all been repeatedly exploited for arbitrary code execution (exactly what you want to avoid):

Weak types. In C, you can take a bunch of bytes, and interpret them as a pointer, an integer, or whatever. All it takes is a cast. As long as such casts are possible, then the language won't be safe. You need to enforce strict unescapable types.
Unchecked array accesses. C gives you pointers and from these you can read and write arbitrary bytes in RAM, with no control. From these follow buffer overflows, which can lead to security holes. In your new language, you must enforce strict array bound checks.
Manual memory management. In C you dynamically allocate memory with malloc(), and then release it with free(). Nothing prevents you from trying to access a memory block after having freed it, or freeing it twice (these are the classic use-after-free and double-free, both leading to serious consequences). Lack of free() can also imply memory leaks, which can be bothersome. In your new language, you must do something to prevent these memory management issues, and that is called automatic memory management, which is most often done with a garbage collector.

Down this road you get Java. Or C#, if you prefer. This works, but it is a considerable development effort. Moreover, the systematic checks on array bounds can imply a non-negligible overhead. For purely computational tasks with no I/O bottleneck (no disk access, no network access, and all data fits in the CPU L1 cache), I typically get a factor of 2 to 4 between optimized C and optimized Java (tested on numerous cryptographic algorithms such as hash functions; also on zlib-compatible compression). For some algorithms the slowdown was smaller (Java code was achieving up to 70% of the speed of C code), but that's rare. For the specific task of computations with big integers, Java is more like 6 times slower than C+assembly, because of the lack of support for the 64x64->128 multiplication opcode.

There are two main roads out of this (assuming that the overhead of a Java-like language is not acceptable to you). The first one is to try to use formal verification. The concept is that the code will be executed only if it can be proven that it "behaves properly". In essence, Java is doing a weak form of verification, in that the JVM proves that a piece of code does not do anything wrong like using a reference with a wrong type; but that verification relies on systematic checks, e.g. on casts and array accesses, and also the presence of the GC. Formal verification is an active research area, whose scope extends beyond security: basically, this is about proving correctness, i.e. absence of any bug.

There are good mathematical reasons why a generic verifier which works on all possible programs cannot exist. Researcher still hope to improve things in several directions:

There are programs for which proofs are feasible. For instance, a program with only if but no loop, and no recursive call, cannot loop "forever": that's an example of an easy proof of correctness for programs which follow some specific rules. Researchers try to define more useful sets of rules which still allow for proofs.
The human developer may provide proof elements. There are constructions for which no algorithm is known to generate the proof, but a developer-provided proof can still be verified. Assertions fall in that category.
We may find optimizations: starting from a generic "safe" language like Java, an automatic prover might find "occasions", e.g. code chunks where it can be proven that some array accesses are necessarily fine, thus allowing for removal of the corresponding checks. In fact, modern JVM apply such strategies, which is why they are not as slow as could be feared. Many researchers believe that there still is room for improvements.

However, right now, don't hope for too much: existing top-of-the-line Java and .NET virtual machines are about the best that can be done for now.

The other method is to surrender the CPU to the potentially hostile code, and instead move the security perimeter at an upper layer. The "plugin" is executed in an address space of its own; the MMU blocks unwanted accesses. The plugin code can do all the memory accesses that it wishes: it will see only its own code and data. If the code tries system calls, then the kernel knows not to honour them.

Among incarnations of this method are FreeBSD's jails and Linux's seccomp. The same concept at a still higher level is virtualization with hypervisors: the guest can be a full operating systems, with access to disks, network... and yet all this hardware is virtual and the guest cannot escape from the closely guarded perimeter set by the hypervisor.

The main problem with that kind of isolation is overhead for data exchanges. If your "plugin" must consume a lot of data from the application into which it is plugged, or if it produces a lot of data for that application (typical example: video codecs), then the moving of data between the two worlds, beyond the MMU/hypervisor barrier, can kill performance.


What could an attacker do with informations about devices in my local network?

Just a few examples:

Detect the type of router and exploit it via CSRF. Then change the DNS settings and thus have man in the middle attack. See this example where millions of DSL routers got hacked.
Use CSRF, XSS, DNS rebinding etc to extract information from internal web sites, i.e. internal web mail, company wiki etc.
Use the web interface of VoIP phones to make expensive calls or switch on the microphone and listen to whatever happens in the room.
Just collect various information which then help to attack specific targets (i.e. intelligence).


How to determine what type of encoding/encryption has been used?

Your example string (WeJcFMQ/8+8QJ/w0hHh+0g==) is Base64 encoding for a sequence of 16 bytes, which do not look like meaningful ASCII or UTF-8. If this is a value stored for password verification (i.e. not really an "encrypted" password, rather a "hashed" password) then this is probably the result of a hash function computed over the password; the one classical hash function with a 128-bit output is MD5. But it could be about anything.

The "normal" way to know that is to look at the application code. Application code is incarnated in a tangible, fat way (executable files on a server, source code somewhere...) which is not, and cannot be, as much protected as a secret key can. So reverse engineering is the "way to go".

Barring reverse engineering, you can make a few experiments to try to make educated guesses:

If the same user "changes" his password but reuses the same, does the stored value changes ? If yes, then part of the value is probably a randomized "salt" or IV (assuming symmetric encryption).
Assuming that the value is deterministic from the password for a given user, if two users choose the same password, does it result in the same stored value ? If no, then the user name is probably part of the computation. You may want to try to compute MD5("username:password") or other similar variants, to see if you get a match.
Is the password length limited ? Namely, if you set a 40-character password and cannot successfully authenticate by typing only the first 39 characters, then this means that all characters are important, and this implies that this really is password hashing, not encryption (the stored value is used to verify a password, but the password cannot be recovered from the stored value alone).


How vulnerability assessment is different for application and infrastructure?

Application vulnerabilities are very different from infrastructure vulnerabilities.

The app needs to be tested, and the machine needs to be tested, too. You choose the best type of testing for what you want to achieve. App testing for apps, infrastructure testing for the infrastructure.


How do web email clients store my passwords from other providers?

You seem to talk about two different things: retrieving mail and encrypting mail. From reading the question I think encryption is not what this is about. So for now I forget about it.

When you login to Hotmail or Gmail via your browser, you use your login. It looks like you have more email addresses and possibly popboxes. Now it depends on how you setup those other addresses.

Example

Hotmail: fpresencia1990@hotmail.com
Alias: presencia2@myprovider.com
Popbox: franpres22198@myprovider.com

The alias forwards mail sent to it automatically to the forward address. This can be the popbox by the same provider, or it can be any other address like your hotmail. The popbox now has an ugly name. It could have a nice name as well, or the same name as the alias, in which case the alias would not exist.

Situations

The alias forwards to Hotmail directly - no login required by Hotmail.
The alias forwards to the popbox, which forwards to Hotmail - no login required by Hotmail.
The alias forwards to the popbox, and Hotmail fetches the mail from the popbox by pop3. Hotmail needs the popbox login, which you enter only one time, and stores this permanently on its own servers. Nothing is stored in a cookie on your computer. You can check this by logging into Hotmail on another computer where you never used to enter the popbox credentials.


Yes, this is very possible.

In fact, support for this is built into the most popular port scanning tool in use, nmap. This feature, OS detection, can be activated by passing the -O flag to the nmap tool. What nmap does is send different TCP and UDP packets to the target and examine the response. By comparing the response to a database of existing operating systems fingerprints, nmap can determine with reasonable accuracy what operating system is running on the system.


How one can find I am using virtual box Virtual Machine linux through Anydesk remote application?

One way to determine that is

  ifconfig

The default Mac addresses map to the VM vendors.


After restoring from a (valid) full disk backup can malware still persit?

In general, restoring from a clean backup will wipe out any malware you have.

However, there are rare exceptions.  Malware can install itself in your computer's BIOS, in which case it will persist through anything but a BIOS flash (and if it can sabotage the flash process, it can survive even that).  BIOS-infecting viruses are extremely rare, though, because they need to be tuned to the exact make and model of the computer's mainboard.

The most common reasons why malware can survive a restore from backup are:

it was present on the backup, and the user didn't realize it, or
the user failed to wipe the hard drive before or during the restore, or
the user has sufficiently bad security habits that they were re-infected almost as soon as they finished the restore.


VPN Authentication and Network Administrators

It depends on how your VPN organised. Genrally, Asymmetric Cryptography is used for such cases (the same is used for TLS (https://), for example)

Here are 2 examples. They are simplified heavily, just to show main idea.

Server may have private and public keys. One may use public key to encrypt anything, but only private key may be used to decrypt it. Example of algorythm that allows such public/private key is RSA. Server sends you public key and some random number. You encrypt this random number and your password with this key and send it back. Only server may read it since only server owns private key. Then, I connect to server. Server sends me different random number, so I can't simply reuse your packet.
Diffie–Hellman key exchange algorythm may be used by client and server to find some shared key. There is some math, so you may check description here: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Besides Diffie–Hellman you should also read about Rivest-Shamir-Adleman (RSA) and  Digital Signature Algorithm (DSA).


How banking mobile applications keep data secure without Secure Element (SE)?

You must differenciate between Simple banking app where you can do some sort of account management and payment application.

Banking App rely on webservices so all security items relies only on how secure the communication is between the app and the server side and what authentication mechanism you are using(eg:two factor authentication)

Payment App Making Contactless Payment with your phone.

Android offers two possibilities:

Hardware Based Solution:
hardware based rely on Secure elements currently there is three types of secure elements:

SIM Based
Embeded Secure Element
SD Card

As this implementation is hardware it can be considered as secure.

Software based solution:

Since Android 4.4, Android has introduced Host Card Emulation(HCE), to give the possiblity to emulate a plastic card and all contactless data exchange. android offers basic security, so another layer of security is mandated like whitebox cryptographie, Other features like device and user authentication.

Both solution rely on another mechanism which is called Tokenization, so the reel card holder data will never get used between the app and the terminals.


Is it safe to store password in HTML5 sessionStorage?

In principle, values stored in sessionStorage are restricted to the same scheme + hostname + unique port, and if the browser has a clean exit these values should be deleted at the end of the session. However, according to this post it can survive a browser restart if the user chooses to "restore the session" after a crash (which means its values also exist in persistent memory until they are cleared, so keep that in mind). If well implemented, I'd say it's safe enough - especially compared to your alternative of using a cookie (which has many pitfalls that I wouldn't even consider). The W3C Specification also states that Web Storage might indeed be used to store sensitive data (though it's unclear whether or not that practice is endorsed).

As for the risks, it's simply a matter of tradeoffs: you're making your site a little more convenient for your users, while increasing a little the window of opportunity for the password to be captured (either by means of a XSS vulnerability, by the value persisting in persistent storage for longer than you intended to, or by the user leaving the computer unattended before finishing registration). Ideally, passwords should never leave RAM, but that's usually impractical to do, so some compromise is necessary. I'd just advise to clear the password from sessionStorage as soon as the registration succeeds, and to keep an eye for vulnerabilities on sessionStorage implementations that may eventually come to light.


Security implications of running multiple virtual machines on shared CPU cores

The x86 architecture (both in 32 and 64 bits) isn't really designed for a full isolation between (threads|processes|VMs). There are many low-level hardware pieces that —designed for efficiency— may leak some amount of information between them.

This isn't anything new. See for instance the 2005 paper Cache-timing attacks on AES by Daniel J. Bernstein.

This is also what happened with Meltdown and Spectre. Speculative execution allowed one CPU thread to figure out things that supposedly it couldn't.

Note also that these attacks are statistical by nature. It is a big deal that you only had a 0.03% error data when reading kernel data (meltdown) but it doesn't mean that it would succeed reading sensitive information, or that it was in memory at all!

Is it a risk? Yes, it could end up being one. And vendors (hardware manufacturers, Operative Systems, crypto library developers…) try to mitigate them as much as they can. Should you be too concerned about it? Probably not, but it will depend

A) How sensitive your workloads are

B) How evil are the other VMs

C) How much risk you are willing to take

D) The amount of funding you have available.

If you are the NSA, surely you can buy completely separate physical systems, but perhaps not if you are a home user. It's also different that your other VMs are (hopefully) clean than used to automatically run any malicious executable while continuously signing SSL certs with a CA key!


The delivery of the Authorization Code is not more a security issue than is sending the user's password from the browser to the facebook server (for example). That means, if there is an insecure connection, an attacker would be able to compromise the user's authentication anyway. For that reason, OAuth is meant to be executed with HTTPS.

The reason why it needs to be implemented like that is because only this way the OAuth client is able to identify the user who requested OAuth. This is because when a user for example clicks on the facebook button on StackOverflow, it immediately connects him to facebook where the OAuth process starts. StackOverflow so far doesn't know that this user requested OAuth via facebook. Only through now redirecting the user to StackOverflow along with the Auth Code does StackOverflow know that this user (with his session ID) used facebook OAuth and got this Auth Code. Now StackOverflow is able to connect Session ID with Auth Code and knows who requested facebook's OAuth.

edit
I've looked at the RFC of OAuth, and I have to make a correction regarding my first point. While it is highly recommended for the redirect endpoint to use HTTPS, it is not mandatory yet. See Endpoint Request Confidentiality. So the Auth Code indeed might be sent unencrypted at some point, that is when redirecting to the original server which has not HTTPS activated. But still, to me this is a huge security issue with the whole OAuth process. HTTPS should imo be mandatory. If a server can't HTTPS it's connection, it shouldn't play with OAuth after all.


Why are primes reused in Diffie-Hellman key exchanges?

You can look the following questions about difficulties in generating your own DH key exhcange parameters and also using the standard DH group parameters: Is it safer to generate your own Diffie-Hellman primes or to use those defined in RFC 3526? and Where do I get prime numbers for Diffie-Hellman? Can I use them twice?

  For plain Diffie-Hellman, what you need is p, q and g, such
  that:

  p is a big enough prime (2048 bits are more than enough nowadays);
  q is smaller, but still big enough (say 256 bits), prime value which divides p-1 ;
  g is a generator of a subgroup modulo p with an order that is a multiple of q.

In most situations, it is not easy, and also not applicable, to create a DH key exchange group before the actual key exchange occurs. Note that, logjam exploits small primes used in DH groups(512 bits). I think, you should be safe if you use a DH group with a p of 2048 bits even if the the group is used by others too.


Why doesn't KeePass use two factor / one time password generation to protect the database?

Nobody has figured out how to involve OTP with encryption that materially improves security.

It's important to remember that KeePass's master password is used to derive encryption key, so it is actively involved in file modification transactions; unlike web service credentials which are only used for authentication, which is simply attached to the transaction. OTP that changes all the time wouldn't be useful for deriving encryption/decryption key.

A place where OTP could be useful is if you use it as a quick unlock solution, where you only need to type master password once at startup, and then you can unlock with shorter password afterwards. But for OTP quick unlock to make sense, it need to be easier to type than just retyping the master password. Also, since quick unlock requires that Keepass caches the master key, for it to be secure, you probably would need an HSM of some sort so other programs can't read off the master key off the Keepass process.


Nmap showing ISPs router's DNS port in addition to target's ports

It apears that your router's firewall has hijacked your DNS requests. I found these instructions on your router's wiki page which describe exactly how to do that:

  Force users to use specified DNS server

  This is just simple firewall rule which will force all Your users
  behind RB to use DNS server which You will define.

  In /ip firewall nat

  add chain=dstnat action=dst-nat to-addresses=192.168.88.1 to-ports=53
  protocol=tcp dst-port=53

  add chain=dstnat action=dst-nat to-addresses=192.168.88.1 to-ports=53
  protocol=udp dst-port=53

  This rule will force all users with custom defined DNS server to use
  192.168.88.1 as their DNS server, this rule will simply redirect all request sent to ANY-IP:53 to 192.168.88.1:53

If you can log into your router, you may be able to undo the damage yourself. If not, your ISP would have to make the change. Your other options will be complex, like setting up a VPN.

Please note that your country may have laws regarding DNS that may have forced your ISP to provide only government-approved DNS name resolutions. For example, Turkey required the removal of Twitter's servers from DNS due to all the public tweets criticizing their corrupt cabinet. I would not advise you to attempt to work around this restriction if it means going to jail.


Is it possible to load external JS script through the "inspect elements" feature?

I would categorize it as "social engineering"; someone tells thirds to do it with their devtools. And yes, it is a possible attack vector.

Oftentimes it is warned about when you open the F12-tools on say facebook e.g.

 from (german) facebook.

They call it Self XSS


Can neighbour hear my bluetooth headset?

Can a neighbour with a bluetooth headset hear my TV's bluetooth
  emission through a wooden wall?

If you're asking about if the signal can get through, then the answer is yes. To block a bluetooth signal you'd need very thick and dense walls (something like thick concrete walls) or something that acts as a Faraday cage.

Usually bluetooth transmissions are encrypted by default, the security on this mainly relies on the pairing method.

But as forest commented, you shouldn't be worried about anything. Statistically speaking I think that it's quite unlikely that your neighbour would have the cryptographic expertise to hear your transmissions.


Estimate the time to crack passwords using bcrypt

In June 2015, using eight GTX TitanX video cards, they were able to get hashcat to perform:

14,455 hashes/second (cost factor 5, i.e. 32 iterations)

With a rig of 8 video cards, they got:

155,642 hashes/seconds (cost factor 5, i.e. 32 iterations)

Of course nobody actually ever used bcrypt with a cost factor of 5.

At the time of publication of BCrypt (1999) the default costs were:

Normal User: 6
Superuser: 8

And also:

  "Of course, whatever cost people choose should be reevaluated from time to time."

The question is how long should a hash take to compute. At the time of deployment in 1976, crypt could hash fewer than 4 passwords per second. (250 ms per password)

In 1977, on a VAX-11/780, crypt (MD5) could be evaluated about 3.6 times per second.   (277 ms per password)

You should be adjusting your bcrypt work factor so it takes 250-500 ms to compute.

Our implementation uses the cost factor 11 as a lower bound. And it then benchmarks the system, increasing the cost if it's being computed too fast.

And the function to check a password forces you to deal with the consequences of that:

Boolean passwordRehashNeeded;
BCrypt.CheckPassword(rawPassword, savedHash, out passwordRehashNeeded);

Sometimes a re-hash is needed:

because we're going from 2 -> 2a -> 2x -> 2y -> 2b -> ...
hardware is too fast these days, and is calculating your saved hash in 230 ms

Hashing speeds

Back to the question of time to crack. For different bcrypt cost factors, the CPU a the eight video card monster, the hashing speeds are:

| Cost |             Hashes/sec         |
|      | i7-2700K@3.5GHz | 8xGTX TitanX |
|------|-----------------|--------------|
|  5   |        384.04   |  115,642.00  |
|  6   |        192.02   |   57,821.00  |
|  7   |         96.01   |   28,910.50  |
|  8   |         48.00   |   14,455.25  |
|  9   |         24.00   |    7,227.63  |
| 10   |         12.00   |    3,613.81  |
| 11   |          6.00   |    1,806.91  |
| 12   |          3.00   |      903.45  |
| 13   |          1.50   |      451.73  |
| 14   |          0.75   |      225.86  |
| 15   |          0.38   |      112.93  |
| 16   |          0.19   |       56.47  |

Time to crack

The time to crack a password depends on the password. We all know that corporate password policies forbid strong passwords.

If it's a password being enforced by a corporate policy of complexity and expiration, then it will by definition be a weak password, and be broken much more easily.
If it's a password that follows best practices (*e.g. no complexity requirements, no forced expiration), then it will be much stronger.

For example:

Weak: Tr0ub4dour&3 (e.g. 1011 bits)
Strong: correct horse battery staple (e.g. π40.89316, aka 1020.33003 bits)

The passwords demanded by security auditors are intended to weaken the system:

| Cost |   Time to crack - 8 way GTX TitanX       |
|      | PCI-compliant password | Good password   |
|------|------------------------|-----------------|
|  5   |                 5 days |       29M years |
|  6   |                10 days |       59M years |
|  7   |                20 days |      117M years |
|  8   |                40 days |      234M years |
|  9   |                80 days |      469M years |
| 10   |               160 days |      937M years |
| 11   |               320 days |    1,875M years |
| 12   |               641 days |    3,750M years |
| 13   |             1,281 days |    7,499M years |
| 14   |             2,562 days |   14,999M years |
| 15   |             5,124 days |   29,998M years |
| 16   |            10,249 days |   59,996M years |

NIST says your password policy is terrible

In 2017 NIST even reminded auditors how dumb their password polices are. The better password rules are:

no complexity requirements
no forced expiration
allow any character (e.g. correct horse battery )
check passwords against corpus of previous breaches
minimum of 8 characters
no SMS 2FA
no What is the eye color of your first pet's favorite maiden name?
no password hints

Personally, I believe that a password policy should be:

password is estimated to take 50 years to break

Getting a password to take an estimated 50 years to break is ridiculously easy (once you teach people that everything IT told them about passwords was wrong.) And as a bonus:

it exceeds most statue of limitations
and hopefully i'll be dead in 50 years

tl;dr: Don't be one of those people who caves when HIPPA, or PCI, or other regulators who come in demanding password complexity and regular expiration requirements. You're just encouraging the idiots, and making the world less secure.

Diatribe about correct horse battery staple

It may be a well known password, but it is not a commonly used one.

For example, Intel's World Password Day 2014 gives the example password:

Compl3xity < Length!

Nobody is arguing that zxcvbn should recognize this is a commonly used password.

And rightly so: it's not a commonly used password!

zxcvbn is intentionally limited to the top 30,000 passwords:

     1: 123456          55893
     2: password        20785
     3: 12345678        13582
     4: qwerty          13230
     5: 123456789       11696
     6: 12345           10938
     7: 1234            6432
     8: 111111          5682
     9: 1234567         4796
    10: dragon          4191
         ...
 11577: hunter2         44
        ...
 28871: hunter22        17
       ...
 29998: scoubidou2      17
 29999: benelli         17
 30000: vasilina        17
        ...
 47022: dimazarya       11
 47023: xpcrew          11

The fact is: correct horse battery staple does not belong in the list of top 30,000 passwords: because it simply is not in the list of the top 30,000 known passwords.

In fact, i would be willing to go far as you say that's it's not used by anyone.

It is no more common that the other extraordinarily well-known password:

173467321476C32789777643T732V73117888732476789764376Lock


Is an RC4 encryption enough for my personal documents?

RC4 is insecure

From wikipedia/rc4:

  While remarkable for its simplicity and speed in software, multiple vulnerabilities have been discovered in RC4, rendering it insecure.

It's not the most broken of ciphers (see DES), so your data is getting some protection, but not ideal. You would be better off finding something that supports AES-128 or AES-256 as those are the modern go-tos.

If the authors of that app have not bothered to update from RC4, then what else is the app going wrong? Basically, it does not speak highly of the overall quality of the app.

What's the actual risk?

The Electronic Frontier Foundation has a brilliant 5-point questionnaire for gauging your personal risk:

  What do I want to protect?
  Who do I want to protect it from?
  How bad are the consequences if I fail?
  How likely is it that I will need to protect it?
  How much trouble am I willing to go through to try to prevent potential consequences?

How much effort would it be to put it through a tool that supports AES? Is protecting this data worth the extra effort?

Any of the common zip programs found on Windows, OSX and Linux should do this, I presume iOS zip tools will too.

One closing point; if you're going to go to the trouble of choosing a strong cipher, make sure you choose a strong password to go with it. If your password is easily guessable, then it really doesn't matter which cipher you're using.


Security Features enabled in Linux Debian and Ubuntu

The hardening guide on the official Debian wiki is the one of the most complete resource for Debian I have come across. You should also ensure things like ASLR is turned off if you are just getting started with exploit writing.

It's highly recommended that you use a VM for this though, basic exploits requires turning off a lot of protections to work, and this can be dangerous if you use your day-to-day machine. VMs also has a handy snapshot feature that you can use to rollback the system if something unexpected happens.


Is there any FOSS passive vulnerability scanner ? Not a NIDS but a vulnerability assessment tool

At a glance, this looks to me as just being a network-based intrusion detection system (Network IDS, or NIDS) with a few special rules.  It probably doesn't do anything that Snort couldn't do with the proper tweaks.


Could anyone technically see my requests with TOR if the person has access to my router?

The communication between Tor's exit nodes and the Internet is not different from normal traffic which thing makes Tor also prone to MITM attacks. Entry nodes do not cause a problem, but exit nodes do.

To answer straight forward to your question. it depends on what you mean exactly by see my requests. In practice, by design TOR is such that locating the source of such request sthrough the network should be difficult to determine, including your typical case.

However relying on unencrypted protocols (such as sending emails using SMTP) leads to your TOR requests being able to be entirely monitored (or seen, in your own vocabulary).


One bit can be 0 (zero) or 1 (one). So 2048 bits gives 2^2048 distinct numbers. A decimal digit has ten possible values 0, 1, 2, ... , 9. So to find the number of decimal digits to make 2^2048 distinct number we need to solve

2^2048 = 10^n

Take a logarithm (base 10) on both sides to get

2048 log(2) = n log(10)

I.e.

n = 2048log(2) = 616.5

which means you need 617 digits.


Recommended level of password complexity for Keepass

Let's first establish clearly what should be a common sense truth: A password manager master password is a very high value secret. (This is irrespective of which password manager you are using.)

This is for a rather simple, fundamental reason: this one password, together with the encrypted password database that it protects, essentially allows full access to every account for which you have credentials stored within that database.

Thus, you should ensure that this password has a corresponding level of security. Traditionally, this has led to the use of weird password schemes which have tried to combine the goals of making passwords memorable as well as making them secure. With today's computing resources, that's just not a practically achievable goal with a simple password any longer.

Instead, I like to recommend Diceware style passphrases. (Diceware is similar to the scheme described in XKCD 936, but more explicit on how to gather the randomness. Also, in Diceware, if the generated sequence of words makes sense linguistically, you are actually supposed to start over.) In proper Diceware, you use a random physical process (throwing physical dice) to gather randomness, then convert that randomness into words by looking up the numbers in a list of words. In the specific case of Diceware, you use five throws of ordinary six-sided dice to generate about 12.9 bits (log2(6^5) = log(6^5) / log(2) ~ 12.92481... bits) of randomness per word. While for reasons of physics regular play dice tend to not be perfectly fair (produce every value with equal probability), if this is a concern to you then it is possible to buy "casino dice" that are perfectly fair; however, the error is likely small enough that a single extra word accounts for any reasonable reduction in dice fairness, and you can easily test your own particular dice by making a reasonable number of throws and noting how many times each value comes up (which with perfectly fair dice and a large number of throws should be 1/6 the number of throws, because the dice is six-sided).

Since we normally assume that an adversary knows how you generated your password or passphrase but not the exact input or end result, this means that the adversary knows that you generated it using the Diceware method and dictionary. They might very well even know the length of your password.

Given those assumptions, we can actually directly calculate how difficult a Diceware passphrase is to guess: For a properly generated Diceware passphrase, each word corresponds to something very close to 12.9 bits of security. For a reasonably well generated passphrase using ordinary play dice, this is probably a little less simply because all values are not equally probable.

For a high-value password where an offline attack is a feasible mode of attack, such as that to a password manager, I'd probably want at least 90-100 bits worth of security. 100 bits worth of security using Diceware needs eight words. (100 / 12.9 ~ 7.752, and round upwards.) Since the average Diceware word is about 4.2 characters, and you need a separator (conventionally a space) between them, this means a passphrase giving you about 100 bits of security becomes approximately 41 characters long. (8 x 4.2 characters, plus 7 separator characters, is 40.6.)

For comparison, this is less than twice the length of your example ireallyhatebluemountains (which clocks in at 24 characters) but, as also illustrated by the other answers, is far more secure in practice and not much more difficult to remember. Your example password would essentially need to be generated completely randomly for it to have similar security (100 / log2(26) ~ 21.3 characters to get to about 100 bits: log2(26^21.3) ~ 100.12).


Are there any working proof-of-concept string comparison timing attacks?

Your example isn't working for several reasons, chief of which is the fact that you're using the best possible case data (i.e. least likely to display differences). If the difference in the strings was at the start, the early-out comparison should alert you. However, since you're using a JIT language, there are all sorts of weird possibilities that might hinder such a check.

The best way to demonstrate this type of attack is not with loops, but with a single measurement in a low-level language such as C.

Here's a quick example that works very well:

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <time.h>
using namespace std;

// this is just strcmp() wrapped in timer calls
bool CheckEqual(char* a, char* b, bool show)
{
    int i, r, trv;
    long time_pre, time_post;
    struct timespec ts;

    if((trv = clock_gettime(CLOCK_MONOTONIC,&ts)) != 0) {
        printf("Timing error, pre. Code = %d\n", trv);
    }
    time_pre = ts.tv_nsec + (ts.tv_sec * 1000000000L);

    r = strcmp(a, b);

    if((trv = clock_gettime(CLOCK_MONOTONIC,&ts)) != 0) {
        printf("Timing error, post. Code = %d\n", trv);
    }
    time_post = ts.tv_nsec + (ts.tv_sec * 1000000000L);

    if (show)
        printf("Time: %ld\n", time_post - time_pre);
    else
        printf("First compare done.\n");

    return r == 0;
}

// this function helps us avoid the problem of the compiler being too smart.
// if we were to use string literals that were equal, it'd optimise compile-time
// constant strings into a single instance, so strcmp() would just early-out on
// the fact that the two pointers were equal, which is not what we want to
// demonstrate here - in reality we'd be comparing buffers that aren't static.
char* MakeStr(char c, int n)
{
    int i;
    char* s = (char*)calloc(n+1, sizeof(c));
    for(i=0; i<n; i++)
        s[i] = c;
    return s;
}

int main()
{
    // equal apart from last
    char* aa = MakeStr('0', 64);
    char* ab = "0000000000000000000000000000000000000000000000000000000000000001";

    // equal apart from first
    char* ba = MakeStr('0', 64);
    char* bb = "1000000000000000000000000000000000000000000000000000000000000000";

    // inequality in the middle
    char* ca = "0000000000000000000000000000010000000000000000000000000000000000";
    char* cb = "0000000000000000000000000000001000000000000000000000000000000000";

    // equal
    char* da = MakeStr('0', 64);
    char* db = MakeStr('0', 64);

    // first call to strcmp() and time functions will result in cache misses
    // so we call it once and don't display output to account for that.
    CheckEqual(aa, ab, false);

    printf("Equal but last, ");
    CheckEqual(aa, ab, true);
    printf("Equal but first, ");
    CheckEqual(ba, bb, true);
    printf("Equal but mid, ");
    CheckEqual(ca, cb, true);
    printf("Completely equal, ");
    CheckEqual(da, db, true);

    free(aa); free(ba); free(da); free(db);
    return 0;
}

Your output should look something like this:

First compare done.
Equal but last, Time: 345
Equal but first, Time: 229
Equal but mid, Time: 234
Completely equal, Time: 270

Notice the large difference between the first two? This is due to early-out optimisation, whereby the comparison exits as soon as it finds a difference. In the second comparison, it takes less time because the first character comparison shows it's not equal, so it can return early. In the third comparison, we see that this goes a little further into the string, resulting in a slightly longer runtime than the "equal but first", but shorter runtime than the "equal but last".

The completely equal one is an interesting beast. I'm guessing that, when the last character is not equal, there is some additional required logic. In comparison, the completely equal one takes less time, I assume because it just has to return 0.


Sounds like you could probably do a Diffie Hellman to create a temporary session key and use that to symmetrically-encrypt the communications.


Preventing Client PC's from accessing C&C machines

You can't, not without imposing an unwarranted intrusion on people's ability to get work done.

You could turn off all networking (or forbid all outbound connections), but then no one could get any work done.  Not a helpful solution.
While it might be possible to build a blacklist of known C&C servers and prevent machines from contacting any server on that blacklist, this is not likely to be a useful defense.  Where would you get that blacklist?  You're not gonna compile it on your own; this stuff changes too fast.  And if someone has analyzed the bot software to identify the C&C server, they've probably also identified it to find a fingerprint that can be added to anti-virus software.  So I would expect any bad stuff that's blocked by this defense to already be recognized by anti-virus software.   In short, I don't think this offers much value over just running anti-virus software.

In conclusion, I don't think this is a promising direction to solve your malware woes.

I think it's a better bet to focus on standard practices: automated backups, bring everyone up to the latest version of the OS and software, turn on automatic updates.  For Windows users, get them on the latest version of Windows (XP must die), give them a modern browser, uninstall Java, Quicktime, and other unnecessary software (unless they need it), and give them antivirus software.  If they get infected, wipe and reinstall their machine and give them some quick informal, impromptu security training (e.g., about clicking OK on dialog boxes). Also, Secunia PSI can help you keep your users' software up to date on the latest security patches.


Sites don't generate fingerprints. They are artifacts created by the small differences between devices. Javascript code on the client can probe those small differences and create a list of factors, and that list can be unique. If multiple sites share this uniqueness table, no matter if you clear cookies, you will be identified.

For example, your browser. The combination of version, plugins installed, screen resolution, OS, available fonts and a couple other factors are more or less unique. Sites like https://amiunique.org/ and https://panopticlick.eff.org/ will show you how unique you are, and the information they used to detect how unique you are.

Nobody have to ask Google to generate it. Nor ask Chrome. Just toss a special Javascript on the page, and every browser will more or less generate a fingerprint, the difference is the amount of data the browser will give.


In the context of ssl/tls a CAs main job is to assure the client that the server the client is connected to is the server the client intended to connect to. In some cases it may also be used to verify other things.

Understanding this and understanding your clients is key to understanding when you should create your own CA. You need to ask yourselves some questions.

Will your clients be using generic software or will they be using software you provide?
If it's generic software does it expect to use a system default list of CAs or does it expect an explicit CA to be configured?
Will your clients be on machines you manage?

Once you do this you can assess the pros and cons of using the public CA system or a private CA in your particular context.

Often you will have little choice. Take a public website for example, your clients are using generic software, on machines you don't control and which they will not be prepared to do special configuration of for your site. You have basically no choice but to use a widely recognized public CA.

At the other extreme take something like openvpn. It fully expects you to use your own private CA as a means of identification and access control. Trying to use it with a public CA just wouldn't reasonably work.

A middle ground might be a website for internal use only. Using your own CA here would bring advantages, you could issue certs for internal-only hostnames and you wouldn't be dependent on any external party to issue certs. However it would also bring disadvantages, you would have to install your own root in the main trusted root stores on clients. Getting your root cert into the trusted root stores on the clients may be a pain if you have unmanaged machines around. Having your cert in the trusted root stores would also mean it could be used for MITM attacks on your clients, so you would need to keep the root (and intermediate if applicable) certs under very close control.

Or moving to the software development side consider a program with an auto-update system that relies on tls for security (not a design I would recommend). If you use a public CA on the server and the operating systems default CA list on the client then anyone who can persuade a public CA to give them a cert for your domain can MITM your updates. On the other hand with a private CA the attacker would need to compromise your internal certification infrastructure.


SIP Provider stores credentials, is it required for some SIP phones?

Usually you have a constant realm and in this case HA1=MD5(username:realm:password) could be stored instead of the password. But, if the password is only used for the SIP account, it actually does not matter if within a attack against the provider username and password get seized or HA1 instead, because the latter is all it needs to authenticate as the user. The storage method only matters if the account is used for other things or if the password is used for other accounts.


Security RESTful web application in Java

Based on the limited information:

At a minimum your looking layers of security you trying to accomplish.

We'll call this the DMZ. This is the layer that Application A is accessed at, or more simply put, the point of entry for your setup. You don't want anyone beyond this point.
The next layer is the backend. This is your application B and you are trying to restrict the access to this application only through Application A.

At a network level, your best option is through white listing of IP's/Domain Names. If you truly are just in development, and you basically trying restrict users/ other devs from messing with a system that's no ready, simply while listing at your servers FW will probably be sufficient.

You don't need to have a FW in between for something this basic (unless your development demands a certain level of protection upon which I would suggest no using these forums and hire a professional. This place is great for information, but specific engagements shouldn't be done here)

You should know the IP and Ports that Application A and B talk on which is what you want to white list.

If/when you push this into production I would make a few suggested changes.

Depending on your level of required security, use a dedicated firewall to separate your DMZ from the backend (Your organization may have this already).
Use Third Party Signed Certificates, I believe the current best practices are Minimum Key length of 2048, SHA2 signatures, running on TLS 1.1 or greater.
Secure the at the server level. Set your group permission properly, etc for the application. (I am not including actual server security recommendations, but that should be a given).
Know you DMZ access level, and internal application doesn't need to be access by external IPs, and you IT team should know what IP scheme they use and if they are really on the ball, they'll know what IP range will be accessing the application for the dedicated user group.


SSL for only parts of a website... How does it work?

When you access http://www.amazon.com and click Login, it redirects you to https://www.amazon.com which is secure.

Note: This is susceptible to sslstrip and they should be forcing SSL/TLS using HSTS.


How to Generate Custom Dictionary For this Password Structure

This is not exactly what you want but it is a close approximation of it. It will take a random word from 5 letter word list and 6 letter word list and output all possible 4 digit combinations in between the words and print it to a file, ready for further use.

You can repeat this as many times as you like and save all these files as dictionaries or even merge them if you wish to do so. Also this will save your computer from choking itself to death, both space and performance wise.

A python script:

import sys

orig_stdout = sys.stdout
f = file('pass_list', 'w') # Specify the name and path of the output file.
sys.stdout = f

import itertools
from itertools import product
import random

digits = '0123456789' # Set the digits.

prefix = open('5-letter.txt').read().split() # Specifiy the path to 5 letter word list.
first = random.choice(prefix)

suffix = open('6-letter.txt').read().split() # Specifiy the path to 6 letter word list.
last = random.choice(suffix)

for keygen in itertools.product(digits, repeat=4): # Specify the length of the digit combinations.
print (first+ ''.join(keygen)+last)

sys.stdout = orig_stdout
f.close()

Note: Both of the input .txt files need to have one word per line in order to work this properly.

EDIT: I would like to add that you may print out a bigger file if you want but know that chances are, although very slim, that prefix and suffix words will be repeated in the output file. Here is how you can modify the code.

prefix = open('5-letter.txt').read().split()
a = random.choice(prefix)
b = random.choice(prefix)
c = random.choice(prefix)

suffix = open('6-letter.txt').read().split()
x = random.choice(suffix)
y = random.choice(suffix)
z = random.choice(suffix)

for keygen in itertools.product(digits, repeat=4):
print (a+ '' .join(keygen)+x)
for keygen in itertools.product(digits, repeat=4):
print (b+ '' .join(keygen)+y)
for keygen in itertools.product(digits, repeat=4):
print (c+ '' .join(keygen)+z)

Not very pretty but it gets the job done. However, as stated above, chances of duplicate increase with repetition. And the bigger the file, the more annoying is to manually edit it.


Do I need to keep production Docker/container images?

At the moment there are no specific PCI guidelines for container based deployments (Although it is mentioned in their cloud guidelines), and I'm not aware of any specific requirements around image retention. There are some guidelines in development, but they've not been released as yet.
It might come up in relation to incident response/forensics, but realistically I'd expect more emphasis to be placed around audit logging at the container, runtime and orchestrator level. Retention of images doesn't really make a huge amount of sense, even there.


Backend Authentication of Mobile App: Session ID vs. OAuth

Oauth is an authorization system, not an authentication system.

OAuth is intended to provide secure access to a resource by a third party. For example, there are applications that allow you to schedule posts to various social media platforms, such as Facebook and Twitter.  These applications will store your posts then, at the scheduled time, make a post to that system on your behalf, without having your credentials.

Another common use is, if you are a third party, such as an information scraping tool that is set up to look like a "What color pocket lint matches your auras" poll, such apps will be given some identifying information about you, such as your name and user ID (and possibly a LOT more, if you don't check the permissions carefully.)  These provide a round-about identification system, that can sometimes stand in place of authorization, if you trust the OAuth provider.  That is, there is no way to prevent this OAuth provider from lying to you about the identification; an admin for the provider could claim to be one of your users and you would have no way to know for certain, if you use their OAuth service as authentication.

If you want to identify users of your mobile app, you could have a "Sign in with [social media platform]" option using OAuth.  This can decrease some of the friction of signing in, compared to using a username and password.  Just keep in mind that, in this case, you're not the one authenticating your users.

As far as authenticating a user with a normal username and password in your app, and having a session ID passed with each request; this is how most sites work.  The OWASP cheat sheet on session management goes into details, but the general best practice can be summed up as:

At least 128 bits (16 bytes, 22 printable Base64 characters) long.
Generated with a cryptographically secure PRNG.
Does not represent anything except the session ID (don't include the username).
Before authenticating, switch to TLS. Never use an authenticated session in non-TLS.
Cookies may not apply to you, unless you're using a browser, but if they do apply, must have the Secure, SameSite, and HttpOnly attributes with properly configured (and not too permissive) domain and path attributes.
Recycled on privilege level change (login, logout, changing password).
Idle timeouts and maximum timeouts.

Since you are writing a mobile app, you have some more assurances that many web developers don't have. You do not have to rely on cookies for storing your session IDs, so you can get away with having two tokens; a short term session token for your API access, perhaps valid for a few hours, and the other (a "refresh token") to request your short term tokens.  This refresh token should be much higher entropy than a session token. In any case, 256 bit tokens will protect against brute force attempts until the heat death of the universe.

You can also use this refresh token as a shared secret, rather than a simple ID like the session ID is. When negotiating a new session ID, you would send some random bytes to the client. They will append these bytes to their refresh token, and calculate a hash based on that, and send the result back.  You then compare what they sent back with what your server expects (after doing the same hashing of the refresh token and your nonce). This proves that the client has the correct refresh token, without sending the refresh token over the network.

With this system, an attacker who performed a successful Man-in-the-Middle attack can only hijack a session for as long as you haven't recycled your session IDs, and users will not need to re-authenticate constantly, for as long as the refresh tokens are valid.


Is this explanation about how SSL Certificate Signatures work correct?

There indeed is no negotiation, but the quote is still mostly correct.

The certificate is simply static. If you have the certificate file and openssl installed, you can see exactly what it contains with this command line:

openssl x509 -in <crtfile> -noout -text

The same information is also available within Web browsers, but you have to be a bit careful; using openssl is better. What the Web browser shows you isn't as raw as what openssl shows you, and the Web browser will add some additional information that is derived from the certicate. In particular, you may see both an SHA1 and an SHA256 fingerprint - don't get confused, those are not in the cert itself.

When you look at the signature within the certificate, you will usually only see one signature, and that will obviously be the one that is being used - if the client doesn't support that signature algorithm, there is nothing they can agree on, and that's the end of it. If the client does support it, then it can immediately start using that certificate.

It is also conceivable that a certificate contains several signatures using different algorithms (although I don't think the certificate format actually supports that; this idea would be only theoretical), but even then, the same would still hold true.

So, the "negotiation" basically consists of the server sending the certificate with the signature algorithm and telling the client "here it is, take it or leave it".


How to ensure file integrity cryptographically?

A simple solution would be to store the checksums in a digitally signed file at the same location.

As long as you retain control of the private key used for signing, you can easily verify the integrity of the whole set of files without having any access to that key.

Something like this is trivial to implement with PGP.


emailing a direct link to executable file blacklist risk

From my personal experience it would be better do send a link to a webpage where the user has to download the software by cklicking on a download link/button. There are many spam/ malware filters for mail out there blocking mails with direct links to software.

I encountered this many times trying to get updates of our software to various clients. Now we made a downloadpage with doesn't include the strings '.exe', '.msi', '.zip' and many others. Since then we don't have problems with filters any more.

Also it offers another level on security because we have secured the downloadpage with  username and password, so if one of the emails is read by some third party they still can't simply download the software. But as I don't know exactly what you are trying to do, this may not apply to you.


Security of starbucks gift card redemption feature

As far as I can tell, the idea is that even if the URL is leaked to somebody who's not you, your gift card is still protected.

Sure, it's fairly rudimentary especially since email addresses are by no means private, but generally theft of Starbucks gift cards isn't something a lot of people who could easily bypass the email validation would take part in.

And it probably makes people who aren't very security minded feel more secure.


Specifying my key name while encrypting file to some receiver using GnuPG

There is no need for your own key when encrypting message to other recipients: only the recipient's public key is required.

There would be two scenarios though requiring to denote your own key: signing messages (which is an operation involving your own private key) and adding yourself as another recipient, consider encrypting mails also stored as encrypted copy in your sent mails folder. You wouldn't be able to read your own messages any more, if the only encryption key is the recipient's one. There is the --encrypt-to  option in GnuPG, which allows you to define additional keys to encrypt for.


Convincing the boss about the importance of privacy and security

if your compagny is working in Europe, tell him that in May, the GDPR will be launched and every company which have a leak of personnal data can suffer law pursuit and penalties around 4% of the world incomes.

More specifically, being a little structure was pretty safe years ago. But today, most of the hackers are targeting small structures (because they are not secure) to launch ransomware or to do bitcoin mining (which can cause your servers to be dead quickly and your electricity invoice to be scary).

most of the time, during a governance audit, I ask:

What is so sensitive that you cannot loose it?
The emails
... no, not the emails, if you loose the exchange server is disturbing but your company still exist
hummm
what if you loose your ERP?
loosing the ERP ?
Everything, the invoice, the contacts, etc. Imagine someone breaks this server
ho no don't do that, without ERP we don't know who must pay us, what we have to deliver, it's critical
yes it is. Okay so you have the impact. What is the likelihood ? The ERP is not quite secure because the password is bad, so if someone try to break it, he will suceed
yes but noone will attack us
this is the last point: the occurence. How often someone will want to disturb you (evil employee, former trainee, hacker)? Can you really say never ? I don't think so, never does not exist. One time every 7 years ? Okay it's not often...but when it will come, you loose your entire company. How much your company is valued ? 1 000 000 ? Okay so your security yearly budget is 1000000/7: 140k


Is this non-cookie based session scheme horribly vulnerable to some attack?

KISS -- Keep It Simple, S___ (fill in what you will).

Pass only a session id to the client. Verify that session ID on the server side. The server should map out who the session id belongs to. The server should be responsible for expiring that session ID.

Under your current system, it is unclear whether a user can change their identity by changing the username. It is also unclear what will happen if they alter the timestamps.


Why do we need IDS/IPS if a firewall is present?

Functionally, they are two different applications, but they are often meshed together because the monitoring process tends to be at the edge off the network. Many times you see UTM (Unified Threat Management) which are firewalls with IPS/IDS services integrated as a subscription.

Firewalls serve to control the inbound/outbound connections into an environment based on static rules (Stateful Firewalls). Your more advanced firewalls can work up at the application level (Application Firewalls), which is why at some companies you can browse FB, but not play any of its games.

IPS/IDS serve to monitor connections for malicious activities mainly through signature based detection (similar to AV). Attacks have certain patterns and depending on your setup you can be alerted or have the system take action on those patterns.

You can generalize it, I suppose, to firewalls limit the types of connections you will allow into the network based on static rules, and IPS/IDS monitor those connections for malicious activity based on signatures and understanding of attacks.

As CoverosGene and Xander said, it part of using Defense in Depths, but technically they're two different services that tend to operate in tandem.


Yes and there are several reasons to do so.

Firewalls like other computing devices occasionally have security flaws which need to be patched. If you were to think of two firewalls or firewall pairs (one behind the other) as two layers of defense if the first layer had an issue and was able to be bypassed the second firewall would be able to prevent outsiders from gaining access to your network.

Likewise different types of firewalls can process different types of attacks at different speeds. Hardware-only style devices tend to process packets at a much faster rate than software firewalls but they don't process or block packets as deeply whereas other types of firewalls can block a much larger number of types of attacks because they do inspection either for more items or cover more of the communications that are being filtered. If a client were to deploy both of these they would want the hardware firewall internet-facing to block the largest number of attacks and then have the software firewall behind it blocking attacks at a deeper layer.

Take this a step further and we have specialized Firewall devices such as Web Application Firewalls (WAFs) which only do filtering on http and https. These are almost always used in conjunction with more traditional firewalls in front of them.

Likewise in a cloud environment it is not uncommon to use a primary firewall in front and also run firewall software on each of the computers in what's known as a Zero-Trust model of firewalling which is also effectively two layers (or more).

Note: Zero-Trust firewalling does not have to have a separate firewall in front this is simply a common deployment pattern I see especially in AWS environments.

Finally to dispel said "rule": You can use two software firewalls like IPTables and mod_security (essentially a WAF) on one computer or even have IPTables forward incoming traffic to a second software firewall for further inspection for things like Data Loss Prevention (DLP) or for advanced malware or application filtering. The use of the second software firewall as a WAF is actually very common for people who run software WAF's.

That said having two software firewalls is not common in traditional computing but it's a very legitimate way to add good security controls to a system and as long as you are adding unique security controls into each layer and not negatively impacting your applications I would say it's very wise to do so.

In regards to having a hardware firewall behind the router. This is very similar to how all businesses have their own firewall behind their router and have access-lists on the router. All companies need to secure that external router so effectively almost all companies effectively do have two layers of firewalling even if one is more actively used than the other. I do this myself because the ISP has access to the network router in my house and I don't trust the ISP to secure it. This is very common in business and semi-common for home routers amongst people in the know about security.

You don't get Defense in Depth from a single layer so having a second layer is always wise and I think it would be wise to question this "rule" you mention about one firewall.

BTW: I once saw a bank that used three different pairs of firewalls in a row for it's Internet-facing banking application.

Useful links for comparison:

https://en.wikipedia.org/wiki/Comparison_of_firewalls

https://en.wikipedia.org/wiki/Application_firewall

https://www.modsecurity.org/


Why does OpenVPN have reneg-sec on 3600?

Shorter key lifetime = less time for an attacker to a) capture known-plaintext packets and b) somehow crack the key. Also, a leaked key will only help an attacker gain access to your communication for 1h instead of a day.

So, damage control, essentially.


How can I spoof the Mimetype of a file upload?

If you were creating the header on the upload request programmatically, you can declare the headers, etc. An explanation which includes some code samples.

You should go beyond the mime type and check the content. E.g., if you allow an image upload, do a conversion of the image on the server and do other checks as well.

You may want to check out this post on SO:

  The "signature headers" help you to decide what kind of image format a
  file tries to impersonate. In a next step you could check if the rest
  of the contents are compliant with the underlying image format. This
  would guarantee you that the file is really an image file of that
  specific format.

You may also be interested in this article on GIFAR:

  They call this type of file a GIFAR, a contraction of GIF and JAR, the
  two file types that are mixed. At Black Hat, the researchers will show
  attendees how to create the GIFAR while omitting a few key details to
  prevent it from being used immediately in any widespread attack.

  To the Web server, the file looks exactly like a .gif file, however a
  browser's Java virtual machine will open it up as a Java Archive file
  and then run it as an applet. That gives the attacker an opportunity
  to run Java code in the victim's browser. For its part, the browser
  treats this malicious applet as though it were written by the Web
  site's developers.


Unfortunately, we can’t analyze your malware from out here. Sounds like that link may be pretty sketchy, but we can’t say one way or the other. If you’re super curious to know more, one pretty common technique for analyzing malware is to download and execute it in a VM. If you do that, obviously be careful to configure everything properly and keep a firm sandbox. Good luck!


Security risks of using SQL Server without a firewall

There are many vulnerabilities associated with database management systems. Basic security issues include:

Deployment security issues.
Application level (DBMS) security issues.
Abuse of database features
Zero day attacks
Data leaks

When your application is developed, another attack surface will be added to your database.
You can avoid brute-force attacks by using a strong password. But preventing against DDOS is somewhat difficult.
You can show them the risk associated with the system and have them sign to agree to this risk, if they cannot afford to mitigate the risk. But accepting a huge risk is also not acceptable.


Is there any merit to the idea of certificate viewing software showing a gravatar/identicon for the hash of an SSL certificate, to aid in identifying it?

Yes. At least with OpenSSH this has been done. I don't see why it wouldn't work with SSL as well. But I know of no (live) implementation. There was a thesis from 2004 that showed an implementation of this for Mozilla, but I don't think it was more than a proof of concept. (See "Further reading" section.)

OpenSSH calls these images "RandomArt", "SSH Fingerprint ASCII Visualisation", "Visual fingerprint", "Visual Host Key". They have been there since version 5.1 from 2008. But I've only ever seen these images when creating a new key. Not when actually using one with ssh. (And that's because it's off by default on all ssh clients I've come across. You need the -o VisualHostKey=yes option.)

Further reading

SU:What is randomart produced by ssh-keygen?
Sec:How secure is Visual host key, and how is SHA2 converted into that representation?
Hongxian Evelyn Tay, Carnegie Mellon University, 2004-05-03, CS Senior Honors Thesis: Visual Validation of SSL Certificates in the Mozilla Browser using Hash Images


How can I limit the consequences of a possible future identity theft?

The best thing you can do to help minimize damage if one of your online accounts gets hacked is to make sure that none of the information in that account can be used to get into one of your other accounts. Say you use the same username and password for multiple accounts, if one of those accounts is hacked it will compromise all your other accounts. You can minimize this risk by:

using different passwords for every account
use different usernames for every account
use different security questions and answers for every account

Also, these are good practices:

Have all your credit card details and emergency phone numbers recorded so you can get them cancelled and re-issued if an account containing your card details is compromised
Keep a list of all your online accounts, monitor them if one of your accounts is compromised


Is there any benefit to spammers oversaturating a service?

Spammers will use as many resources as possible and attack websites relentlessly, to the point where the service is no longer usable. With no real users to be tricked and the spam being so blatant that it can't possibly trick anyone, why would they waste resources doing this?

There are a couple of reasons why websites will get massive amounts of spam attacks. More than likely, it's because there are a lot of spammers. There are many, many companies out there dedicated to creating illegal spam bots and flooding the web. Many of them just happen bombard the same place.

If it is a sudden, out-of-nowhere spike in traffic that crashes the service than it could be an attempted attack to gain access to the system, or it could be a DDoS attack. This means someone or some organization is trying to compromise the system, rather than utilize it for promotional purpose.


Why does Gmail (add accounts) using SMTP server recommend SSL instead of TLS?

From that link:

  Select a secured connection

  Check with your other mail service for their recommended port number and authentication type.

  Here are some common combinations:

  SSL with port 465
  TLS with port 25 or 587

The difference, then, is that "SSL" means SMTP over SSL-or-TLS on port 465, and "TLS" means SMTP with STARTTLS on port 25 or 587. So what's the difference between them?

STARTTLS is opportunistic encryption. The connection starts as plaintext SMTP, and the client tries to initiate encryption if the server says that it can. The problem with this is that the plaintext negotiation can be relayed and modified by a Man-in-the-Middle attacker, exactly the way that sslstrip works for HTTP redirects and links to HTTPS.

SMTP-over-SSL, on the other hand, starts with a SSL (or TLS--the exact protocol is negotiated) connection, then SMTP is conducted over that tunnel. With this configuration, the client always expects to use SSL, and can't be tricked into going plaintext.

So the SSL-or-TLS naming is not the real issue. Google is using "SSL" to mean the older "smtps" standard, which is actually more secure in this case. In reality, the service is probably using TLS, and Google's mail servers will negotiate the most secure connection possible, depending on the other service.

EDIT: As @Mehrdad points out in the comments, Google will change which option is "recommended" based on the port number that is selected in the dropdown. This shows that their recommendation is not based on higher assurance of encryption, but on what is most likely to work: port 465 is registered with IANA as 'smtps', and is expected to be SMTP-over-SSL. Ports 25 and 587 are 'smtp' and 'submission' respectively, and are expected to be plaintext. Since I doubt that Google will refuse to send mail over these ports if STARTTLS cannot be negotiated, "TLS" remains the weaker, opportunistic option. It is, however, more likely to be supported than port 465.

EDIT 2: @grawity did the legwork and determined that Google does not, in fact, fall back to plaintext SMTP if STARTTLS is not supported. You have to explicitly select the "Unsecured" option when configuring the server. This is really good work by Google to ensure transport security for emails. Of course, all that has been said already about STARTTLS remains true: it requires this extra step of making TLS a strong requirement to avoid downgrade attacks.


FIN Attack- What is this type of attack really?

It's an older attack originally intended to be a "sneaky, firewall bypass" that was dependent on a few factors that are now uncommon today: old Unix OSes, lack of stateful firewalls, lack of NIDS/NIPS, etc. It can still be useful when testing (i.e., as a fingerprinting technique not an attack per se) completely new or novel TCP/IP stacks (or just new to you or your environment), which is rare but can happen.

Here is a modern replacement, the TCP protocol scan:

nmap --reason -n -Pn --packet-trace -g 80 -sO -p 6 <target ip>

Which is almost exactly the same as the TCP ACK scan (which can be used to map hosts, open ports, firewall rulesets, etc with the caveat that some NIPS, IDS, and modern firewalls will detect -- with another situation-specific event where perhaps it will not notify incident responders or Security Operations Centers because they have more important things to look at these days):

nmap --reason -n -Pn --packet-trace -g 80 -sA -p 80 <target ip>

But the outputs are slightly different and you can see the other packet-level differences as well.

What you are looking for in order to develop a more advanced technique is to identify the subtleties in the RST packets and their window sizes. If you get non-zero window sizes, then you may want to switch to using the TCP Window scan instead of the TCP ACK scan. For more information, see http://nmap.org/book/man-port-scanning-techniques.html

Some other techniques are found in the NSE guide, such as the firewalk and firewall-bypass scripts. However, there are many other techniques including BNAT, fragroute, osstmm-afd, 0trace, lft, and potentially others that detect other inline, non-firewall devices such as WAFs, IDS, IPS, reverse proxies, gateways, and deception systems such as honeypots or active defenses. You will want to be aware of all of this and more if you are performing a network penetration test, but they come in handy for troubleshooting all sorts of network and security issues.


Finding an up to date website with detailed information on viruses

It sounds like you are interested in something similar to the National Vulnerability Database (NVD), except for malware.  I am not sure such a thing exists, but here are some similar repositories:

http://home.mcafee.com/virusinfo/
http://www.microsoft.com/security/portal/Threat/Views.aspx
http://www.virustotal.com/search.html
http://about-threats.trendmicro.com/threatencyclopedia.aspx?language=us&tab=malware
http://www.f-secure.com/en/web/labs_global/threats/descriptions
http://www.sophos.com/en-us/threat-center/threat-analyses/viruses-and-spyware.aspx

Perhaps it would be a good project to stand up a site that  queries all of these repos and provides results from all of them in one place.


Is it risky to use an untrusted keyboard?

I think you have answered your own question :) Purchasing hardware from any untrusted supplier carries risks. The company I work for has a designated hardware supplier for peripherals (And other hardware) to help mitigate against this risk (amoungst other controls).

There have been incidents before where keyloggers have been installed on keyboards, see https://thehackernews.com/2017/05/hp-audio-driver-laptop-keylogger.html

Avoid if possible & if you are unable to avoid then make sure you have the necessary security controls on the device before plugging in, better to be safe than sorry.


How does ssh public key authentication work?

In brief:

SSHv1: The server encrypts a message using a public key stored in authorized_keys, the client has to decrypt it and return it's checksum (modified by a session ID)
SSHv2: The client signs a message (depending on the session ID) and transmits the signature and message (without the session ID) including the public key used. The server then prepends the session ID and verifies the signature (provided the public key is actually in authorized_keys)

The document PROTOCOL.agent summarizes this:

Protocol 1 and protocol 2 keys are separated because of the differing
cryptographic usage: protocol 1 private RSA keys are used to decrypt
challenges that were encrypted with the corresponding public key,
whereas protocol 2 RSA private keys are used to sign challenges with a
private key for verification with the corresponding public key. It is
considered unsound practice to use the same key for signing and
encryption.

Here's the SSHv2 relevant section from RFC 4252:

To perform actual authentication, the client MAY then send a
signature generated using the private key.  The client MAY send the
signature directly without first verifying whether the key is
acceptable.  The signature is sent using the following packet:
  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication
  string    signature

The value of 'signature' is a signature by the corresponding
private    key over the following data, in the following order:
  string    session identifier
  byte      SSH_MSG_USERAUTH_REQUEST
  string    user name
  string    service name
  string    "publickey"
  boolean   TRUE
  string    public key algorithm name
  string    public key to be used for authentication

When the server receives this message, it MUST check whether the
supplied key is acceptable for authentication, and if so, it MUST
check whether the signature is correct.


Hydra: Need to use information found in page source code

Hydra is limited in the inputs that it can process, just like any other program. If you want Hydra to work on a modified input, you will have to create an interface for Hydra.

Burp might be your friend in this. There are many ways that you can write plug-ins that you could use as a foundation.


Is it possible that the email itself deleted from John's inbox (he does not want to show me this though...)?

No, it cannot automatically delete from John's hotmail account. Maybe John decided not to take further action and deleted it and then changed his mind.

  He is also claiming that he could get this email from different address and easily manipulate the screenshot so it would show his adress.

That is true. It's also possible John made the whole thing up.

This is one of those situations where the truth is unknowable. Just mentally subtract 1 from the trust values of both of these guys and move on.


Unicode Technical Report #36 has some examples. In your case exploits that make use of ill-formed byte subsequences may be of interest.


Cannot exploit elasticsearch on Metasploitable3

Finally I got it. I was not explicitly setting the payload. Once I used java/meterpreter/reverse_http I got it through.


Prevent users from copying sensitive data

When someone can read data they can also copy it.
Preventing copying and/or distribution of data is an age old problem in the entertainment good industry. Data such as movies and games are protected via DRM (Digital Right Management).

If the project members look at the data from their work computer then it doesn't matter how well-secured the folder or the document editor is. They would still be able to use a phone camera to record their screen and/or use pen and paper to copy the information. Similar to how you can copy a copy-protected movie by recording your TV with a camera or video recorder. They might be able to remember the more interesting parts of the document which is also a kind of copy. Similar to hoe you don't need pen and paper in order to spoil your friends about a movie plot twist.

We could have a separate secured room which is guarded like a previous answer stated. But I assume this is too expensive and/or unpractical for your use case.

Your best option is to enforce the copy-protection via contracts instead of using expensive physical means. Let the people of the project sign a non-disclosure agreement.

(Please notice how I use "movie" as a consumer-grade anology to showcase that digital means of static content copy prevention only has marginal to none effect)


How does Team Viewer establish a Remote Desktop Connection?

To elaborate on ewanm89's post, TeamViewer does use UDP pinholeing.

UDP is a stateless protocol. This means packets are fired off at their target with no verification (at the protocol level) that they were received or even reached the destination. Firewalls are designed to look for UDP packets and record the source and destination as well as the timestamp. If they see an inbound packet that matches an outbound packet they will generally allow the packet through even without a specific rule being placed in the firewall's access list. This can be locked down on enterprise grade devices, but in general 90% of the firewalls out there will allow return traffic.

In order to pin hole your machine (viewer) has a TCP connection back to the main TeamViewer server. The target machine (client) also has a TCP connection to the main TeamViewer Server. When you hit connect your machine tells the main server its intention. The main server then gives you the IP address of the client machine. Your machine then begins firing UDP packets at the client. The client is signaled that you intend to connect and is given your IP. The client also starts firing UDP packets at you.

If the firewalls are "P2P-friendly", this causes both firewalls (yours and the client's) to allow the traffic, thus "punching holes" in the firewall. Specifically, this requires the firewalls to not change the public port of an outbound packet merely because its destination has changed; the firewall must reuse the same public port as long as the source of the packet hasn't changed. If your firewalls don't behave in such a friendly manner, then this won't work. Many firewalls do behave this way, though.

Of course TeamViewer adds some security by doing a pin/password check before the main server sends the IP info to both parties but you get the idea.


What's the modp length of diffie-hellman-group-exchange-sha256?

A DH group is defined by a prime modulus and a generator. The prime modulus is a bit expensive to generate, so OpenSSH will not do that on a general basis. Instead, sshd will, upon receiving a connection, use one of the groups in the /etc/ssh/moduli files. That file contains pre-generated moduli of various sizes. You can use the one provided with OpenSSH, or generate your own with ssh-keygen; see the man page (there is no security issue in using the same group as other people, but nevertheless, for some psychological reason, some sysadmins experience a feeling of higher security when they generate their own moduli).

The actual selection process is, in OpenSSH source code, in the choose_dh() function in the dh.c file. Roughly speaking, if the client wants at least min bits, at most max bits, and preferably n bits, then the server will choose among the moduli in the min..max range; it will try to get the smallest modulus which exceeds n, and, if there is none, the biggest modulus it has (still in the min..max range, of course). If the server finds several modulus of the same "optimal" length, then it selects one randomly. If the server knows of no modulus in the min..max range, then connection fails.

The default /etc/ssh/moduli, at least on my server, appears to have moduli of size 1023 to 8191 bits.


How should I verify a caller is from the bank or company they claim?

I would refuse to give out any personal details to anyone that called me as you can't verify who they are.
If they need to talk to you then say you can call back. You can then call through on the direct number, which if it is a large bank will be well known and on their website. You could then ask for an extension number to direct your call once you know you are through to your bank.


nmap - "No exact OS matches for host (test conditions non-ideal)" even with 1 open, 1 closed port

Nmap fingerprints a remote system's operating system (more correctly, the OS's TCP/IP stack) by sending a series of probes and measuring the responses. These probes check for particular choices that the OS programmers made when implementing parts of the Internet protocols that are not as strictly defined as other parts.

There are several reasons why Nmap considers an OS fingerprint non-ideal, and it can be useful to know what they are and why they matter:

Scan delay is greater than 500ms - Nmap sends six probes in quick succession and checks to see how much the remote system increments certain counters. If there is too much delay between packets, then there's too good of a chance that someone else's packets were incrementing the counters instead. (-T2 sets a scan delay of 400ms)
Timing level 5 (Insane) used - -T5 can overwhelm a system or its network link, causing dropped packets and unpredictable responses, which lead to an unusable fingerprint.
Missing an open/a closed TCP port so results incomplete - Some probes are only sent to open ports, and some only to closed ports, so without one or the other, the fingerprint cannot be complete.
Host distance appears to be negative - This is a weird thing that can happen when a firewall is sending responses to blocked UDP ports. Any time a firewall sends a response to one of Nmap's probes, it makes the fingerprint less likely to match, since the responses will be a mix of good and fake.
Host distance is greater than five - The farther away you are from the target, the more likely there is some sort of packet filter or traffic shaper that is causing interference with Nmap's probes. Also, some of the timing stuff can be thrown off.
maxTimingRatio is greater than 1.4 - This is a measure of responsiveness to Nmap's probes. Nmap tries to send one probe every 100ms, for a total of 500ms between the first and the 6th probe. If it has to wait too long for any of them and the 6th probe is sent more than 700ms after the first, then we assume the timing checks won't be accurate.
Didn't receive UDP response. Please try again with -sSU - One of the probes sent is to a closed UDP port. If you didn't scan for UDP, then your fingerprint will be incomplete.

These reasons came from the Nmap source code, but you can see them when you run a scan with -v2 or -d.

Please note that "non-ideal" doesn't necessarily mean that you won't get an accurate fingerprint match. It just means that the chances are good that something will have interfered and caused a poor-quality fingerprint. In these cases, Nmap will not print an OS fingerprint for submission, since we don't want to clutter up the database with fingerprints that are "blurry."


Does OpenPGP encryption mean that not even I can see my data?

It's perfectly true. Encrypting an e-mail with someone public key, you get as output a ciphered text that you cannot decrypt yourself, this is the point of asymetric cryptography after all.

There are many methods to keep the original text.

keep it as clear-text
encrypt it with your own public key (to keep confidentiality)


Is AES vulnerable if the plain texts share a known format?

Any modern encryption method is secure against known-plaintext attacks, and even chosen-plaintext attacks. The only thing that is exposed by a ciphertext is its (approximate) length. The mathematical notion behind this is indistiguishability under chosen-plaintext attacks (IND-CPA for short); what this means in a nutshell is that if an adversary chooses two plaintexts of equal length and receives the encryption of one of them, the adversary is unable to tell which one was encrypted. The two plaintexts may have a common prefix, they may differ by as little as one bit. Computer-era cryptographic algorithms are generally designed to be robust in terms of what data they can process — the inputs can be any set of byte strings (up to a very large length limit).

This assumes that the encryption is performed correctly, in particular with a valid mode (such as CTR or CBC, never EBC) and proper IV selection (random each time a message is encrypted is always fine).

Note that IND-CPA is not the full story. Some attacks may be possible where the adversary submits chosen ciphertexts (that may or may not be valid) to the party with the secret key. An adversary may be able to obtain information by submitting variations of a ciphertext (even if they don't know what it decrypts to), having them decrypted, and observing the consequences (even if they don't get access to the decrypted output, they may be able to observe how long it takes, whether it triggers certain errors, etc.). Many systems built on cryptography actually require indistinguishability under adaptive chosen-ciphertext attacks (IND-CCA2). Protection against chosen ciphertext attacks requires authentication.

The best way to authenticate data, which protects against chosen ciphertext attacks, is to use an authenticated encryption mode. See Why should I use Authenticated Encryption instead of just encryption? for a more detailed explanation. Popular ones include GCM, CCM, OCB and EAX, CWC. Any of these five is as secure as it gets; see Choice of authenticated encryption mode for whole messages for other considerations such as performance. If you have to use a library that doesn't provide AEAD modes, you can combine a MAC with CBC or CTR, but doing it right is tricky; in 2017, I think that if your library doesn't provide AEAD modes, you should get a more up-to-date library.


Does rotating proxy provide better privacy?

does rotating proxy increase the difficulty to find your real IP?

No. Your "real IP" is either disclosed in some way, or it is not. If it is not, it does not matter how many proxies you pass through.

Multiple proxies may make more difficult to track your activity, i.e. establish that actions A and B were both performed by the same entity (for that, see fingerprinting, below).

It might be argued that the more proxies you use, the more likely that one of them will be compromised or misconfigured and will leak your address. In this case the likelihood is low because all proxies will probably be centrally managed.

On the other hand, by using cookies and fingerprinting (you may want to google "panopticlick"), it becomes possible to mark all of your connections as belonging to the same user, let's call him "UNKNOWN-1".

Now knowing that UNKNOWN-1 is using fourteen different servers, if they are distributed around the planet, it is possible, using timing techniques, to estimate the distance (both in hops and in kilometers) between UNKNOWN-1 and each of those servers, albeit with a possibly conspicuous error margin.

If the proxies don't employ time fudging techniques, and chances are that they don't, it becomes possible to restrict your location geographically. Your real IP is still unrevealed, but you're less anonymous than if you used a single proxy.

There are also much more complicated techniques that cross-check your timing data with real-time network traffic status ("Internet weather"). They require resources, time, and a lot of traffic from your host to some monitored facility (even a single website might do). For example if I have restricted your location to somewhere in Southern Europe, if your connections through the Amsterdam proxy begin lagging when the route from Amsterdam to GARR is hosed, and you stop lagging when service is restored, my confidence of you being in Italy increases greatly. At that point I start monitoring service levels for Italian providers...


You could try OpenVPN running on UDP on port 53, 80, or even its default port.  Many firewalls are not configured to block UDP, and you can have both a UDP service and a TCP service on the same port number.

  Can configure my server so that it uses port 80 for apache if the
  requests comes from a specific domain and uses port 80 for my VPN
  server if it comes from another domain.

No.  The operating system doesn't know anything about domains, only IP addresses, protocols, and ports.  So when a packet comes in for port 80 on a certain IP, it looks for what application is listening for TCP on port 80 on that IP, and delivers the packet to it.  Only one application can be on any given IP/Port/Protocol set.

If you had multiple IPs, you could run your VPN on one IP and the webserver on another IP.  Otherwise, ports are what are used to distinguish between applications.


Does using unicode or (at) actually stop spambots?

Some spam bots, yes.

All spam bots, no.


Is is possible to create a "signature" for a piece of JavaScript

Not a signature, however a Content Security Policy allows you to whitelist JavaScript for execution in your page
by including a SHA-256, SHA-384 or SHA-512 hash.

e.g. to allow <script>alert('Hello, world.');</script> you would include the following HTTP response header:

Content-Security-Policy: script-src 'sha256-sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

Anything not matching would not be executed by supported browsers.

You can also use this to find out the expected hash of a script in development by opening development tools in Chrome and examining error messages on any mismatch.

It depends what you're trying to acheive - would a hash value be enough, or do you actually require a signature?


What should I watch out for when using pam_ssh_agent_auth?

We ship it and use it in Fedora and RHEL. It is here for a long time and it is using the code from openssh for almost all the public key operations (and openssh is using openssl). The code is quite fair.

The pam_ssh_agent_auth itself basically does only verification that the public key matches and that the signature provided by ssh-agent is valid. All the private key operations are still left on your ssh-agent.

It is not clear what is going to be your exact use case from this question, but from my POV, the most powerful thing on this is having single agent on local machine to log in to all the servers and allowing sudo operations there (or use separate key for this module). It exposes a bit "single point of failure" (if you lose the unencrypted key, it would be a problem, but this module does not expose it).

You should probably disable ssh-agent forwarding for untrusted hosts (or by default and whitelist your trusted), maybe also add the key with -c switch to confirm PK actions or some timeout (-t to let it expire).


root or Administrator access is usually required to modify the CA bundles. If an attacker has gained that level of access, it's game over. Defending against such a scenario is almost impossible as there are many other things the attacker can do.

Now, for the very specific case of SuperFish, browsers (and other applications) can push updates to reject that particular certificate, but that's only because SuperFish incompetently reuses the same certificate across all devices. A more sophisticated attack is much harder to defend against.


This is going to be an annoyingly trivial answer, BUT...

The only way to perform a Response Splitting attack on an updated ASP.NET (or MVC) server, is if the application itself is writing back raw HTTP responses.
Yes, of course no programmer in their right mind would do that... but in the case of the 60% of programmers that are not in their right mind, it is possible likely that such an implementation would be vulnerable.

Otherwise, no, the application is not vulnerable to HRS.


It's for DNS.  I'm going to go out on a limb and suggest you probably want to leave it that way.

http://www.networkworld.com/community/blog/allow-both-tcp-and-udp-port-53-your-dns-serve


How to disable typed arrays in firefox as rowhammer mitigation

There are no means to disable typed arrays in the browser. Much like you can't disable the use of 'img src' or 'a href' tags in the code.

What you can do however is prevent the execution of javascript via this method.

In Firefox

typed 'about:config' in the address bar
Click "I accept the risk" on the dialogue box that comes up
Type 'javascript.enabled' in the search section
Right click on 'javascript.enabled' and select 'Toggle'
You can then close the tab.

Firefox will not load javascript from then on.


How do Windows services access folders encrypted with NTFS EFS

Maybe BitLocker instead of EFS?

we have a server located at a remote location [...] stop anyone from pulling out the disks and making a copy.

Well, you could use BitLocker Full-Disk-Encryption and store the decryption key inside the mainboard's TPM chip. And set BitLocker to automatically unlock the volume on boot.
This would mean that a thief would have to steal the WHOLE SERVER and not just pull out a disk.
This BitLocker volume unlocking mode of operation is called TPM only.
Here's a blog article that lists the different modes:
Luis Rocha, Count Upon Security blog, 2014-06-23, BitLocker with TPM in 10 steps.
(Archived here.):

TPM Only: No authentication required for the boot sequence but protects against offline attacks and is the most transparent method to the user.

This would at least make any attempt to get at the key much easier to prevent/detect.


Is the HTTP TRACE method a security vulnerability?

One of the wisest security principles says that what is unused should be disabled.

So the first questions is: Are you really going to use it? Do you need it to be enabled?

If you are not going to use TRACE method then in my opinion it should be switched off. It will prevent your app not only against XST, but also against undiscovered vulnerabilities related to this channel, which can be found in the future.


bots bypassing form and submitting directly through web service

HTTPS will only prevent people from viewing the data en-route to the web service. It provides no method to authorize a request. You'll need to implement some authorization/authentication in the web service to make sure the people posting data are the ones that need to be posting data.