Can you explain exactly how the other browsers fall back? I've seen the following scenarios with servers and middleboxes:

try to connect with TLS 1.0 or higher, peer responds with SSLv3 and thus the connection continues with SSLv3. This usually succeeds.
try to connect with TLS 1.0 or higher, peer closes connection and browser tries again with lower TLS version. This usually succeeds.
try to connect with TLS 1.0 or higher, peer drops client hello and does not close connection. This times out after a while. In this case the browser does not retry with a lower version because it does not assume an SSL-related problem.

IE11 on Win8 does the initial client hello without offering RC4 cipher. If sonicwall just drops this client hello instead of closing the connection or sending an TLS alert you might run into the case where the browser does not retry.

You might make a packet capture (wireshark) to see what is going on.


How can we use digital signatures for mutual authentication between two computers?

Preface

Digital signatures and signing is not a one way street. A public private keypair is actually just a mathematically linked keypair, with one key designated as the private key and the other designated as the public key.

When you sign a message with the private key, the public key can be used to check the message and thus validate the sender. Additionally, when you encrypt a message with the public key only the private key can decrypt it. This can be used to ensure only one receiver can read the message. What some people don't realize though, is that this process is actually mathematically reversible. You could sign a message with your public key (making it only verifiable to yourself), or encrypt a message with your private key (making it readable to the world). Mathematically, keypairs are interchangeable and can both perform the same operations. However, it is worth noting that when it comes to practical applications, these keys should not be interchanged. You can read more about why a private key is chosen to be private in this StackOverflow answer. In short, both keys are derived by an exponent. In real world cryptographic applications like RSA, the exponent for the private key is made extremely large, thus causing the public key exponent to be extremely small. This makes guessing the private key WAY harder, while making the task of guessing the public key WAY easier (which is fine because everyone already knows the public key). So, if you gave out your private key and kept your public key secret, it would be easy for an attacker to derive your privately held public key when compared to the proper method of doing things.

Also, something to touch on: Mathematically, signing and encrypting is the same process. Signing a message is simply taking a hash of the message and then encrypting the hash using your private key. This encrypted hash is sent along with the message. Other users will verify this signature by decrypting it using your public key. They will then hash the message and compare the hash they computed with the hash from your signature. If they match you are verified because they only you could have used your private key to encrypt the correct hash of the message.

Note: You mention digital certificates as being used to solve your problem as if it is a separate thing from public-private key cryptography. It is not. These are both examples of asymmetric cryptography. Digital certificates contain a public key along with other metadata, all of which is usually signed by another authority (using asymmetric cryptography)

To answer your question

There are multiple ways you can do this with asymmetric cryptography. In my following examples we will have Alice and Bob who both want to authenticate the other user.

Example 1
Oddly enough, in the same SO thread I linked to explain digital certificates there is one answer to your question. Similarly, to achieve mutual authentication between two entities we can sign an encrypted message. Suppose Alice initiates a conversation with Bob. Alice encrypts the message "respond with the codeword potato" using Bob's public key. Alice then signs this encrypted message with her private key. When Bob receives the message, he can verify that Alice sent it by checking the signature against Alice's public key. Bob can then decrypt the message with his private key and respond to Alice with the codeword "potato" (encrypting his response with Alice's public key). When Alice receives the message from Bob and reads the codeword, she can validate it is Bob on the other end.

**Alternatively, Bob could just sign his response message and Alice could verify him that way (a more secure method) but this scenario has the downfall of not involving the word "potato".

Example 2
Because a public-private keypair is simply a mathematically linked keypair, we could conceivably have two private keys. In this implementation, the size of the exponent would not be chosen to be overly small or large for either key. This would prevent one key from being "weaker"/"stronger" than the other. If we give Alice the first private key, and Bob the second private key, they would be able to sign their messages with their own private key, thus making it verifiable to the other user's private key. AKA, Alice sends a "hello" message to bob, and signs it with her private key. When Bob receives the message, he can validate it using his own private key (which is the partner key to Alice's) and then respond with a "hello", signing this message with his private key. Both parties would know that the other is who they say they are. Additionally, because both of these keys are private, Alice and Bob could encrypt their messages using their own private keys, ensuring that they are only readable to the other person.

**Disclaimer: This second example came straight out of my head. There are probably implications to signing/encrypting messages back and forth like this which I am unaware of, but this is a simple to digest example.


SSL for external micro-services for Tor hidden service

If the main service connects to the micro service via Tor hidden service, you don't really need to do additional encryption, Tor hidden service already encrypts and authenticates the connection.

If your main service connects to the microservices using regular internet, then you really should encrypt this connection. There's really no reason not to, as you can use self signed certificate for this purpose which you can create for free, and when setup correctly, without reducing your user's experience or security.

If you don't encrypt the connections to these helper microservices, a well positioned adversary would be able to see what your service is doing, what your users are doing, and potentially deanonymize them.


Can I pre-register an SSL certificate with validity in the near future?

Ordinarily, the validity of period of the certificate is not determined by the requestor, and is not specified in the CSR.  The validity period is determined by the CA (most CA's offer various durations according to price).  So, you would have to find a CA that has a mechanism in place for what you are trying to do.

See CSR expiry date / validity date for more info.


LLVM's LibFuzzer might be helpful.  It is a toolkit to help with in-process fuzzing of libraries.

It does not solve the problem of automatically identifying function signatures of each exported function and injecting random data of the appropriate type to each.  Instead, it expects you to write a small test harness of your own that invokes the exported function with data of the appropriate type, so that part you have to do manually.  However, if you do that part manually, it automates the rest of the fuzzing job, using techniques similar to American Fuzzy Lop (the AFL fuzzer).


What are the risk of NOT using a host key for SFTP using pysftp?

You confuse your account public key, that you use for authentication, with a host/server public key, that you should use to verify the server.
These are unrelated, while serving a similar purpose, just in an opposite direction. The server uses your public key to verify your identity. While you should use the server public key to verify server's identity.
See my article on understanding SSH keys.

Even if you use a simple password authentication, you still have to verify the host key. The host key verification protects you from man-in-the-middle attacks.

See my answer to Verify host key with pysftp to learn how to verify the hostkey with pysftp library.

Note that neither of the two above mentioned public keys are encryption keys. That's just another thing. See How does SFTP function without a manually generated public/private key pair.


Intrusion Detection System and Network Intrusion Detection Systems

Whats the difference between IDS and NIDS?

The concept of IDS can be divided to Two classes, this are Host IDS and Network IDS or HIDS and NIDS.

                           IDS
                        /       \
                     HIDS       NIDS
           Host IDS                 Network IDS
      Inspecting Host             Inspecting Network

For example:

Network IDS:

Snort
Suricata

Host IDS:

AIDE
Tiger
SAMHAIN
Osiris
Tripwire

There are 7 IDS. Two of its are NIDS and Five of its are HIDS.

Of-course, IDS can be designed as hybrid of NIDS and HIDS.

  Can i use more than one IDS and NIDS at the same time?

As you wish.

  And what's YOUR favorite IDS or NIDS (I couldn't find ANY NIDS).

My favorite NIDS - is Suricata, because it can block connection in real time with iptables.

On HIDS, I like mtree way ( OpenBSD ). You can read man mtree

  PS: Where do you install NIDS? On the router?

There are many ways to use NIDS. Inside DMOZ or outside. For example, one NIDS can be installed on the front of network, with active filtering of connections. Thereafter other NIDS can be installed right on the server / work-station.

The easiest solution, that I'm using is installing Suricata right on my work-station with active dropping of any packets that match any of rules.

Suricata User Guide » Suricata Rules

Means, I'm taking latest set of rules and replacing alert to drop everywhere.

Users of Ubuntu could easy setup Suricata by one command:

$ sudo apt-get install -y suricata


Safe to email images with personal information? or use encryption for images?

Emails are not protected. If an attacker is specifically against you and has technical read access to your emails, then he will be able to open pictures and see their contents. Encoding text as pictures is good only to deter robots. This uses the known facts that although human brains are, as far as computing goes, remarkably feeble, they are outstandingly good at image recognition. That's the reason we write with, say, writing: our brains are easily trained to recognize contiguous ink blots as letters (or other glyphs), filtering out visual noise automatically.

CAPTCHA systems use the same principle. They try to defeat automatic scanners. In practice they don't work so well, in part because attackers have learned to hire cheap human labour to do the image recognition part.

An encrypted Zip is something really different. This is cryptography. It does not work on the hardness of recognizing letters within a picture; it works on the hardness of breaking an encryption algorithm if the key is not known. An encrypted Zip will deter attackers, and prevent even targeted, human-controlled eavesdropping; but it will do so only if the decryption key (the archive "password") can be conveyed to the intended recipient without showing it to the attacker. Do NOT write the Zip password in the email itself (don't laugh, I have seen it done -- you may cry, though; that's what I did). A Zip archive protected with a password that you give to the recipient over a phone call ought to be effective against most attackers (if the bad guy taps on your emails and on your phone, then you probably have bigger worries).


Linux forensics- How can I extract sysfs procfs from a raw image?

You can't. Those are virtual filesystems that don't correspond to anything on disk. They're just file-based interfaces to inside the kernel, and only ever exist on-the-fly in RAM.


First of all, malware normally does not load it's own DLLs into memory. I think you confuse this with malware injecting executable code into another process (OpenProcess(), WriteProcessMemory()) and starting a new thread in that process (CreateRemoteThread()) which executes that code. This has nothing to do with loading a DLL into memory which is much more difficult than just executing code. Why should malware consist of multiple DLLs that are loaded into memory? It is much easier to write ONE malware executable instead of multiple DLLs.

Back to your question: If you want to trick Windows to load a DLL from memory this is something between very advanced programming and cracking.

One disadvantage is that you cannot use debuggers if anything goes wrong in your DLL.

You can use for example this code: https://github.com/fancycode/MemoryModule to load a DLL into memory. I did not test it because the disadvantage is that you must use special funcions to access that DLL in memory afterwards. For example to read a string resource from that DLL you cannot use the usual Windows API. You must use a function from the same library.

Some problems that occur are listed in more detail here:
https://www.codeproject.com/Tips/430684/Loading-Win-DLLs-manually-without-LoadLibrary
The author says that with his code his DLL does not have an HINSTANCE handle. This is a big disadvantage.


A single site for reporting unknown viruses

You have a hand full of of Virus checking online services:

Virus total
Herdprotect
Meta scan
Jotti's Malware scanner
Threatexpert
Uploadmalware
Web of Trust

Most of them have connection with Security product vendors and may forward your samples upon request by the vendors.

Alternatively, you can directly email each vendor: http://www.techsupportalert.com/content/how-report-malware-or-false-positives-multiple-antivirus-vendors.htm


How is a "commonly used password" determined?

One option is to use a list of well known weak passwords. Those lists are available from many breaches of the past in the internet. For example, there RockYou list contains the passwords of more 32 million accounts. One method would be to compare your password with the (let's say) 1000 most common passwords. If there exists one password which is similar to your password then your password is considered to be weak. Similarity can be computed with the edit distance (e.g. Levinshtein distance) which is the minimum number of insertions/deletions/substitutions to transform one string (i.e. in this case the password) into the other one.

Another solution is to use an approach that is described in the paper "Adaptive Password-Strength Meters from Markov Models" (http://blogs.ubc.ca/computersecurity/files/2012/01/06_3.pdf). Here only n-grams of all passwords are stored and counted to create Markov Models from the passwords. These Markov Models are used to compute the strength of passwords. The advantage of this approach is that the Markov Model adapts to the password distribution of the specific site. For example, the RockYou users often tend to use passwords which contain the string "rockyou" in some form. Therefore, for RockYou this passwords similar to this one should considered to be weak. For other web sites there are other site specific weak passwords.


It seems that its like a black point in my mind that I think about
  browser when I research information security. Its clear that its the
  browser applies security rules while we navigate websites. In any
  event that if browser failed to apply cookie rules or origin policy;
  how we can detect that?

You cant really tell if the browser fails at applying a policy unless the browser itself tells you. If the browser has not been tampered with when you start using it, you can use some third party addons for the respective browsers to give you a fine grained control over these kind of policies.

Firefox has addons like Cookie Monster and Self-Destructing Cookies to make it easier to manage cookies and apply policies on them. I am not familiar with Chrome or IE so I cannot give any example for them.

There are also blockers like uBlock Origin and uMatrix which provide loggers that you can use to analyze what the browser is doing, as well as see what is blocked and what is allowed.

  Now, if someone downloaded malicious browser (infected version of
  genuine browsers or any other browser that originally designed to
  steal user data)

  how we can validate trustworthy of the browser and proof that all
  security rules applied correctly?

There are checksums available for firefox here you can compare them with the file you download to make sure nothing has been altered from the version published. Its important to note that checksums assume there is no MITM when you are downloading/viewing them. Obviously if someone has a MITM they can just alter the file before sending it to you.

Again, these browsers don't offer any real way to audit them, you need to use some third party tools for that.

  Dose anyone validated Mozilla, Internet Explorer or Google Chrome?

Firefox and Chrome (Chromium) are open source projects so they have bug trackers that are publicly visible as well as the ability for anyone to download the source code. The problem is that these projects are so large, its difficult for a single person to audit the code.

If you are worried about exploits on the browser making your data/actions vulnerable then the best you can do is find some addons that help you track the browser, run in a sandbox environment and use programs like apparmor or selinux to prevent the browser from doing things you don't want it to do.


How many combinations of md5sums can be computed from a call to random() in PostgreSQL?

random() can have at most 64 bits of significance, since it's a double precision float. That assumes perfect random number generation and all that.

We only produce a random significand, the sign and exponent is fixed. The fractional part of the significand is 52 bits.

So ... about 2^52 possible values.

It looks like you're thinking of the rainbow table as a mapping of the md5 of the text representation of a double precision float back to the original float. Assuming you're using extra_float_digits = 3, that'd take up roughly 128 * 2^52 bytes, so a couple of exabytes, in exchange for reducing your search space from 2^128 to 2^52. Not that exciting, really.

I'd still want a good reason not to just use a uuid-ossp's uuid_generate_v4(). How big can your session tables really be? You know PostgreSQL has huge per-row overheads right?

Separately, you don't have to use uuid to store an md5, or format it as text. You can also use bytea. It'll be packed into a short-varlena Datum which has a 1-byte length so it'll take up 17 bytes. (See: VARSIZE_ANY in src/include/postgres.h, and src/backend/utils/adt/varlena.c).


Signed requests can help in the scenario where the Assertion Consumer Service URL requested after authentication can be to a variety of domains or URLs. To avoid being used as an open redirector, the IDP would generally validate based on a predefined list of valid URIs. This list would be obtained from the SP metadata or manually entered from a known list. But if the SP signs the authentication request, then the IDP has some assurance that the request is valid even if the URI is not in the predefined list.


Is all access to the underlying system components protected via an access control mechanism managed by the kernel?

Both main memory and disk drives are managed solely by the kernel.

For a user space program to access these it needs the kernel's cooperation through the invocation of system calls.
A kernel module can access them without further approval, because it's already part of the kernel. Of course to become a kernel module kernel cooperation is again required.


You should not worry about the source being Any. It is the common way for public server side protocols like FTP or HTTPS. Simply you should ensure that only the expected server(s) is (are) reachable on their open ports.

But FTP is an old protocol that was invented when firewalls and encryption were not used. It uses one TCP connection for the command stream, and a distinct one per file transfer. In the sendport mode, the data connection is initiated by the server form a well-known port (20 for FTP, 989 for implicit FTPS). That means that is is nice for your own firewall, but will cause headaches to your partners firewall admins: they will have to open input connection on their firewall to random ports...

The passive mode in a little more client firewall friendly, because the client will open the data connection. But only a little more, because the server will listen on a (quasi) random port and no longer on a well known one. And the nightmare is for the server side firewall: a legitimate connection coming from a random port and reaching a random port! In non encrypted FTP mode, the firewall was spying on the command connection to know the data ports, but no way if the command channel is encrypted...

This is one of the reason why FTPS is only seldom used, despite being a very robust protocol.


Techniques exclusive to my malicious version of my own benign program?

This is not the right approach to this problem. It will bring legal ramifications against yourself and cause a wide array of issues you want to avoid. Instead you should implement the best practices to keeping yourself and your program safe.

Really you should make people want to buy your software or implement copy protection that won't put people off from buying it. There's some logic behind your approach, but it's still blackhat logic and should be avoided at all costs.

Really what you should try to do is offer value, incentive, and protection. Upload your evaluation copy to the torrent sites and let people use it for a reduced set of features, and make those pay for me features really useful(remove the single ad, add extra common output formats, helpful features, etc.). This way enough people will find it, try it, and if it's a good value buy it.

Now this may sound like poppycock, but it leads to one very large advantage: It will make it much harder for people who have decided to crack it to try and upload it because you'll have put your version up first, in a way that makes people find your legit version instead of their cracked version. Now when they go to try and steal it, instead they'll just sample it. Do this enough, and keep a vigilant watch out and torrents shouldn't exist for your product that you yourself don't use to put them out there. In fact offer it as an official source for your free or evaluation copy.

At least this way you won't go to jail/prison/federal/worse and you won't get sued if a legit user somehow gets one of those version accidentally.

Other best practices for this include setting up a registration server and code so that it logs something identifiable that isn't personal based on the system(like UUID) so that you can keep track of those computers, and if you suspect someone is using it illegally, you have some sort of evidence(uploading your own cracked, reporting, non damaging copy to the internet as a honeypot). This way registered users get logged as legit, and unregistered users get logged as non legit.

A great place to put that code is the pro features that would get cracked open. If the key doesn't exist in memory because it's been bypassed and thus not stored, REPORT! This way you can get your protection, and not end up somewhere bad.


How can an attacker sniff a password with SOCKS5 proxy?

I did a blog post on this here in 2012: http://security.blogoverflow.com/2012/04/tor-exploiting-the-weakest-link/

The fact is that an attacker can indeed launch attacks as you mention. The exit node will always be able to read the clear text traffic and maybe even indeed perform SSL strip like attacks.


How do I block Chrome extensions from making network requests unless whitelisted?

Have you tried this extension ? https://chrome.google.com/webstore/detail/chrome-apps-extensions-de/ohmmkhmmmpcnpikjeljgnaoabkaalbgc
It's made by Google itself and seems to have the functionnality you need. Since I have Firefox I can't test it myself, but let me know if it works.


What happens after setting up HDD password?

Usually, disks supporting encryption do this in two steps.

In step one (usually on factory manufacture) a secret key is chosen at random. Then, a decryption key is chosen, and initially it is blank.

The secret key is encrypted using the decryption key and, when the system is powered up, an API exists whereby the user can supply the decryption key, if needed. Then, the secret key is stored into a temporary memory buffer and used to encrypt (and decrypt) all traffic to the magnetic platters.

To change the password, you supply the old password, whereby the encryption key is decrypted and re-encrypted with the new password. This takes only a few instants.

To decrypt the hard disk you need to know the secret key, which never leaves the disk itself. While some encryption schemes are vulnerable to brute force and statistical analysis (for example because the encryption scheme is a simple "SECRET KEY (XOR) HARD DISK SECTOR" - it has happened), current schemes are pretty solid.

There are some very sophisticated techniques that can recover the hard disk secret key, if the model is known and supported, from the powered down hard disk provided it hasn't been powered down too long, from the residuals in the hard disk's volatile memory. But at that point it makes much more sense to worry about a rubber-hose attack.

The advantage of the double-key system is, as you experienced, that there is no need to decrypt and reencrypt the whole disk whenever the user key changes. This makes the operation very, very fast and reduces the risk of a mishap happening in mid-encryption which might leave the disk effectively "bricked".

Of course, there are rumors - I can't seem to find the reference now, so let's call it a theoretical possibility - that the master key is not actually random at all, but may (e.g.) derived from the disk serial number, maybe hashed with a secret salt (or alternately, it can be random generated... and then secretly stored together with the disk serial number). Knowing the hash, the salt and the disk serial number, and by dismantling the disk or overriding its interface, it then becomes possible to "easily" recover the disk content. At the same time, such a backdoor isn't easy to uncover.


Is this type of ARP poisoning attack possible?

This is actually called ARP flooding. An infected system/malicious user sends ARP replies to all systems connected to the network, filling them with incorrect ARP entries. This causes the systems to be unable to solve MAC and IP addresses resulting in systems being unable to connect to other systems in the network.


How would I implement "Broadcast Encryption"?

You just encrypt the symmetric with the public key of each recipient. There is some research on how to do better than that (so that the size overhead is less than, say, a hundred bytes per recipient) but there is nothing directly applicable right now.

If you use RSA (that's the most probable), then here are the sizes: an encrypted message always has the same size than the modulus; for a 1024-bit RSA key, this means 128 bytes. The encryption process includes some padding, which adds an internal overhead of at least 11 bytes. Thus, the maximum size of a data blob which is to be encrypted with a 1024-bit RSA key is 128-11 = 117 bytes.

I am not sure why you would want to wrap the symmetric key in a SOAP or JSON message. If it is encrypted then the receiver must decrypt it; since an encrypted RSA message really looks like a bunch of random bytes with no visible structure, this means that the receiver already knows what to expect. What would SOAP or JSON add at that point ? Maybe you would like to do it the other way round, i.e. encrypt (with RSA) the symmetric key, and then wrap the result (the 128-byte encrypted message) into a SOAP or JSON message ?


Is it a good idea to test a live company website as part of an interview process?

A lot of companies are giving challenges as part of the interview process these days, mostly on sample apps, I've never heard of testing on a live site as part of an interview.

Do you have a paper trail? Is there an email from someone at a high level approving of this? If not I'd ask for an email from someone at the director level or higher that indicates you have permission. Then agree on a time and have everything in writing.

Are they looking for a free pen test? Maybe, but oh man is that shady if true.


Cryptomator can potentially meet at least some of your needs, and seems to be designed for this use in mind: that is, transparent client-side encryption/decryption of individual data files stored with a cloud storage provider, while obscuring filenames.

  encryption relatively transparent (mostly text/.odt files) and cross-platform (Win, OS X, Linux)
  file-level encryption (so that versioning/backup still works)
  ideally files can be viewed server-side with a key (this will require a new owncloud plugin)
  sharing of files possible (ideally with multiple keys)

✓
✓

this will certainly involve some manual inspection/comparison of, say, timestamps to determine which file to revert from the ownCloud interface, since filenames are obfuscated

¯\_(ツ)_/¯

I suppose it's possible, since other cloud storage providers have integrated it into their own web-based services according to this page on the Cryptomator site

ehhhh, sorta, but probably not in the way that you'd hoped

this would be possible at the level of encrypted containers, if you shared the key file or passphrase used to unlock the container; this is easily done if you can meet the other person in the physical reality, not so straightforward across the InterWebs
and this is obviously not going to be integrated into ownCloud's built-in sharing workflow, such that you could just pick a username and click a big "Grant Access" button

Other notes

Recent versions of ownCloud have server-side encryption, as mentioned in this FAQ

not sure if this is a paid "Enterprise" feature nowadays or a "core" feature
this will not protect user data from local administrators, only encrypts it in transit to a third-party storage provider like Dropbox or Google Drive
ownCloud GmbH's original press release, from late 2018

Not much luck with searching for "client side encryption" on the ownCloud forums


Why and where was Meltdown made public before schedule for the first time?

I followed the news of these attacks with a lot of interest starting on Jan 3rd, and have done some digging back to see what else people had been saying prior to disclosure.

The embargo was officially broken on Jan. 3rd by this post from Google, followed shortly by a bundle of technical details in their Project Zero post.

In that first link they justify breaking the embargo by saying: "We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation."

There were a number of reports that an aware observer could have picked up on prior to that date. The biggest "smoking gun" for a speculative execution exploit (that I'm aware of) was made when an AMD developer submitted a Linux patch on Dec. 26th, which is linked in the article you provide. To my knowledge that's the first time a public report directly connected speculative memory references to a possible attack and patchset. Prior to this an article at LWN on Dec. 20th suggested that the page table isolation patchest was really addressing a deeper security flaw, but no specific reference to speculative execution being the source of the problem.

People really started to pay attention on Dec. 28th-29th after the page table isolation patches were merged into the kernel by Linus. A change of this magnitude usually takes a lot longer to be applied to the mainline kernel, so this essentially announced to the world that there was indeed an embargoed vulnerability.

The internet started blowing up on Dec 30th and Jan 1st. grsecurity on Twitter was convinced that there was an embargo at least as early as the 28th, and on the 30th observed to the world that there were missing source code comments in the Linux patchset. python sweetness on Tumblr accurately predicted on Jan 1st that it was a hardware-based vulnerability in x86 that could do unprivileged memory reads, and speculated about the possible hypervisor attack based on the presence of employees of Amazon and Google being looped in.

Then, of course, the Register published their piece on Jan 2nd and the entire world was looped in. That article referenced AMD's Dec 26th patch and connected speculative execution to the undisclosed vulnerability.

There has been growing interest in the security research community about the vulnerability of modern microarchitectures. The Spectre paper cites no less than 12 other works about leaking data from inside the processor or L1 cache, and recent work from 2016 about exploiting branch predictors to bypass address space randomization arguably laid the foundations for Spectre. Anders Fogh's blog outlined some basic techniques for the attacks at the end of last July but reported a negative result. If you throw Fogh in there, that's three separate groups independently finding and reporting these specific vulnerabilities inside a single year.

The Spectre vulnerability in particular is a really big deal, meaning that they're going to be talking about it for a long-long-long time to come. My guess is that part of the desire to disclose early was to make sure they claim credit where it was due. Imagine if you were sitting on a game-changing vulnerability. You know that at least one other group has already independently discovered your vulnerability, and if you're up to date on your blogs you know that Fogh has been investigating the same. A sudden bout of press activity spooks you into thinking that a fourth person has discovered and was about to disclose the same vulnerability you'd been sitting on for a year!

What specifically caused Google's team to break the embargo we won't know. The Register's article is the obvious candidate, but the cat was really out of the bag once the page table isolation patches started moving in early December.


Randomness of hash token in password reset link

Most random number generators just generate pseudorandom numbers. They create a series of numbers which appears random at first glance, but the numbers do follow an exact algorithm. To prevent them from generating the same series of numbers everytime they are used, they are initialized by seeding them with a start value. A good pseudorandom number generator should output a different series of numbers for every possible seed value.

In practice, a pseudorandom number generator is often initialized with the current time. Because the time will be different everytime a program is run, it will never generate the same stream of numbers. Unfortunately this is insufficient for any security purpose, because the time of initialization is very predictable. For that reason you need to combine values from other entropy sources which are hard or impossible to predict for an outside attacker.

Which entropy sources are feasible depends on your environment.


If the server's on your own network, feel free.  But if it's hosted somewhere, then your DDOS could impact other people using the same network path or other infrastructure.  You could ask permission, but they'll almost certainly say no - SPs are generally comfortable with pentesting but nobody fools around with DDOS testing.


How many security-related websites/sofware/system/human brain will break when we get more than 10000 CVEs a year?

The industry will not fall apart, because such an outcome would mean that the industry at large minds CVE numbers and acknowledges their existence; the day this will become true will be a glorious day indeed.


Wireless Positioning System (WPS) works without Internet?

So several companies have a database of Wireless Access Points (Google, Apple, Skyhook).

In terms of how the data is collected, I don't believe that any of the companies have made official statements on the matter, but there's a couple of likely avenues.

First one point is that your wireless Access Point broadcasts it's BSSID address into, likely public, areas like the street outside your door.  It's fundamentally legal (AFAIK) for someone to pick up wireless signals in a public area.  So it's not your location that's been directly gathered, it's the location of a device in a public area together with the signal strength and BSSID address of your Access point

War-Driving.  Google in particular is known to have used this technique, when they equipped their street view cars with wi-fi detection capabilities.  This would allow them to assemble a large database.
Mobile Devices.  Both Google and Apple (and other mobile device manufacturers) have huge numbers of mobile devices with GPS and Wi-Fi.  If those devices report back Access Points that they have seen in a specific location, then it would be easy for those companies to assemble this information into a database.

In terms of your devices Internet connection, it doesn't really matter as it's not your device that is sending them information, it's other devices that "see" your device in passing.


Aside from the legal aspects alluded to by Neil McGuigan in the comments, it's also difficult to perfectly emulate, say, Google. For one thing, when I log in, Google shows my profile picture. Second, it asks me to perform my 2FA validation (I know, you're assuming most people don't use this, but for those who do, its absence is a red flag).

Reading your question closely, I just noticed this statement:

  I then emulate the user and authorize my app through the normal SSO process behind the scenes so nothing looks abnormal

What exactly do you mean by this? Assuming at this point you've captured the users credentials, how do you then turn around and use them to actually perform SSO? There's no way for your server to authenticate with those credentials in a way that sets the correct cookies in the user's browser, which is important for SSO to work.

Really, if you were going to execute this kind of attack, it would be better to fake the SSO as well, or omit it entirely, and just store the credentials for later retrieval.

But, none of this is specific to OAuth or SSO itself. It's just a phishing attempt, no matter how its initiated.


Can sending a hidden Text/SMS messages be considered a security issue?

What happens is that your phone "exports" a modem. This is visible via Bluetooth and can be programmed using AT commands (in this case, AT+CMGW).

And those can be used by the SMS App to send SMSs, and also by the Toyota to do the same.

This can be done by any device that is paired (trusted) and has access to the Bluetooth stack.

Since SMSs are not stored by the modem but by the app, you won't see any messages from any app from any other app (unless the two apps "agree" to a protocol and store messages where they both can access them).

Checking what was done by such applications is probably possible but would require a specific utility to do so.

To verify that no unknown stranger is abusing your radio modem console, you need to not pair with any untrusted device, ever, and periodically verify what devices your phone has paired with.


Using hashcat in order to crack the JWT signature in WebGoat

JWT Token Structure

As detailed on the JWT website (https://jwt.io/introduction/), JWT token consists of three parts separated by a dot (.), which are - Header, Payload and Signature. Both Header and Payload are Base64 encoded strings.

  Therefore a JWT token would typically look like this:
  Base64(Header).Base64(Payload).Signature

The signature is created by taking both the header and the payload, use a secret key to create a signature by using the algorithm specified in the Header.

Finding JWT Secret Key

What you need to do to solve this challenge is to find the secret key that has been used to create the signature. This can be done by using a brute force attack to calculate the signature by using different secret keys either from a wordlist or through a pure brute force attack.

The correct syntax to use to conduct brute force attack to find the secret key using Hashcat is:

Using a Wordlist:
$ hashcat -a0 -m 16500 text.hash [dict]

Pure Brute force attack:
$ hashcat -a3 -m 16500 text.hash

The option -m 16500 is the correct Hash Mode to brute force JWT tokens using Hashcat. The one that you have used (-m 1450) is for raw HMAC-SHA256 hash and is applied to the whole string, therefore resulting in an error.

The above method works fine for me to find a secret key for a given JWT token, however, I am not able to solve the WebGoat challenge yet. I am trying to get in touch with the Webgoat team to understand the problem and to solve this challenge. I will provide an update when I hear back from them and can solve the challenge.


How android WebView can be exploited and how to secure my app from WebView vulnerability?

The primary vulnerabilties involved in the WebView component are Insecure Direct Object References, SQL Injection, and Cross-Site Scripting (XSS).

While all three are potentially huge risks, the XSS vulnerability potential can be used to gain access to shared preference files using the file:/// command or can utilize smsJSInterface.launchSMSActivity to send unwanted SMS messages from the phone, in addition to stealing credentials or providing a false front to the HTML, CSS, Javascript, or other browser-level behavior.

If you turn off the setJavaScriptEnabled as follows, adversaries will not be able to run any Javascript in order to perform XSS attacks:

myWebView.getSettings().setJavaScriptEnabled(false);

Or, if you can't do this, be sure that each context is escaped properly by using an XSS filter component such as the OWASP Java Encoder Project.

You can see what data is available to each WebView by using the sqlite3 command-line tool or a SQLite3-compatable browser to view the /app/-packagename-/db/webview.db file. Of course, any input that makes its way into the SQLite3 database or that performs a query or other string operation against it can become a potential insertion point for SQL injection -- albeit in some cases a network MITM scenario may be required.

Some examples of insecure direct object references can be found in these penetration testing tutorials against the HerdFinancial app which is a part of the OWASP GoatDroid Project:

http://jit6ndrakumar.blogspot.com/2014/07/android-app-pentesting-part3.html
http://jit6ndrakumar.blogspot.com/2014/07/android-app-pentesting-part4.html


When a Web browser uses an HTTP proxy, things go the following way. Let's assume that the target URL is http://www.example.com/index.html. The browser then connects to the proxy and says to it: "I want to get the page at http://www.example.com/index.html". The proxy complies, get the data, and sends it back to the browser. By construction, the proxy sees all the data. The connection between proxy and browser could be encrypted, but the proxy still sees everything.

If the target URL uses SSL (https://www.example.com/index.html: mind the s in https), then the browser connects to the proxy, and tells it: "I want to connect to port 443 of www.example.com; do it and then relay all bytes in both directions". Section 5.2 of RFC 2817 describes this mechanism. The proxy then acts as relay for all the bytes between the browser and the Web server, these bytes encoding whatever the browser and Web server wish them to be, i.e. in practice a SSL handshake and subsequent data. In that case, the proxy is outside of the SSL tunnel and cannot see the exchange data. The SSL tunnel is still between the Web server and the browser, and the proxy is a purely transport mechanism.

The proxy is still in ideal position to attempt Man-in-the-Middle attacks, since all communications go through it; but SSL is protected against that, namely by virtue of the Web server certificate being validated by the client. This of course relies on the human user not to click through warnings about invalid certificates. In some organizations, local sysadmins install extra "rogue" root CA certificates in desktop systems so that they may create fake server certificate on the proxy, and do the MitM attack, granting them access to the exchanged data (so that they can apply antivirus filters even on HTTPS traffic, or so they say at least).

Barring such a rogue CA installation (which is, basically, a breach into the security of the client machine), the proxy won't be able to peek at the data exchanged between the browser and the HTTPS server. The proxy will still be able to know which server was contacted, and to observe the size of the data exchanges: encryption hides the contents, not the size.

Situation for SOCKS is conceptually similar. The dialog between browser and proxy is different, but the basics remain the same: the proxy will be able to see all the HTTP traffic, and none of the HTTPS traffic.

Edit: apparently, some other kinds of "proxies" exist, in which your browser contacts a dedicated server, which itself runs a browser, does your browsing for you, and returns the pages to you. Unfortunately, some people call that "Web proxies", a terminology which has been in use for two decades to designate what is, technically, a HTTP proxy. Confusion ensues.

Such "browsing proxies" are similar, in concept, with opening a session on the server with a remote desktop protocol and running your browser from there. This grants all conceivable power to the proxy administrators on your browsing activities. You don't want to do that if you don't absolutely trust the proxy sysadmins.

And you'd prefer not use the "Web proxy" expression if there is any risk of ambiguity.


If the question is if malware can copy data from USB device to computer, the answer is yes.

If user have read privileges, malware have the same. If the USB device is read-only or read-write does not make any difference.

If the question is about malware writing on a read-only USB device, it depends on the privileges the malware obtained. Usually, a USB device is marked as read-only by the OS, and any program with OS privileges can override the lock and write.

If the device have physical write protect switch, nothing can write on it. There is an astronomically small possibility of a malware written just for your device, that could theoretically bypass the lock exploiting a vulnerability on the device's firmware, but this is so improbable that I would say it's impossible.


Is TLS 1.3 available and if so, how is it enabled?

This is probably not news, but since the TLS 1.3 RFC is still in DRAFT, you'll probably cause yourself compatibility headaches if you turn it on for a production server.

I would guess this is exactly what you're running up against: TLS 1.3 may exist in some places, but is probably not fully supported all the way through both the client and server stacks; either some component doesn't support it, or they support mis-matched versions of the 1.3 draft, and they and up agreeing on 1.2. Just a guess.

Also note that (as far as I'm aware) TLS 1.2 --> TLS 1.3 is more about performance improvements and simplifying the protocol than about security. While there are a lot of good changes in 1.3, there's no security need to be a bleeding-edge adopter.


If my aforementioned understanding is correct, that would mean WPA-Enterprise with PEAP is less secure than WPA-PSK because a man-in-the-middle attack is possible to intercept the passwords. This seems weird to me. Is there a flaw in my understanding?

Yes, there was a flaw in my understanding. PEAP encapsulates the inner authentication method, EAP-MSCHAPv2 in my case, in TLS. If used correctly, TLS provides server authentication. In my case it wasn't used correctly because the server's public certificate isn't verified.

However, MS-CHAPv2 provides mutual authentication too. To answer my own questions:

  Does this really mean that my WPA2-Enterprise PEAP setup is less secure than plain WPA2-PSK? Seems really counter-intuitive because WPA2-PSK is so much simpler and only requires one shared secret. How is is possible that WPA2-PSK is able to ensure mutual authentication with just a shared secret while WPA2-Enterprise is not?

Not really. Both ensure mutual authentication without transmitting the password in plain text. The only problem with MS-CHAPv2 however is that it is quite old and depends on DES, which is not that strong anymore. It can be cracked.

  How can I make the clients validate the server's certificate? Is the only way to install the certificates manually on all the clients? (In that case, if I need to distribute certificates anyway, I can better switch to EAP-TLS)

I can't answer this one yet. Verifying the server's certificate would certainly enhance security (because MS-CHAPv2 can be cracked) but I have no idea how to do this on Android. I tried installing the CA certificate on my Android device, which went without problems, but I still couldn't select it in the WiFi settings.

  Or is it possible to use a public certificate just like with HTTPS? How would that work? With HTTPS, your certificate is 'anchored' to your domain, which you've proven to the CA that is yours. How does this work with RADIUS servers?

No clue on this one.

Alternatives

Well, since MS-CHAPv2 isn't that safe anymore, it would be nice to have some alternatives. A really promising EAP method is EAP-PWD. I would really like to implement it but there isn't much to find about it. Android supports it, but FreeRADIUS only does in the 3.x (unstable) branch. And of course, the stable branch (2.x) is in Debian. I guess I have to wait some time for this one.


A site bypasses VPN despite several precautions. How?

To the question about Google Maps:
If you allow Google Maps web site to access tHTML Geolocation API and if the browser has permission to access your device location information, then Google Maps will know your location from your device.


Wayback machine downloading a file called default.exe?

That might also be a snapshot of a misconfigured web server -- back then it was normal to generate web pages from CGI programs, which would be addressed as if they were regular files, and only their location or an "executable" bit set on the binary would indicate to the web server that the file should be executed and its output sent instead of the file itself.
It could also be a twenty years old virus.


You've compiled a neat list of possible indicators for a classifier. Some feedback:

First: Who would run this classifier? Are you talking about a browser or a browser plugin that will check every URL, or are you designing a redirector service of some kind? Are you building a search engine? Obviously, your classifier only works in cases like these; it doesn't help if you're just the owner of the real "facebook.com" and want to protect your users from entering "faecbook.com", because you'll never get to see the wrong "faecbook.com".

Playing devil's advocate to your suggestions:

Check the domain for typosquatting: This only works if you have an inkling what the "actual" domain name should be. You could probably automate this using result counts of various search engines (or, if you were a search engine yourself, look at your index to identify close matches) or try to access domain registry databases. Or, as a browser plugin developer, you could create a central database of domains your users visit, and then determine which domains are typosquatters using some simple statistics. However, if you did this, you'd have to deal with serious privacy issues.
Check the length of the redirection url: This is dangerous: There are various protocols which require redirection and which can pass a lot of information through the URL (oauth, for example). You'd have to exclude these protocols to avoid false positives. Also, some frameworks send things like session identifiers as parameters in the URL as a fallback when cookies are disabled. That's hard to distinguish from your typosquatter.
Count the number of redirects: I don't understand this. If you're refering to the number of redirects the browser does when it hits a typosquatter url, I don't think this will work very well as an indicator. Again, there are valid reasons for redirects, and a higher number doesn't necessarily imply malicious intent. Also, there's no technical reason for typosquatters to do more than one redirect (in fact, they don't even need to do a single one; redirects are just the simplest (and cheapest!) way to forward the user to a third-party site, but they could take the traffic and cpu hit and act as a proxy instead of doing http redirection, which would be invisible to you - it would just make it more expensive for the bad guys); so if you built a hugely successful classifier based on the number of redirects, the typosquatters could simply adapt.
Blacklist: It will never be even close to complete or up to date. How would you compile it? If you were a browser plugin developer, one way would be to record which domains your users visit, as I already said. If you were a search engine, you might be able to do something with your index, although most typosquatter domains probably wouldn't be indexed at all, so there'd be no way to build an even remotely useful blacklist from it.

An additional avenue you might think about is to try to classify the target page based on its content. You say that the target pages try to get you to provide personal information, offer fake tech support etc. It might be possible to build a classifier on that, kind of like the classifiers to determine whether we're dealing with ham or spam in our mailboxes. You could also run a limited spider on the target site to see how big it was; if it only offered a handful of pages, that would be an additional indicator. But again, if you were successful, this would be easily overcome by your opponents automatically building a large number of fake additional pages.


This is where an understanding of the OSI model is useful: the different types of encryptions happen at different layers of communication.

WiFi encryption protects all communication from your device from the local network (i.e. your coffee shop's network), but not anything past the local network (i.e. the rest of the Internet). WiFi encryption is 'optional', but set up by the WiFi network (not optional as a user).

SSL encryption protects the individual connections you make with the individual destinations (i.e. connections to websites). This also protects specific communication from your device from the local network, but it also protects it all the way to the destination (some exceptions apply).

Here's the problem: you do not always have control over what connections are being sent out by your device. Without the local network protections (i.e. WiFi encryption) you expose all of that to anyone listening.

So, the best idea is to use both the network encryption (Wifi) and SSL encryption wherever possible. You do not have as many options as you think, and you do not have as much control over what is sent out by your device than you think.


How is an HTTPS login secure when pages use HTTP?

There is an oft-quoted result from Google stating that when they switched Gmail to site-wide SSL, they saw only a minor overhead which could be neglected. An important point, though, is that it is for Gmail which is not necessarily a typical Web application.

The CPU overhead for SSL is small. A basic PC CPU core can do AES encryption at more than 100 MB/s. The cryptography which happens during session establishment (the "handshake") can be done several hundred times per second with the same kind of core, and it does not occur often, thanks to both HTTP keep-alive and the SSL "abbreviated handshake". It makes sense that properly implemented SSL won't clog the server CPU for most kinds of Web sites.

Network overhead for a single connection is also slight. When in full swing, a SSL/TLS connection breaks data into individual records, with a header and some bytes for cryptographic support: 5 bytes for the header, 16 bytes for the per-record IV if using TLS 1.1+ and AES/CBC, 32 bytes for a SHA-256 HMAC, and 1 to 16 bytes of padding for alignment. At most 69 bytes. But the record can embed up to 16384 bytes worth of application data, so we are talking about a 0.4% extra bandwidth. Again, that's negligible.

However, there is a site-wide network overhead due to caching. When the same piece of data is to be downloaded by many distinct clients, it is worthwhile to uses caches, located between the main server and the clients: when one client connection, going through a cache, is for a file that the cache has, the cache can answer without having to disturb the main server. The client and server needs not be aware of that mechanism; that's called a transparent proxy. Many ISP run that kind of system.

Caches won't help much with Gmail, because each user has his own mailbox and there are few files which will be shared between distinct users. However, the situation with Ebay may be different, with all the item photos that they send, by definition, to a lot of clients. It is highly plausible that caching benefits much more Ebay's infrastructures than Gmail's. However, and that's the tricky point, SSL prevents most of this caching. By going site-wide SSL, Ebay could possibly incur a non-negligible impact, enough to give them reason to pause and think. I don't say that Ebay's not doing site-wide SSL is proven to be a question of cache-related performance, but at least it is a possible reason.

Of course, not doing SSL means that passive eavesdropping and active attacks are a possibility. From Ebay's point of view, there are trade-offs everywhere between security and usability. Ultimately, as @Lucas says, it is all about money.


It's not always obvious how to extract the cleartext messages from an XOR.  However, in many cases, this is quite obvious.  For example, if a message is a 40-byte packets, it's probably an ARP packet, and you already know a bunch of the message from the format of the data on the wire.  Or, if you know this is part of an HTTP request, you're already going to know the format of that request, and determining the other message will be easy.
It may also be possible to determine whether two messages differ in a certain way.  For example, if the XOR of the two values is 0, then you know they're the same byte.  Similarly, if you know one of the messaages is an ASCII-based protocol (e.g., HTTP/1.1 headers), you can determine whether the other message is as well by looking at the top bit, which may lead you to other, more interesting discoveries.
Moreover, many of the insecurities of RC4 let you recover the key in this situation, since RC4 is vulnerable to related-key attacks and WEP uses it in exactly such an insecure way.  In that situation, the XOR of the data isn't as necessary.


Can a Bitlocker To Go user pin be brute forced?

It's not possible to find arbitrary digits of the pin. It's an all-or-nothing deal.

Assuming a numeric pin, there are 10,000,000 possible combinations. Depending on the implementation of the key derivation algorithm, it may take up to ~1s per attempt - that's roughly 58 days before you have a 50% chance of hitting the correct key, with 116 days (almost 4 months) being the worst-case time.


Is e-mail authentication using a hashed ( address + string ) insecure?

Since you want to change the user information, you presumably already have a db with (email, first name, last name) so I would add the token there too (plus an expiration time).

If you would use it in a stateless way (eg. just to confirm subscription), that's an acceptable approach, but you should be using a HMAC rather than a hash of concatenated values.


strategy for dealing with glibc issues through all docker containers

This is an unfortunate consequence of relying on software built/maintained by others, over which you have no control.

With Docker at least you have the opportunity of just replication the Dockerfile and then basing it on a fixed base image.

My recommendation would be that you do exactly that. The base OS images should be fixed by now, if you're using one that isn't rebuilt, just fork it and run your own Docker image based on the base OS of your choice.


How to securely communicate with radio controlled device?

There are commonly two methods of controlling drones. Radio receivers and data transceivers (traditionally telemetry links). This really varies by device, autopilot hardware, etc. Some even use WiFi for everything. Receivers typically are receive-only, and convert received signals into PPM or PWM signals to speed controllers, servos, etc. Transceivers typically convert data into serial or possibly connect to another data bus such as I²C.

But let's say you have a traditional drone with both a receiver and a telemetry radio to the autopilot, you may need to address security of both. You mention encryption, and this provides confidentiality, but I think what you're really after is authentication. How can you ensure the radio sending the commands is really yours?

Radio receivers typically use a pairing method, similar to a garage door, where a key or sequence is exchanged prior to use. In this way, a transmitter (handheld unit by the pilot) is paired to a receiver or multiple receivers in the drone. There are a number of ways this pairing is accomplished, you can look at the source code of Deviation which supports many protocols and pairing methods. These are frequently vulnerable to replay attacks.

Transceivers come in all sorts of configurations. In the past, many used FHSS to "secure" the communication. More realistically, FHSS provides interference avoidance. Some proof of concept take-over methods have been demonstrated. Some common sense things here to protect the radio communication would be using a mutually authenticated protocol such as TLS. Each protocol will require their own solution, but I would focus on authentication, and that likely involves encryption to achieve. Certainly a pre-shared key may meet your solution.

However, there is little you can do to avoid interference and should have some failsafe for when communication is lost or significant interference occurs. Receivers typically need very little bandwidth, and frequently many receivers can operate in the same space safely. So even with unintended interference, it may not be a problem. Data transceivers and WiFi-based units will be much more susceptible to interference and at risk with dropped communications.


Passing user ID as parameter without any authentication, what are the security risks?

what are the security risks?

The security risk is that there is no security at all to begin with.There is a reason why authentication exists.

Now lets assume that GUID is sufficiently long enough such that brute force is out of the question.But it still gets logged in so many places.

But the real threat is more from powerful crawlers that search engines have.A simple google search might leak the credentials of all the users.Plus without authorization or authentication how would you separate user space from one another.Its like an open website where anyone can be anyone without proving who they are.


Where do malware typically hide in a Windows machine?

Malware generally hides in folders that will be present across multiple machines, e.g. C:\Windows or C:\Program Files. Where it is able to hide depends on the program that initially placed the malware, and the permissions that it has.


It is not meant as a protection against XSS and there is no common context where it would do.

Instead, the authors solve the problem that the newline character (\n) does not display a new line in HTML, so they add the
 tag to enforce a visible line break.

The authors of the code even explain it in a comment themselves here:

//replacing "\n" with "\n
" here is to make comment text support displaying breakline
String sanitizedText = Sanitizer.sanitizeForHtml(commentText.getValue()).replace("\n", "\n
");


Why does Android care about differentiating multiple fingerprints?

A bit of a wild guess here: privacy and anonymity.

Having worked on ePassport software, I can tell you that developers need to be extra careful when handling users' fingerprint and iris data. Think of how careful we are about storing usernames, passwords, credit card numbers, etc, then consider that in the case of a breach, passwords and credit card numbers can be changed ... fingerprints not so much. I support the idea of being careful around biometric data - even if there's no obvious reason for it.

That said, here's an example where it might matter:

If you've set up your device to have a shared account used by multiple people, allowing apps to distinguish fingerprints would de-anonymize the users.

On personal devices like phones and tablets that's probably an obscure use-case, but with Android being used in more and more embedded devices, keeping 3rd party apps behind a privacy barrier makes sense. Take for example a livingroom entertainment system that's used by the whole family: the music streaming app needs to know whether it's authorized to bill you for purchases, but does not need to know which human did the unlocking. If you choose to give the app access to this information, then cool, but there's no reason for it to know it by default.

The Principle Of Least Privilege would say that if an app needs access to your biometrics, it should have to request that permission explicitly - just like any other permission in Android. By forbidding fingerprint device manufacturers from leaking distinguishability information to apps, Android has the ability to control access to this information through the OS' permission system.


What can I do to improve my Keepass XC setup?

Full disclosure is more opinion than fact: (I used KeyPass/XC for a few years, but switch to a different service due to sync difficulty)

Your risk tolerance is really based on your own comfort level and personal threat level.  If you are a high-value target this conversation would be different.

In General, having 2 or more backups is good, BUT all in the same space is bad. Off-site backups are important, but then you need to trust the offsite location. Second is the need to sync, a backup database that out of date is not too helpful. So syncing will be an issue and difficult if the off-site copy is in a bank vault for example.

Assuming Windows pc with a not high-value target, modist risk.
I would recommend:

Store one of the vaults in a trusted/one you comfortable with cloud storage  (this solves the offsite need).
Keep the master password and key file (if applicable) out of the cloud storage. (cloud storage user cannot decrypt if storage is not the key file isn't accessible.) Alternatively, there is a phone app option.
keep another DB/key file on a USB stick ( the master password stay separate)

this allows you to have the password on go (if stolen/lost they still need master password).  If really paranoid, you can get a pin protected USB, but that more to remember.

You may not want to store the totp data with the keypassxc database. Save in a phone app like authy?
Building off of another question increasing iteration and using a strong master password will make brute force harder, though slow down the app.
As for the sync issue, I did it manually, there is a feature called keeshare, that offers sync options, however I could only find docs in the beta page, so it's functionally/stability may be limited.
Finally, there is no perfect security, it all about trade-off and risks


Are Internet Explorers "Tracking Protection" able to prevent AddThis canvas fingerprinting?

I'm not trying to be mean or unhelpful but I don't know why people keep asking questions about whether Microsoft products and software are able to protect them from security threats. Just give up. Look into this https://adblockplus.org/blog/adblock-plus-and-the-canvas-fingerprinting-threat and read how its possible to prevent canvas fingerprinting. Then compare that to how tracking prevention works on IE.


Best practice to encrypt data in an Android application

I'd just use SSL with a hardcoded public key of the server. Nobody on the way can manipulate or read what you sent. No need to invent your own protocol.

But of course the user himself can manipulate and read the data this way, but solving that is a DRM problem and not a security problem.

I believe BouncyCastle can be used for that Android. I prefer TLS 1.2 with a DHE AES128 based ciphersuite, but depending on what your server supports, you might need to downgrade to a lesser suite.


Enforce a time limit on the number of uploads per user

The challenge you are going to face is how you identify the remote user.  It's not very hard for a remote client to change their "appearance" (browser, browser version, cookies, browser plugins, IP address, etc) and look like a new client.

If you place a cookie on their browser that indicates they've uploaded a file they can clear that cookie and upload again.

If you add a flag to their session (tracked server side matching a session cookie you give them) indicating they've done an upload, then they can create multiple accounts.

The better approach may be to:

Decrease the value of spamming your site, taking away their
incentive
Improve your ability to detect and remove spam messages
(either before or after they are posted)


How to Protect the Password Stored in a Configuration File?

In reality this is not a problem that cryptography can solve.  There isn't a separation of trust, the application must be able to decrypt the passwords in order to use them.

So how do you protect passwords stored in a configuration file?  Prevent the attacker from reading the configuration file!

Keep the configuration file out of the web root.
Make sure your application doesn't suffer form directory traversal.
Disable file_priv's on your MySQL database.
Make sure that only your application has read access to the file.


Where you have the full copy of your key requesting to export the secret key will export the secret master key plus any subkeys, the corresponding public keys and signatures by the master key on the subkeys.

Where you have removed the private master key you will get all that minus the private master key.  That is you'll get any subkeys (public and private), signatures on them from the master key and the public master key (necessary to validate the subkey signatures).

gpg2 --homedir=/my/save/place --export-secret-keys should produce something suitable for paperkey


Is there something like the OWASP top 10 for BizTalk applications?

The OWASP Top 10 is not language specific; it is applicable for all web applications.  The CWE Top 25 is the most generally used list for non-web applications. That's probably what you're looking for.

If you want something language specific, it'd be most helpful to look for a biztalk security guidance or a BizTalk hardening guide and also to obey common practices like treating all user input as malicious.


What risks are involved with installing gems from rubygems.org? Are alternatives safer?

If I wanted to avoid such risks, would it be safer to clone the git
  repository of the source code for the gem, and build the gem myself?

Probably not. More effort is likely to go into releasing (and potentially approving) a gem for inclusion onto rubygems than you will go to when cloning the source, especially for popular gems. Furthermore, there might be particular configuration / build options that are taken care of on your behalf when getting from rubygems which you might not be aware of when cloning from github.

However as Deer Hunter said, if you are going to go to the effort of thoroughly reviewing the code yourself, then cloning it from source is a good way to go.

Note that if the code of the gem in question is hosted on github, then in trusting rubygems you are implicitly trusting github, as any attack on the source there is very likely to also affect the author's gem publishing environment.


Yahoo Account hacked, changed pw, spam still going out elsewhere?

I will answer this question in accordance with your numbered questions in the comment.

1: Impossible to know without access to your computer, if at all.

2: The attacker did HAVE access to your address book, but it is once again impossible to know if he made a copy of it on his machine.

3: Logically, if an e-mail exists, someone or something sent it. If it wasn't you, it was someone else. As @mr.spuratic pointed out, you can verify for certain that a e-mail WAS sent from within yahoo, but you can't prove that it wasn't.

4: Impossible to know without access to your computer and account.

5: See 2.

6: Make sure the attacker can't get your password again (do an AV scan, use HTTPS Everywhere, etc.)

Hope this helps you out.


How do I clear cached credentials from my Windows Profile?

The utility to delete cached credentials is hard to find.  It stores both certificate data and also user passwords.

Open a command prompt, or enter the following in the run command

 rundll32.exe keymgr.dll,KRShowKeyMgr

Windows 7 makes this easier by creating an icon in the control panel called "Credential manager"


Is it okay to omit the 'Version:' line in a PGP public key?

The Version header is purely informative; my guess is that it's included to make compatibility bugs easier to discover (e.g. if a client is unable to decrypt 10 messages, and all 10 were made by the same version).

Source: https://superuser.com/a/823907


If using https, and hsts, and verifying the certificate is valid, are my connection safe, if not using vpn?

If you are using HTTPS with a valid certificate, then Transport Layer Security (TLS, née SSL) is likely adequately protecting your communication with the server that sent the certificate.

An attacker on the network may still be able to see things like the IP address of the server you are communicating with (or other header data below the application layer). But the application layer data (in this case the HTTP data and headers) will be encrypted with TLS (the S in HTTPS) and thus the network attacker will not be able to see that data.

In other words, for the most part, yes it is safe without VPN.

The above statement is subject to the usual caveat that threat models will vary. E.g., if an attacker has access to your computer and can run, say, super user processes on your local machine, then they can likely steal your data prior to TLS encryption. Additionally, if you are not positive that the certificate is valid, then the above mentioned safety would not apply. Etc.


What are the details of the vulnerability?

Git stores repository metadata in a .git sub-directory. This includes git hooks that allow custom scripts to be run at various points in the git workflow. Git normally does not allow any files in this sub-directory to be committed.

However, sub-directories like .Git on can be committed into the repository. This vulnerability arises because operating systems with case-insensitive filesystems (such as Windows or OS X), will treat the two sub-directories (.Git and .git) as equivalent and will overwrite .git with the contents of .Git. This results in an attacker being able to execute arbitrary code by tricking users using operating systems with case-insensitive filesystems into cloning a maliciously crafted repository.

  Does it affect me?

The vulnerability only works on users using case-insensitive filesystems. This include most Windows and OS X users.

Pulling repositories from GitHub is safe because GitHub now blocks repositories from containing the malicious exploit.

  What should I do?

As with all new vulnerabilities, upgrade the affected software. This means upgrading to versions v1.8.5.6, v1.9.5, v2.0.5, v2.1.4, and v2.2.1 of git depending on which maintenance branch you are using.


Why so long to break 128-bit encryption?

When encrypted data using a password, things go that way:

The password is converted into a secret key using a Key Derivation Function.
The key is used to encrypt the data with a symmetric encryption algorithm ("symmetric" means that the same key will be used for decryption).

"128-bit encryption" means that the secret key is a sequence of 128 bits. It tells nothing about the password length or contents.

To break such a file, two possible paths: try all possible passwords until the right one is found, or try all possible secret keys until the right one is found. "Right one is found" means that "decryption works and produces something meaningful / expected.

There are 2128 = 340282366920938463463374607431768211456 possible keys of 128 bits; that's a lot and trying all of them will take millions of years. On the other hand, there are much fewer potential passwords because passwords are chosen by humans with human brains, and human brains are not good at making random choices; also, humans are lazy and will prefer short passwords (easier to remember, easier to type in). Trying all "potential" passwords, i.e. passwords which humans are likely to select, is called a dictionary attack. Any decent password cracking software will first try all possible very short passwords (i.e. 6 letters or less), then try "meaningful words" and derivative. A one-letter password would be cracked within a fraction of a second.


Are there risks associated with a strong password reuse for disk encryption?

The problem is in fact similar to the question you mentionned. You have a password which is reused on several external disks. You encrypted them because you want to avoid data loss following physical theft.

Should for a reason or another your password be recovered (a vulnerability of the crypto one of the disks for instance) then all the disks are vulnerable.


What is the best way to be sure of user's identity?

This is a very difficult problem. It is sometimes refered to as the "level of assurance". In fact, it can be further divided into the entity (i.e. person, company etc) level of assurance i.e. the level of assurance you have that the information about the entity is accurate and correct and the identity level of assurance, which is the level of assurance that the identity using that information is the same identity that is associated with the entity.

A common example of the entity assurance is the 100 points system used by many organisations to verify a person i.e. photo ID, passport, driver's license etc. Each bit of information is given a score based on how reliable the information is for proving someone is who they say they are. A passport may be worth 50 points, a birth certificate 10 points, a drivers license 20 points etc. The person wishing to prove their credentials must provide enough proof to add up to 100 points. This establishes the entity level of assurance. This normally needs to be done in person so that you can verify the photo on the passport/drivers license etc represents the person presenting the proof.

Identity level of assurance is used to prove that the person using an identity associated with an entity is that entity. For example, when you connect to your bank. Often it is achieved with something like a password (least strong) or a combination of things (password plus unique token pous some form of biometric data, such as a finger print (something you know, something you have and something you are).

In your exzample, you probably have a need for both entity level assurance and identity level assurance. Some sites don't have such requirements. for example, facebook and gmail have very low entity level assurance - they trust that the information you provide is true. However, they have increasingly strong identity level of assurance, for example, adding 2 factor authentication.

Normally, any site which reuires high levels of entity level assurance will also require high levels of identity level assurance i.e. if you require the user to provide true and accurate information, you probably also need to ensure anyone logging into the system as that person is actually that person.

Identity level of assurance is usually easier to achieve than entity level assurance. Entity level assurance is very difficult to achieve remotely. Normally, you would require the individual to be physically present so that you can do things like verify the photo on a passport, license etc matches the person standing in front of you. When this is not possible, you usually need to rely on some form of 3rd party to assist in your vetting process. This could be something like a partnership with an organisation which has a large number of public offices - for example, a post office. You might pay a fee to this 3rd party for them to provide a vetting process. An individual wanting access to your service would then need to visit the post office, provide their 100 points of proof and then the post office would provide you with their details and sign off that they have vetted this person with the level of assurance you require. Obviously, you are trusting in this 3rd party. Another alternative is to use a certificate authority. Most of the CAs provide a personal certificate service. The individual purchases a personal certificate from the CA. The CA performs the vetting prior to issuing the personal certificate. Of course, the risk with all these 3rd party solutions is that your trusting they actually do a decent job. As vetting can be an expensive process, some CAs do a better job than others. If you reduce the rigor associated with the vetting you can reduce the cost and in turn provide cheaper certificates, thereby gaining a competitive edge. However, this may result in less confidence/trust in the certicates that are issued.

The other problem with certificates is that it relies heavily on the person managing their certificate in a secure way. If someones certificate is stolen and either it does not have a passphrase/password associated with it or if the thief was able to get the passsword/passphrase, then they can use the certificate and effectively impersonate the user it is associated with.

This all probably makes your problem seem impossible. However, things may not be as bad as they first appear. We often fail to really analyse our requirements and have many inherent assumptions about what we need. It is important to consider that the more personal information you require and the more accurate it needs to be, the more expensive it will be for you and the more inconvenient it will be for the user. It will be more expensive for you because of all the additional safegurds you will need to implement, which means more complexity, which means more development, more testing and more maintenance. For the user, it means more hoops to jump through and most likely, more concerns regarding using your service etc.

In additional to considering whether you need the information, also consider whether you really need it to be 100% accurate. For example, if you require their date of birth, how are you using that information? What is the impact/affect if it isn't accurate? What will the users impression be when you requirest that information? etc.

After you hve gone through all the information and assessed it along these lines, if you find you still require a high level of assurance, then you can look at options such as requiring a certificate, establishing relationships with 3rd parties who can assist in your vetting etc.

Finally, note that your example of faxing/mailing in copies of certificates probably won't be sufficient. I could easily obtain birth certificates and possibly passports, drivers licenses etc of someone else and fax them to you. While these certificates may be 'real', there is nothing that proves the person who sent them is the person the certificates represent. Likewise, if you decided to use something like OpenID or some form of social media authenticaiton, you need to look at what the vetting levels of that identity provider are to know if they are sufficient for your needs.


Can someone know my IP address through Thunderbird email attachments?

Yes, they can, and they don't even need to be especially cunning to do so. But you can prevent it.

When you receive an email in HTML format, the emails HTML code can embed images from an external webserver. Many email clients (not just Thunderbird) will then connect to that webserver to download the image. That way the webserver will learn your IP address. When the sender sends a mass email, they can embed an unique image URL in each individual email. That way they know if, when and from which IP address each email was opened. This is very useful for spammers, because it allows them to measure the success rate of their spam filter prevention measures and identify email addresses with a high view-rate so they can send them even more spam.

You can prevent this in Thunderbird under Tools->Options->Advanced->Privacy->Block loading of remote images. You will then no longer see images embedded in HTML emails which are not attached to the email themself, but most emails of that kind are spam anyway.


Consider the following scenario:

  You install Windows 8.
  You change the Hosts file by specifying custom IP-address-to-host-name mappings to prevent users from browsing to
  some websites.
  You run a scan in Microsoft Windows Defender.

  In this scenario, the Hosts file is detected as a
  SettingsModifier:Win32/PossibleHostsFileHijack malware threat by
  Windows Defender.

Reference

So when the host file is being restored by Windows Defender, Avira's host file protection could be detecting the change.


How to capture not only the mtime but also the ctime when making forensic copies of files?

File archive formats don't capture the ctime because it would be pointless since it's impossible to restore it¹.

For forensics purposes, you need to keep things simple, because you need to be able to prove that the data you captured is genuine. There's no escaping doing a low-level copy of the block device that contains the filesystem. For analysis purposes, where you sift through the data to figure out what is interesting, you can use complex data extraction methods, and verify your findings against the real data afterwards.

Using ls may be tricky if the files have names containing special characters such as spaces, newlines or unprintable characters. Also ls prints an approximation of the time which is timezone-dependent and annoying to parse. If you must use ls, use the --full-time option of GNU ls to get an unambiguous time display, and make sure that you're using a set of options that print the file name unambiguously and that you later parse the name correctly. Recent versions of GNU ls print the file name unambiguously by default, but the format is relatively complex.

Linux provides a stat command which prints more metadata including all the timestamps and the inode number. *BSD systems including macOS have a stat command with a similar purpose but completely syntax. Beware that they print the file name literally, which can make the output ambiguous if some file names contain newlines.

Of course, do all of this from a view of the filesystem that's as read-only as you can get. For forensic purposes, it's best if the first thing you do is to make a copy of the disk through a hardware dongle that ensures that it doesn't modify the source, that way there won't be any doubt that you corrupted the evidence. If the legal risk is low, you may dispense with the special-purpose hardware, but at least make sure that you've made the block device read-only. Doing a read-only mount of the filesystem (mount -r) is not enough: it guarantees that you won't update timestamps, but it will replay the journal, so you can't claim that your capture didn't modify the evidence.

¹  If you're root, you can change the system time, but that impacts the whole system so it would be extremely disruptive.


Is the Linux kernel vulnerable to LazyFP (CVE-2018-3665)?

To cite the information from Redhat:

  RHEL-7 will automatically default to (safe) “eager” floating point register restore on Sandy Bridge and newer Intel processors. AMD processors are not affected. ... You can mitigate this issue on older processors by booting the kernel with the eagerfpu=on parameter to enable eager FPU restore mode

For Debian it looks like that lazyFP is fixed for anything using a 4.9 kernel or newer. Debian also links to the kernel commit message from 01/2016 where eagerfpu was enabled for all CPU by default.

As for other distributions one need to have a look which kernel is used, which patches are maybe applied and which configuration settings where used. There is simply no "the Linux" but instead lots of distributions which use different kernel versions with different patches and different settings etc.


If you haven't already done so, read Amazon PCI FAQs and request their PCI Compliance Package.

That being said, all you're doing is adding another server to your PCI scope.  As long as you add the AWS site to your Qualys scans and ensure that the handling of the data is in line with PCI requirements (e.g. encrypt across public networks), there's no reason you shouldn't be able to do what you want in a PCI-compliant manner.


Chrome browser reports obsolete cipher (AES_256_CBC with HMAC-SHA1)

The problem is not the SHA1 but the CBC. You need to offer an AEAD cipher like the GCM ciphers or   CHACHA20-POLY1305. From the Chromium (base for Chrome) projects documentation about cipher suites:

  To avoid this message, use TLS 1.2 and prioritize an ECDHE cipher suite with AES_128_GCM or CHACHA20_POLY1305. Most servers will wish to negotiate TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

You don't offer any of these ciphers so you get this warning. See also this answer for more details. See also the source code of Chromium, notable the function ObsoleteSSLStatusForCipherSuite in net/ssl/ssl_cipher_suite_names.c where this check is implemented.


The Vista/7 Ophcrack will work on Windows 10 hashes. I've run it myself, against both NTLM and LM hashes.

The only time that I've seen aad3b435b51404eeaad3b435b51404ee and 31d6cfe0d16ae931b73c59d7e0c089c0 is when the passwords are actually unset/empty/disabled. These are explicitly detected and marked as "empty" by Ophcrack:

It really does look as though the hashes that you found are classic empty hashes.

Once you get some non-empty hashes, Ophcrack should work fine.

(Side note: but it will only run the wordlists/tables that you feed it, which is somewhat limiting compared to modern capabilities. On modern systems with GPU, you can cover a lot more ground and have overall higher success rates with a full cracking suite like John the Ripper or hashcat. I would suggest demos of those also, to supplement your demo.)


A GPG_AGENT is a program that when asked, (de|en)crypts the data for the caller (in this case using gpg). The 'files' you see are most probably sockets for communicating with the agent.

Once the program is closed (or locked), it can't be used, those files don't contain any private information, agents are (generally) pretty-well designed, and won't even store private material out of ram (in most cases, the OS may not allow memory locking, or if you hibernate the computer, the keys can go into disk).

In regards to your question

  Also, what is the correct procedure to clear/stop the keyring agent and thereby make it forget all the passphrases it is remembering.

You don't specify which agent you are using, the basic approach is to kill the agent process, but it will probably support unloading the keys / being put into locked state. See also
How to lock a unlocked GNOME Keyring?

¹ See if the first mode character is s, eg.

  srw------- 1 indiajoe indiajoe 0 jun  8 21:57 agent.1234


How does IPsec turn KEYMAT into Encryption and Authentication Keys?

The IPsec stack does not create it's own keys, or request any keys for that matter, instead the IKE daemon generates as much key material as required for the negotiated encryption and authentication algorithms using the PRF+ (which can basically return an arbitrary amount of key material). How key material is taken from the expanded KEYMAT is described in detail in RFC 7296 (IKEv2), section 2.17.
The resulting keys are then passed with the rest of the information about an IPsec SA to the stack. With the standardized PF_KEY interface, for instance, this is done with two Key extensions if encryption and authentication is used.


Kingston Data Traveller Vault Privacy - more password attempts

The "correct" way to implement hardware encryption on a flash memory device is to encrypt with a key stored in an inaccessible part of the device, which is itself encrypted with the user password. This means that the device can be "wiped" simply by wiping the key and replacing it with another one. The reason for this is in how flash memory devices work: they are built with some spare capacity which is used to compensate for individual memory elements failing or wearing out through the expected lifetime of the device. However, this also means that data may exist on sectors which are no longer writable, so it wouldn't be possible to securely wipe them. This isn't a major problem if the entire device is encrypted - the remaining data, even if it can be extracted from the non-writable sectors, is encrypted, so remains secure. By removing and replacing the key, the data can effectively be rendered unreadable, without increasing the load on the flash memory with extra writes.

If a device instead encrypts based directly on the user input, you can't avoid the extra writes - you can't just forget the key, since the user has it, and may have left it lying around elsewhere, where some malicious person can find it and use it to decrypt the data.

The result of all this is that if a manufacturer has constructed their drive in the "correct" way, the password you enter is only used to decrypt the key which is used for the rest of the data. Since this is intentionally inaccessible, you can't usually extract it for offline brute forcing, even if you can extract the rest of the data on the device. It also means that brute forcing the actual key used doesn't mean working out the relatively short password that you'd enter, but instead working out the internal key, which could well be much longer - even something relatively insecure, like a SHA-256 hash of the word "password" would be 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8. That's infeasible to brute force when you don't know the key length or composition...

Now, it's possible that the manufacturer has implemented a different method, where the input is directly used to encrypt the data, but the steps outlined above are pretty well known and, given a reasonably secure key store on the device, really difficult to break.

I'd say that the data on that device is probably gone, unless you get lucky with the last try...


How does a website instantly know if a certain credit card number is wrong?

Checksums

CC numbers, as well as pretty much any other well designed important numbers (e.g. account numbers in banks) tend to include a checksum to verify integrity of the number. While not a security feature (since it's trivial to calculate), a decent checksum algorithm can guarantee to always fail if (a) a single typo was made or (b) two neighbouring digits are swapped, which are the two most common errors when manually entering long numbers.

http://rosettacode.org/wiki/Luhn_test_of_credit_card_numbers is an example of such a test.

Issuer

If a CC number is technically correct, it may still be not a real CC number. The method for verifying that is simple and complicated at the same time - generally, if you have appropriate access you are able to the look up the issuer institution for each range of card numbers, and then you ask the issuer[s card systems] if they think that this is a valid card. Well, the second part generally happens as a part of making a CC payment, but verifying the issuer is sometimes done before that as an extended test; but not on the client browser.


Full-disk encryption and theft mitigation?

Disk encryption is about preventing access to data, unless a specific authentication token (e.g. a password) is presented. Full disk encryption is about doing that on the whole disk, including the OS, so the machine won't even boot without the password. If it does not boot, then, in particular, Prey won't work.

What you can do is to allow the machine to boot on a minimal OS which uses Prey and controls a virtual machine, which is the actual machine you use for all your usages. That VM will use full-disk encryption.

This should be doable with reasonably low overhead with Xen: a minimal low-RAM dom0 system, which runs Prey and has no disk encryption, and the actual domU system which allocates most of the physical RAM, contains your files and applications, and uses full disk encryption. Note: if you want to do that with Windows as domU, you will need a computer with supports the hardware x86 virtualization instructions (AMD-V, Intel VT-x...); this is not necessarily a given on Netbooks.