How do you manually encrypt text to an md5 hash? I am aware that you can do something like go to md5online.org or something, but I want to know how to do it manually. For example, you might encrypt it like by taking the length of it and turning the number to hexadecimal. I highly doubt that is how you do it, but that is just an example. I know it is impossible to decrypt it, unless you do guess and check

First of all, let's be clear: encryption (encipherment) and hashing are not the same thing. Hash functions convert an arbitrary-size input into a fixed-size output, which by necessity loses some data and is therefore not reversible. If there isn't any way to get back to the plain text - and there isn't, with a hash function; you might find something that produces the same digest but you can't prove it was the same as the original - then it's not encryption.

Second: you shouldn't be using MD5 for anything, anymore. It's broken. If you don't require security, there are non-cryptographic functions that are faster to compute and produce outputs which are smaller to store/transmit. If you need security at all, use a modern and secure cryptographic hash algorithm, such as a member of the SHA-2 or SHA-3 family.

With that all said: MD5 is an algorithm that operates on bits (although in practice nearly all implementations operate on bytes). There are multiple ways to encode text as bits (binary), most commonly ASCII (which is seven bits per character but widely extended to use the eighth bit of a byte to hold additional values), UTF-8 (each character is stored in one or more bytes), or UCS-2 (or its extension UTF-16, where each character is stored in two - or possibly more, with UTF-16 - bytes).

To hash anything, you take the input (might be encoded text, or an image file, or a network packet data structure, or...) as a buffer, and call the desired hash function with that buffer as an input parameter. For text in particular, you simply take a representation of the text in the desired binary encoding and pass it as the input buffer to the hash function. Every non-toy programming language has some native encoding of text (which may or may not be already suitable for use as a hash function's input buffer), and has functions to convert a text string to a byte array of a desired encoding.

All general-purpose programming languages should also have at least one library that implements the most common hash functions. You can also invoke programs to do it from the command line (or from a shell script), such as md5sum or openssl dgst -md5, although they might not be installed by default on your machine (depending on OS and install configuration).


Spectre: Problem with Understanding POC - Reading data from cache I understand the vulnerability (Spectre) and, in theory, what the PoC does. But I do not understand the part of the PoC, when it reads or identifys the data from the cache, between the lines 86 - 108. I know that the PoC is reading the data from the cache by measuring the time of reading from *addr (at l. 90), but what exercise has results[] and why mix_i hits the cache when it represents the byte at the address of the cache hit?

what exercise has results[]

It is not an exact art. The cache may be hit for an index which is not the one hit by victim_function. The threshold might lead to borderline results.

So the code runs the attack 999 times and increments results[mix_i] when it thinks there is a cache hit. It then selects the result with the highest result value (most expected cache hits) and assumes that is the correct value for the victim byte.

  why mix_i hits the cache when it represents the byte at the address of the cache hit?

mix_i is just a way of shuffling i.

for (i = 0; i < 256; i++) {
    mix_i = ((i * 167) + 13) & 255;
    ...
}

The above results in mix_i being initialised as each value between 0-255 once only but not in the order 0,1,2,3 (as i is). This is done for the reason stated in the comments - to prevent stride prediction;


How exactly would SOPA-style DNS blocking threaten the security of the Internet? A point that keeps getting mentioned in the SOPA debate is that the DNS blocking it prescribes will cause security problems. Can somebody explain in simple terms just exactly how SOPA threatens Internet security?

The main security-related concerns raised so far are

attackers may use false infringement claims as a denial-of-service attack.
ISPs may start doing deep packet inspection on their customer's traffic, to look for infringing content.
it may interfere with the effectiveness of, or take-up of, DNSSEC.


Are strong WPA2 passwords "good enough" for WiFi security? I'm currently using WPA2-PSK with CCMP on my home WiFi network for encryption and security.

I was a big fan of MAC filtering, until I realized that MAC addresses are publicly sniffable in the 802.11 packets.

Is WPA2-PSK with CCMP "good enough" for WiFi security in light of programs like oclHashcat, which can bruteforce passwords like there's no tomorrow? As the entropy on my WiFi password increases, do I get actual security benefits, or is unauthorized access inevitable?

The short answer is probably.

The actual answer depends entirely on what "good enough" means to you.

Do you need to disallow WiFi altogether? Perhaps you really need Ethernet cables run in pressure-monitored shielded conduit run under an access-controlled, video-monitored raised floor with locks on the exposed ports? Okay, that is overkill for almost everyone, but just almost.

Like almost all security questions, you need a risk analysis. Maybe not a formal one, but at least go through the risks and costs in your head.

What is the impact of unauthorized access?
What are you trying to protect?
What is the impact of disclosure?

In your case, take a look at some oclHashcat performance benchmarks. How long is your WPA2 password? How big is the search space for a password that long, with those "types" of characters (digits, alphas, symbols, etc.)? GRC has a convenient calculator.

On average, an attacker will have to search half the search space to find your password. Given how fast they can search (which depends on what amount of resources the attackers are will to put forth), how long will it take to find your password?

Can you live with that? Can you simply change your password more often than that? Are you willing to take that risk?

To answer your specific questions:

yes, as the entropy on the WiFi password increases, you get security benefits in the form of an increased password search space, and
yes, unauthorized access is inevitable given enough time

My work site has a WiFi password that has a search space of 4.23 x 10^33. oclHashcat can guess 350k or so passwords a second on the system used in the benchmark. Assuming the attacker has 1,000,000 of those boxes at their disposal, or at least 1,000,000 times the compute power, they can try 3.5 x 10^11 passwords a second. It would take them on average 2 x 10^14 years to find the password. Good enough for me. Even if they are a million times luckier than average, I'll have changed the password before they find it.

Of course, they could guess right on their first try. Or in their first few minutes of guessing. Or they might have some knowledge of the password that they can reduce the search space (e.g., they know how long the password is, which characters can be used, what the first 5 characters are, etc.). Maybe the WiFi password is written on a white board that can be seen through a window from the street, making this whole discussion moot.

Again, it all comes back to what the acceptable risk is to you.


ISO 27001, Skype, online CRM... compatible? My company is B2B, our services include hosting data about our clients' users.

Data protection laws are important to us, and we must observe them carefully as our clients rightly demand their users' data is kept safe.

We are looking at obtaining ISO 27001 certification for 2 main reasons:

Force ourselves to follow rules and methodologies that help us keep that data safe
As a sales tool: in theory if we are ISO 27001 certified potential clients will trust us their data easier

So there are 2 sets of information: our clients' users' data, which is critical to be kept secure, and other data, such as our contacts database, our internal tasks and projects planner and calendar, sales presentations, etc. which so far we have created mainly through online tools like a web-based CRM, Google Calendar, and spreadsheets, EverNote, etc.

Finally my question: Must ISO 27001 cover all data and procedures across the company, or can it just apply to our core and most critical clients' users' data, and everything else (online tools like Google Calendar, an online CRM, Skype, Evernote...) we can still use, provided we don't publish any of the core data through these tools? We have been told no more Skype or online spreadsheets, the CRM must be hosted by us, any other web-based service like Evernote or similar is banned. Which is quite inconvenient because typically there is little choice in terms of tools you can host yourself in order to have absolute control over the data.

Whoever has said that you cannot use some specific technology because of ISO27001 probably has some other vested interest - possibly even just laziness. The standard does not mandate what you can and cannot do. It effectively defines the way you need to manage risk and how you need to demonstrate that you are managing risks.

There are many organisations who are compliant and who use Office 365 or even Google Work. Even more that have all manner of external communications from Skype to Slack, etc.

What matters is having a robust process for identifying and acknowledging the risks and mitigating them.

A specific example may help. Though not directly related to ISO27001, there are a number of doctors in the UK who are holding patient consultations over Skype. That requires certified risk management well beyond that normally expected from ISO27001 (think the UK equivalent of the US's HIPPA).


Where to save the token information? I'm currently working on an end user Windows 10 application using the Microsoft UWP platform. Within this application the end user will be able to authenticate themselves using an oauth2 SSO service.

So here is the question:

  Where should the client application (the Windows 10 app) store the access token and the refresh tokens ?

I've been looking a multiple options:

Just save the access token and the refresh token in the Windows Password Vault at user level (not encrypted).
Use the data protection provider for encryption and store the token values in a simple config file.

What would you guys do ?

The main goal is for me to keep the credentials safe from malware that might steal the tokens and also make sure that the only person who can see the token values is my application and the end user itself (the person who used the SSO service).

The easiest is going to be using the DPAPI as its just straight forward function calls. Chrome uses this to encrypt cookies at rest on disk.

However if an attacker is aware this is being used and they can execute code under the user context they can call the same functions to extract data. If this is normal malware, the likelihood is low of this occurring.


Dualbooting Windows and Ubuntu, can I get Windows viruses/malware while running Ubuntu? Today I have both Windows and Ubuntu installed on my SSD.

What happens if I for some reason get a malware/virus (targeted for Windows), perhaps downloading something I should not, while I am running Ubuntu?

Will the malware/virus find a way from the Ubuntu partition into the Windows partition and eventually do something with my Windows files? Assume that I have downloaded some malware (targeted for Windows) on my Ubuntu partition what is likely to happen?

If you had two viruses in play, one that infected Linux with a payload to infect Windows, then it could conceptually happen. However, a native Windows virus cannot run in Linux at all. The reason why nothing would happen has to do with something known as the "Application Binary Interface", or "ABI" for short.

In Windows, most system calls are performed through something called "INT 20h", while in Linux, system calls are performed through "INT 80h". This means that a Windows-based virus that tries to call the system through 20h would simply terminate without causing any harm, as INT 20h is a "DOS-compatible terminate program" command.

In reality, most virus writers are going to go through the path of least resistance: write a Linux virus to infect the currently running Linux system, and write a Windows virus to infect the currently running Windows system. It would take a significant amount of extra effort just to write a virus whose only purpose was to infect an offline OS.

As far as I know, it would be far easier to simply write a hypervisor virus that runs "underneath" the OS, as then the ABI would have no meaning, since they'd have direct access to the hardware and memory.

On the other hand, if you download a virus intentionally, for example, you were trying to get a copy of a game from a questionable resource, and you did this in Linux, but downloaded the file to your Windows partition, and you later ran the program in Windows, then you could indeed get infected at that point. The main point, however, is that Linux is impervious to Windows viruses, and Windows is impervious to Linux viruses. They simply do not speak the same language.


secret key compromise in SSL vs in Kerberos Consider the consequences of compromise of a secret key in the Kerberos system vs. in SSL. For example, suppose your individual shared secret key (for your user account) becomes compromised (i.e. it is learned by someone else) in Kerberos. And suppose a widely used certification authority's (CA:s) RSA private key becomes compromised. In which system is it easier to revoke the compromised key (i.e. prevent its being used by an adversary who obtains it), and why?

Kerberos is an on-line mechanism that is centralised. You could in principle change your Kerberos password instantly. (There might be further problems if the attacker beat you to it, but let's assume you could phone up support to change it in this case.)

Tickets issued by Kerberos have a limited lifetime (e.g. 12 hours, although this is configurable), and also have a limit in the number of times they can be renewed (which can be configured in the KDC). Here are typical settings in Active Directory. A compromised secret would have a limited effect, within the lifetime of existing issued tickets.

In contrast, PKI are intended for more distributed usage, where clients and services don't have to contact the CA every time one of its certificate it used; checking for certificate revocation in a PKI (via CRL or OCSP) tends to be an optional step. Not all clients do it. Certificate also tend to have a longer lifetime (typically one or two years), which would mean that a client failing to check for revocation would still consider a compromised certificate as valid for a much longer period of time.


Cascading hashes to increase computational difficulty The question I am asking is: is there some reason why the following method does not make it significantly harder for an attacker trying to brute force the input (or using a dictionary attack)?

This question is perhaps not entirely practical, but is inspired by the idea of bcrypt, but without needing to actually implement bcrypt when you have SHA handy. To put it in context, I tend to use a method of string manipulation and hashing to generate passwords for websites. Basically, you take some secret string, say, TheNameOfMyLongDeceasedHamster, append something obvious to do with a website TheNameOfMyLongDeceasedHamsterFacebookUserMrBoink put that through something like SHA256, take binary output, convert to base64, and take the first 16 characters. I figure one will find it difficult to get the secret string even if you know the output of this process and the site specific input. I've pondered a simple method of making it more computationally expensive, since it is no loss to take say 0.25 seconds on an i5 laptop to compute a single hash in javascript, but naturally if someone wants to try and find the TheNameOfMyLongDeceasedHamster given the output of this (and possibly search/replace pairs) and perhaps some kind of dictionary attack, this makes it all the harder to try.

The idea is a little naive, and I'm wondering if there are any serious drawbacks that security experts know of?

The idea is as follows:

Step 1. Take a well known text (something you can easily find). For me, I take the Latin Vulgate of the Sermon on the mount, remove all punctuation, convert to lowercase and split into separate words. This yields an array like

["videns","autem","jesus",...]

and it is assumed any attacker has access to this text. Importantly I only need to remember how to reconstruct it.

Step 2. Specify a number of pairs of words, e.g

var wordsmap = "in:humpty et:dumpty cum:hmmm";

and convert to the form

var wordsmapa = ["in:humpty","et:dumpty","cum:hmmm"];

and then replace via

var fluff = "videns autem jesus ...";
for(i in wordsmapa) {
   fluff = fluff.replace(wordsmapa[i][0],wordsmapa[i][1]);
}
fluffwords = fluff.split(" ");

to get

["videns","autem","jesus",...]

where some words may have been replaced. (The replacing bit is optional, but has uses, e.g. if I change 'jesus' in the string to whatever my username is, just bunging 'SecretStringtwitter' through this process will yield what looks like a nice strong password for my twitter account, e.g. 'lG0aFybg0/zGLPCO'.)

Step 3. Take a hash function, such as sha256, and iterate (it is of course important/useful to ensure everything is uniformly e.g. hex strings or byte buffers)

function hashcascade(x) {
    for(var i=0,l=fluffwords.length; i < l; i++) {
        var w = fluffwords[i];
        t = hash(t+w);
    }
    return t;
}

so to use we do

secretstring = "TheNameOfMyLongDeceasedHamster"; // obviously this will not be in plaintext in the source, but taken from the user somehow
specificinput = "FacebookUserMrFluff";
hashinput = secretstring + specificinput
hexout = hashcascade(hashinput)
binout = hex2bin(hexout)
b64out = btoa(binout)
result = b64out.substr(0,16)

As such, take the first 16 characters from the base64 of

hash(hash(hash(...hash("SecretStringSpecificStringvidens")+"autem")+"jesus")...)

Is there some reason why this does not make it harder for an attacker trying to brute force the input (or using a dictionary attack)?

Finally, used this way, any change to the secret string totally changes the output, as does any search/replace on the 'known text' used to generate the word array.

I am toying with this method do create/recreate passwords, so as to have a concise zero-storage password manager, relying on memorising a single secret string, using some intuitive guess for what the word replacements should be, and then something obvious like the domain name of the website. Put all this through the above procedure, and say 0.25 seconds later, out comes your password.

I'm very confused by your question, because on the one hand you mention bcrypt, a password verification algorithm:

  This question is perhaps not entirely practical, but is inspired by the idea of bcrypt, but without needing to actually implement bcrypt when you have SHA handy.

...but then it switches gears to password generation:

  To put it in context, I tend to use a method of string manipulation and hashing to generate passwords for websites.

But these are unrelated problems, so a solution for one isn't necessarily applicable to the other.

But in any case, as far as I can tell from your explanation, you are proposing a system for generating derived passwords deterministically from these inputs:

A secret master password;
A public identifier for the derived password (e.g., FacebookUserMrFluff);
Some additional public parameters (the word list and the substitutions).

One problem here then is that, because the scheme is completely deterministic, an attacker who is able to get a hash+salt pair for one of the derived passwords (or a plaintext password from a site like any of these) can then mount a brute force attack to recover  your master password.  And if they succeed, they can then compute all of your derived passwords—past, present and future.

Maybe iterating the hash function many times raises the cost of the brute force attack against your scheme.  But why allow such an attack at all?
Compare to this commonplace bit of user-side password management advice:

Use randomly generated passwords of good length;
Store them in an encrypted password manager.

In this case, since the passwords are randomly generated, they're all independent—an attacker who cracks one of them cannot leverage that to figure out any one other password.  An attacker would need to steal your password database to launch a brute force attack against your other passwords—whereas in your scheme they just need a single derived password.

Other than that, if you "have SHA handy" there is already a standard iterated password hashing solution for that: PBDKF2.  So even if you insisted in using this questionable method for generating deterministically derived passwords, there is no need to resort to your odd algorithm.


Kingston Data Traveller Vault Privacy - more password attempts The Kingston Data Traveller Vault Privacy USB drive has a default amount of 10 password entries before it is erased. I am left with one and the question is whether any of the following two approaches will allow me to excercise more attempts to type the password (I should know the correct one, it's just been a long time since I have set it up). I do not intend to brute force it.

copy the encrypted data from the drive and perform decryption outside the drive
copy the encrypted data as a backup, enter the password on the drive, allow it to format itself and then copy the backuped data onto the drive again
learn the AES representation of the stored password and try to guess the password outside the drive's environment and put in the correct password only after the matching AES representation has been found
any other ideas?

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

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

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

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

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


Advantages of separating Web server from Database What are the security advantages of installing the database of a web application on a server other than the one containing the web server?

Well the first obvious advantage is that if someone breaks the box that houses your application server, they are not guaranteed access to the same server that houses the database.  Also, by separating this functionality you make it easier on the IT (software devs, admins, etc) to minimize code change impact / policy updates on different aspects of the environment.  This does not in any way fix poor coding or weak security (SQL injection, default username/passwords). but it does facilitate a better security posture overall.


Best way to know the algorithm used for a password encryption I have the following password captured using sqlmap-

 $2a$08$9eaKUtKdFV8fuOAx0sfr4emrG1aHzGeNsn/rVdW243nw6Ktt.Uc0O

Now, I don't know how to decrypt this password because I don't know which algorithm was used for its encryption.

I have tried online free decryption tools, but none of them find the way to discover which algorithm was used.

How are passwords stored?

Passwords are not (or at least should not be) stored using encryption. They should be stored using a hashing algorithm. So if you are trying to decrypt it to recover the original password, then that isn't going to work.

Here are some links to read about how password storage works:

https://crackstation.net/hashing-security.htm#normalhashing
https://en.wikipedia.org/wiki/Cryptographic_hash_function#Password_verification
and a much, much longer one here: https://security.blogoverflow.com/2013/09/about-secure-password-hashing/

How to figure out which hash algorithm was used?

Let's break down your sample password:

(This section is completely quoted from A. Hersean answer below. Please scroll down and give them an upvote)

According to wikipedia and the passlib documentation we can deduce :

"$" is a separator
"2a" means that the algorithm used is bcrypt with the blowfish hashing function;
"08" is the cost parameter, i.e. 2^8 rounds;
"9eaKUtKdFV8fuOAx0sfr4e" is the 128 bit salt encoded in Radix64;
"mrG1aHzGeNsn/rVdW243nw6Ktt.Uc0O" is the hash encoded in Radix64.

Even knowing that it's a hash and not encryption, it's still hard to reverse-engineer which hash algorithm was used (this is by design).

Tools to identify hash type

If you google for "hash identifier tools", you'll find plenty of free websites. Personally, I like the linux command-line tool hash-identifier (in Kali, or hashid in Ubuntu):

~ hashid
$2a$08$9eaKUtKdFV8fuOAx0sfr4emrG1aHzGeNsn/rVdW243nw6Ktt.Uc0O
Analyzing '$2a$08$9eaKUtKdFV8fuOAx0sfr4emrG1aHzGeNsn/rVdW243nw6Ktt.Uc0O'
[+] Blowfish(OpenBSD)
[+] Woltlab Burning Board 4.x
[+] bcrypt

I hope this has been helpful!


Major industry password leaks using salted HMAC but without eg PBKDF2, scrypt I'm trying to convince higher-ups on a project to use an iterative strengthening function to secure password-storage for a new system. The current proposal would store something like an HMAC of a salted SHA-256 (presumably the other HMAC inputs are being stored separately for bonus security).

The security developers speak a different language so it's basically impossible to communicate with them directly, or determine exactly the requirements. I went straight to the higher-ups who only seem to understand business case studies. I've been told amid my protestations that basically the only way to convince them would be to find some real-world examples of major password leaks that used both a salt and HMAC but not iterative strengthening, and had many passwords compromised as a result.

Please understand I'm not going to try to attain the impossible and get them to implement the exact standard recommendations for password storage. I just want them to consider iterative strengthening.

Are there any prominent real-world examples where salt and HMAC were used, but due to lack of iterative strengthening, many passwords were compromised anyway? Bonus points for well-known companies such as Facebook, LinkedIn, etc.

Perhaps it's also important to point out the breaches that have occurred where there was no evidence of compromised data. LastPass, for example, used "5,000 rounds of PBKDF2-SHA256" and a random salt (https://blog.lastpass.com/2015/06/lastpass-security-notice.html/). Since the breach, there have been no indications that the master passwords were broken.

That's not to say that we will ever necessarily know if the database is broken. If, for example, the database was exfiltrated and resides on a user's machine it doesn't mean that he will post successfully cracked passwords to Pastebin.

It would be a good segue to introduce the idea with the statement that minimal user accounts would be compromised before a password reset is issued. Thus reducing risk and legal liability.


How to check whether firewall allows traffic on specific port but not listening on the port I have client / server and there is a firewall between them.The server is listening on a port and I want to check if this port is allowed by the firewall.
 I can only know the ports that the machine is listening on using netcat, but I want to know if the server port is allowed to pass.

The easiest solution without having to fire up your server application would be to use netcat.

user@1.2.3.4 ~$ nc -vl 1234
Connection from 9.8.7.6 port 1234 [tcp/*] accepted

user@9.8.7.6 ~$ nc 1.2.3.4 1234

Please forgive me if this does not answer your question as this does create a listening socket. I just wanted to share this as an option.


Is it a bad idea to use base-64 encoded strings for passwords? First off, forgive me if this seems like an extremely naive and un-educated question. Any ways, so as above, is it a bad idea? I mean, thinking about it, it doesn't seem like a bad idea. My logic is this:

Sites should store passwords securely anyway, with salts and hashes (and sometimes peppers). Using a standard password such as Password (for examples sake only) this would be salted and hashed into a much more "unreadable" format for storage when used for an account on a website. If done as it should be, should take a while for anyone to decrypt the password.

Now if I base-64 Password into UGFzc3dvcmQ= and then use that as my password - I already have an additional 3 characters and then included that being salted and hashed - Should create a more secure hashed password? Right?

Does base 64 ultimately cause a password to be any more secure? Do websites either base-64 encode / decode before salting and hashing?

I get that if someone does manage to get the password DB and has a list of all the hashes, and assuming they manage to decrypt my password back to UGFzc3dvcmQ= I get that its an easy guess to base 64 decode it, as its an obvious looking string.

Ultimately, will it serve me better using base 64 encoded password as opposed to full on cleartext? Also, what if I perform multiple encodings adding additional characters between encodes? For example:

password > UGFzc3dvcmQ= > U**E**GFz**n**c3**C**dv**o**cm**d**Q**E**= > VUVHRnpuYzNDZHZvY21kUUU9

All questions of the type "Will this clever trick make my password any safer?" depends on the same thing: What passwords does the attacker try first when brute forcing the hash? The person attacking you is not stupid, and she will try the things that are most likely to succeed first, and the less likely ones later.

Unless the attacker is specifically targeting you, and knows about your encoding scheme, she is more likely to try the unencoded password before the encoded password. So in that sense, this is a win for you (at least until everybody starts doing it and it gets so common attackers starts trying this kind of thing early).

But is it very practical? Are you going to memorize the encoded string? Then why not just memorize something random (and thereby safer) instead? Are you going to use some online service to encode the password every time you use it? Then you might have it sent over HTTP and recorded in logs all over the internet, and thats not very good. So are you going to install some software thad does the encoding locally? Then why not just install a real password manager instead?

So yes, in a narrow sense UGFzc3dvcmQ= is a better password than password. But no, this does not alleviate the need for completely random passwords and password managers.


App hosted Oauth login pages: what stops forgery? I've been thinking about Oauth login which works wonderfully for websites in general.

However these login types are becoming more prevalent in apps, both desktop and mobile. In these situations often the challenge page from the third party is displayed in an in app window, not a browser.

In these cases the hosting application could definitely fake the third parties challenge page to steal the users credentials.

Are there any best practices or systems in place to prevent this?

There is an RFC specifically adressing oauth2 in native apps: https://tools.ietf.org/html/rfc8252

It advises that the app uses the OS browser (Safari / Chrome) rather than show the login window in a web view or handling the credentials in the app.

But in this it largely aims to train the user in what a login is supposed to look like, rather than to provide specific controls to prevent the app from misbehaving.


How do I prevent users from using my iOS apps unless they have been authenticated on a server? I've tried to find an answer to this question for a while now, but my efforts have been fruitless. I've found several articles and questions about offline authentication, but these are mainly concerned with storing login credentials locally after a user has already logged in once online.

The reason I want to implement such a system is because certain groups should have access to my applications for free, whereas others which do not fall under these groups should have to pay in order to use these applications. To my knowledge this is not something that is supported by the app store. Additionally eventually the series of applications should support other devices, so it makes sense to have a common login service.

These applications don't need resources from a server. The server is used merely for authenticating the user.

When a user launches an app they must log in before they can use the app. The authentication takes place on a server and is already sorted. The question is how I can restrict use of the application, which is already installed on the device by the time the user is prompted log in. If this were a web application I would store a session cookie which is then used whenever a resource is requested. In my case all resources are already on the device, so if someone is stubborn enough they will be able to use the application without logging in first, but I don't want this to be too easy. If there is some offline equivalent of a session cookie that I can use to verify that the user has logged in as the app is being used that would be ideal. I'm not storing any sensitive information in the applications nor would it be a catastrophe if someone were to gain access without first logging into an account, but I would like to know if there is a good way to solve this problem.

When users launch my applications they should be prompted to login
After logging in users should be able to use the application, and it shouldn't be too easy circumvent the log-in process

I'm not asking for details, but I've hit a dead end and would like to know about any technologies or techniques that might help.

I think you have either over-complicated the issue in your head (common practice for us developers) or you have a design flaw in your system. Could be both.

Your question states:

  How do I prevent users from using my iOS apps unless they have been authenticated on a server?

The answer to which is: don't allow the app to start until a user has logged in. When you start the app, start it straight to a login screen. But, it appears you already have that in place:

  When a user launches an app they must log in before they can use the app

So, really your question appears to be:

  how I can restrict use of the application...?

Your user accounts need to have roles. At minimum, a free and premium user role.

Upon successful authentication, the user should obtain a token, which gives them use of the app. For the purposes of this discussion, I'll say "unrestricted access to the app" to avoid the complexities of unlocking only this feature or that feature, which is completely possible depending on your architecture.

The token should not only give access to use the app, but also have an expiration option, but that's up to you. (If a free user is perpetually free, and a premium user is a one-time-fee yields a perpetual license, then expirations are not necessary).

Once the user logs in for the first time, your user authentication server will issue a token based on their role and status. If they are a free user, they will receive this token, which gives them unfettered access to the app. If they are a premium user, then the server will withhold the token unless the premium has been paid.

Although the implementation method is a little out of scope for security.stackexchange.com, I'll do a simplified version here because I think its part of the underpinnings of your original question.

The complication comes at this question: how do your premium users pay to unlock the app? You can't have a free and a paid app because everyone would just download the free one and never pay.

You're only left with the option of a single app and altering the user role based on a paid (or even subscription) status.

Since you've posted this in iOS, I'll reference In-App purchases. The app should be free by default with in-app purchase options. When a free user downloads the app, they can request their free account (or, if they belong to a given group that has a coupon code, etc... they need the option of entering that, which will change their role on your server to a free user role).

Otherwise, you can leverage the in-app payments to upgrade the account to a premium / unlocked version.

This being said, having an app be "free" and then immediately require an unlock code or an in-app purchase will be a "high friction" implementation.

If you decided to go with a free and paid version in the app store. The free version would simply require a coupon code to activate the free subscription. Or, in the alternative, it would have to wait for your staff to approve the new user. (Lots of work for a free app).

The paid version would work right after the download. Here, you're restricting the "high friction" implementation to users who are getting free stuff anyway. Paid users have a smooth as butter transaction.

  The authentication takes place on a server and is already sorted

If your authentication server does not support roles, then this isn't sorted, which may be a design flaw that needs to be revisited. Especially considering that if you don't currently have user roles, you certainly would need to have code that either queries Apple's API for subscription status, or have code that receives an event when a subsciption / fee has been paid to change a user's role.


How to do server side validations in Java to prevent XSS? When i use method Get and  intercept the request with any proxy tool. then Cross site scripting because of absence of server side validations.
But in case of post method, as we know data flows in the body of the request and when i intercept any body parameter with the script, then again XSS executes.

I want to know do i need to do server side validations on each screen or is their any global thing which can save me from XSS. I am using Java J2

The OWASP cheat sheet has a number of suggestions for mitigating XSS attacks.
If you already have a framework you are using (e.g., Spring or Struts), they might have some protection mechanisms that can be configured.
If you are looking for an add-on framework, consider OWASP ESAPI or the OWASP Java Encoder Project.


Is accessing /proc/ inside docker container a security breach? In a docker container I am reading the files /proc/stat and /proc/meminfo. As I understand they are the ones of the host. (Not local to the docker container)
In a meeting, a co-worker said that this is a security breach and must be vetted by internal security consultants.
The container does neither run privileged, nor as root. My program inside the container does neither.

Question 1: is he right in saying, that this is a security breach?
Question 2: What if I bind-mounted the host's /proc directory to some folder of the container. Would that then be a security breach?

What you're able to see from the process running in the Docker container is a filtered view of the hosts /proc filesystem.  It's somewhat less than what any process running on the host could see.

on Q1 Whether this is a security breach depends very much on the environment you're operating in.  For most environments, this isn't likely to be an issue, you might want to ask your colleague what exactly he thinks the problem is (i.e. what information is being disclosed from those locations that compromises the security of the environment)

On Q2 bind mounting /proc is a somewhat different story as that will expose a lot of information into the container which may be sensitive.  Again it may or may not be a problem depending on your environment, but it's a more risky prospect.


Store a file on a harddisk without root having access to it Is there a way to store a file on a disk as a user so that even the root user has no access to it?

I tried EncFS but that is no solution because the root user can switch to every user, so he/she can read the encrypted files too.

How can I store a file on the server so no-one can read it but me?

Maybe somehow store it spread it redundant accross the unused diskspace and keep the inodes in mind to recover it via checksums?

Ye cannot defeat root !

The root user can have complete control of the machine. The best that you can hope for is encryption: use GnuPG to encrypt the data with a sufficiently strong random password, that, of course, you won't reveal to the root user.

However, as soon as you decrypt the file on the machine, wherever you put it, root will be able to see it. Similarly, root has all the required power to plant a keylogger (and thus grab your password) or modify the gpg binary so as to recover a copy of your precious data as soon as you encrypt or decrypt it. The best you can hope for is the following:

You may hope to "fly under the radar" by making your file inconspicuous, not to be detected through some massive scans that the administrator runs regularly. This requires that you delete the decrypted file as soon as possible; this assumes that root activity is indeed a nightly scan or something like that.

On a general basis, this concept is known as steganography.
You could encrypt and decrypt the file elsewhere, e.g. on your own laptop computer, using the machine-with-hostile-root only as storage space. That way, the root will only ever see the encrypted data, and not know the contents.


We want to give an outside party access to a demo environment. How do we ensure only they get access to only their version of the environment? We are currently setting up a system where we can create demo environments for prospective clients to use, where we host those demo environments in our own DMZ. The idea is that if a prospect wants to try our product, we create an environment for them, then make it so only that prospect can access that environment.

Some details:

The environment is CentOS 7;
The product consists of 2 environment-hosted GUIs, supported by a number of services that also run in the environment;
The prospect should have mostly full access to the environment (not root, but things like interacting with the file system, making changes to some of the software);
We will have a separate environment per prospect and a prospect should only be able to access one environment.

This system is intended to mostly replace our current error prone and labour intensive process of helping the prospect setup the system on their local network.

The problem we have is that we need to give the prospect access to the environment over the Internet, but in such a way that only they can only access that particular environment they are assigned to. We don't want someone other than the prospect accessing the prospect's environment, and we don't want the prospect accessing another prospect's environment, and DEFINITELY not other machines in our DMZ.

Our current idea to solve this is by using private key authentication, which from what we gather is the proper way to allow only a single party access. However, we still need a secure way to get the key file to the prospect, who often is too far away to hand it over in person.

so 2 questions:

Is there a secure way to provide a prospect with a key file if you can't hand it over in person?
related: is key file based authentication the best way to grant a single client access to a single system?

You could virtualize the whole thing, create a virtual network for a single demo environment and deploy an environment on a per user basis. You can then indeed use key based authentication for accessing the environment. After the user has reviewed the demo you destroy the environment.

Your automation, if done properly, should be able to fully build, deploy, generate  key files and then send them to your client.

Normally this works is a bit differently. The client would supply you with their public SSH key and you would add this key to your machine in the ~/.ssh/authorized_keys.


Where to find or purchase non-SSL certificates I hope this is the right stackexchange - if not, please advise.

As to the actual question: have a system we've developed that makes heavy use of asymmetric cryptography in various different ways (RSA, client certificate authentication, and digital signatures), and in our recommended configuration uses 8 certificates - 4 SSL certificates, 1 signing certificate (for SAML), two client authentication certificates, and an RSA certificate (for protecting symmetric keys.) In our development and test environment, we've used self-signed certs generated with the makecert.exe utility, but that's not at all suitable for production.

What we'd like to know is: can you acquire and/or buy those sorts of certificates from a certificate authority? Will any old certificate do? So far, we've only found SSL certificates for sale and talking to support at various vendors has been..less than helpful.

We're also considering setting up a CA on site (with Active Directory Certificate Service) to cut down on the number of certificates that have to be purchased, which leads into the same vein: can you purchase/obtain a certificate suitable for use as the root for a local CA from an upstream CA? Is it basically an SSL certificate?

A certificate is basically a binding between an identity and a public key, but there are details:

The notion of "identity" which is most adequate for your situation is not necessarily the same as the notion of identity for a SSL server certificate (i.e. a server DNS name...).
The lifecycle of the private key matters: who generates it, where it is stored, whether there are backups...
The certificate contents may activate or deactivate some usages, and you may want some control over that.

If you want to produce your own certificate, then you want to operate your own Certification Authority. There is nice opensource software for that (e.g. EJBCA). However, this course of action entails two main cost areas:

You have to operate the CA. PKI is 5% technology, 95% procedures; having the software is fine, but running it, managing physical access, renewals, audit... will be what costs the most, by far.
Certificates from your CA will be accepted by your machines only if the public key of your CA is installed in these machines as a root CA, or if your CA has been issued by another CA which is installed in your machines as a root.

Using certificates from a "commercial CA" solves the second point, but at a heavy cost. In particular, if you want to have your own CA, then it must be marked as a "CA certificate" (that's written in the Basic Constraints certificate extension). A commercial CA may accept to issue to you a CA certificate, signed by their own, but it will be expensive (think thousands of dollars, at least); and they will require that you operate your own CA within strict rules (including insurance, publication of a detailed and legally binding Certification Practice Statement, and so on).

If you just want to produce certificates for your own usages, on systems that you control, then it makes relatively little sense to rely on a commercial CA: it is much easier to simply have your own root, and install it in all relevant machines.

It is also quite possible that your problem at hand does not actually call for true "certificates". Certificates are a solution to a key distribution problem: the point of certificates is that a given system can gain knowledge a public key, and confidence in the identity of the key owner, dynamically, by virtue of seeing and validating a certificate. If, in your system, there are 8 keys altogether and you have control over all client and server, then chances are that you do not really need certificates; you just want asymmetric key pairs. Public keys are published a priori (pushed through configuration or hardcoded in relevant software).

For easy and cheap compatibility with existing protocols (e.g. SSL), it may be convenient to encode the public keys as something which looks like "certificates"; traditionally, these certificates will be "self-signed" because there is a non-optional field for a signature in the certificate format.

There is nothing intrinsically wrong with self-signed certificates if they map to your problem at hand. There is no need to invoke a PKI if your situation does not have a key distribution issue.


How can I make sure Linux only uses secure connections? Suppose I need to connect to the internet but I cannot (or I don't want to) trust anything outside of my laptop. Therefore I will need to make sure all connections are secure, so I guess this means they should be encrypted and the destination should be able to be trusted.

To browse the web, I can use Firefox with the plugin "HTTPS Everywhere" set to "block every unencrypted request", and if I'm not mistaken I guess that should be enough for surfing the internet. However, browsing the web is only part of the story. There could be some processes or applications that don't make secure connections, including "default" or "core" applications like the system updater itself, or some applications maybe be misconfigured. So what should I do to make sure Linux only uses secure connections that can be trusted, even at the cost of having to avoid or block any insecure connections?

To browse the web, I can use Firefox with the plugin "HTTPS Everywhere" set to "block every unencrypted request", and if I'm not mistaken I guess that should be enough for surfing the internet.

-

  basically not trusting anything between my laptop and the destination, especially not trusting the local network (and not trusting VPNs either). Some exceptions could be made for example for Google's DNS, I can trust their services, but not everything that's between me and them (unless the connection is secure). So you see why the question is about "secure connections"

This doesn't make any sense at all. Why would you trust a TLS encrypted connection to random sites, but not trust a VPN solution?

TLS will not protect you against malware. It will protect you against eavesdropping and MiTM-attacks.

Ubuntu, for instance, uses signatures and timestamping to secure updates against tampering, even though it's transmitted over plain http. At worst, an attacker can force you to not get updates; he can't really give you malware via the update mechanism.

If you have a remote device you have to access securely, set up a VPN to that service, terminating as close to the service as possible. Drop all other other outgoing traffic from your laptop.

Oh, and I'm very curious about your chain of thoughts leading to your conclusions about security...


Can KRACK be used to obtain wifi credentials that could be used to normally connect to an AP? I have a pretty simple question about KRACK.

From what I have read it would be very common to be able to forge, decrypt, delay and block client packets as well as AP packets using KRACK.

Does this mean that an attacker could get some sort of login credentials in order to normally connect to the targeted AP? Or would the attacker have to remain in his/her MITM position?

In case the attacker would have to remain in the MITM position, could he/she use only manipulate/read the traffic of a user or could he/she also for instance establish a TCP connection and surf the Internet etc?

An adversary using KRACK can decrypt information that is transmitted via WiFi that should be encrypted. This can only be done after a victim is authenticated to an AP. Read more on how the actual attack works here. So no, it is not possible to obtain the credentials.

However: if you were to change the password of your AP while an adversary was reading your traffic, s/he could also read the new password, if the connection to your router is not protected by another form of end-to-end encryption.


Is DNS service secure? I am based outside of the US, but I still want to watch Netflix. So I am thinking about signing up a DNS service such as unblocked-us, but I worry that as I am now querying an unknown ( relative to Google DNS, that is) DNS server, my details over the internet may not be secured, as the DNS service provider, or hackers can hack into the DNS server and leak my browsing habits and my other private information.

What do you think? Do you think that my fear is warranted?

From what I understand, unblocked-us is setup by pointing your computer to their DNS server. Their DNS server answers ALL DNS requests with their own servers, thus becoming a proxy/MITM.

E.g. you want to goto Youtube.com. This would resolve to 173.194.112.104
in a regular DNS server. However going through Unblocked-us DNS server
they would yield a different reply, their own IP address. This can be
illustrated better with the nslookup command:

nslookup netflix.com 8.8.8.8 (Google DNS)
Server:  google-public-dns-a.google.com
Address:  8.8.8.8
Non-authorative answer:
Name:    netflix.com
Address:  69.53.236.17

nslookup netflix.com 208.122.23.22 (Unblock-us)
Server:  UnKnown
Address:  208.122.23.22
Name:    netflix.com
Addresses:  173.208.170.14
      192.227.246.14
      204.12.200.14
      67.216.222.14
      172.245.210.14

This is absolutely dangerous. You are not only querying someone else's DNS server, you are actually proxying everything through their servers as well. Whether you want this or not is up for you to decide.


MySQL AES_ENCRYPT key length AES_ENCRYPT uses a 128 bit long key to encrypt the data, but how MySQL handle longer or shorter keys? I found out that PyCrypto for instances recomend to transform the key by using MD5, SHA-1, SHA-2, etc. hashes and then using the the resulting key for encryption. How does it work with MySQL?

MySQL 5.5 does not handle other key sizes. As stated on http://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html:

  AES_ENCRYPT() and AES_DECRYPT() enable encryption and decryption of data using the official AES (Advanced Encryption Standard) algorithm, previously known as “Rijndael.” Encoding with a 128-bit key length is used, but you can extend it up to 256 bits by modifying the source. We chose 128 bits because it is much faster and it is secure enough for most purposes.

I never tried to pass bigger key to MySQL, but I guess it would yield an error or truncate to 128 bits.

I'm not sure if MD5 use it's full codomain because I can't find any proof of that MD5 is a surjection. So I assume that you will get less  security by using MD5 hashes since you reduce the set of possible values for your keys. This is still very subjective.

As far as smaller keys are concerned, I guess that 0x1 == 0x00...01 so it is still a valid key.

By the way, I do not understand why you just don't generate key to the given size. If you have some constraints (already existing key you want to reuse, ...) let us know.


StrongSwan, IPsec remote certs and cert_policy I'm looking for a way to limit the certs that my IPsec can accept. I'm using StrongSwan (swanctl version 5.7), I want to accept only certs coming from a remote with a name of yoji.*.example.com

I searched a lot on the internet. The documentation does not give any solution except modify on the client-side, which I'm not able to do at the moment.

I found something called Cert_Policy but I didn't understand how to apply it, I don't understand how it can help or how to use it.

Can someone help me with this? Or if you have a solution or a modification to modify on the config file that I could try it would be much appreciated!

The cert_policy constraint (swanctl.conf) enforces specific OIDs in a certificate's certificate policies extension, so that might not be what you are looking for.

As for matching identities with wildcards, strongSwan currently only allows ignoring complete RDNs (not parts of them), for instance, C=CH, O=strongSwan, CN=* (multiple RDNs may be ignored). With domain names and email addresses (e.g. in subjectAltName extensions of type dNSName/rfc822Name), only prefixes can be ignored (e.g. *.strongswan.org, or *@strongswan.org).


Is it ok to use the same password for many services with two-factor authentication? Let's say that I've a relatively strong password, but I don't want to use many different passwords for each different service, and let's say that those services provide two-factor authentication using a password and a TOTP, for example like Gmail, Facebook, ...etc

Is it still secure to use the same password on those services as long the second factor is different?

If that other factor is enough to protect your security for you, then sure.  The point of multiple passwords is that if one is compromised, they aren't all compromised.  If you reuse the password and one account is broken, that factor is broken everywhere it is used.  If you don't mind a one time code being all that stands between an attacker and your Gmail account, then there is no reason not to use the same password.  It is certainly far less secure, but it's also far more usable.  It's a personal choice based on what you think the tradeoff is between security and usability.


Does Heartbleed vulnerability affect other libraries (like BouncyCastle, .NET's SslStream, etc.)? pretty much the title, how to know if the Heartbleed vulnerability (for OpenSSL) affects other libraries like .NET's SSLStream or BouncyCastle.

(Sorry for ignorance, but have found no info on how to exploit, to see if is related to bufferoverruns and other things that shouldn't happen in Java/.NET).

The so-called "heartbleed" exploit is a buffer overrun. A read overrun, to be specific: the attacked system is induced into reading and sending back bytes from a buffer which is much shorter than the read length, thus reading whatever bytes reside in RAM past the buffer. Since the bytes are sent back to the peer, this gives a window to peek into the target system RAM.

It is unlikely that any other implementation of SSL shares the same exact bug. It is plausible that other SSL libraries have buffer overruns of some sort (nobody really knows how to write bug-free code), but not exactly that one. Or, said otherwise, if another SSL implementation has the same heartbeat-related bug, then it probably is a spin-off of OpenSSL.

Moreover, for implementations written in a language where array accesses are systematically checked for bounds (typically Java or C# or Python or Scheme or OCaml or just about any language which is not awfully low-level like C), the consequences of a buffer overrun are different, and usually preferable: instead of reading the extra bytes and sending them back, the offending code traps, triggering an exception which implies termination of the thread or process or connection. The bug is still there, not the far-ranging exploit; the leakage of secret data has turned into a basic potential denial-of-service, which will often be limited to closing the affected connection, therefore not denying much service after all.


What is the argument for the fairly prevalent "No more than n repeating characters" password rule? So, I understand why most commonly used password policies are used.

N character minimum? No low hanging fruit left for brute force attacks.

N character maximum? The database field can only be so long.

No unicode? The underlying database doesn't support it.

Include at least one letter, special character, number, and heiroglyph? Adds a few extra required bits.

The one I can't for the life of me understand though is the rule where no more than n consecutive characters (commonly two from what I've run into) may exist in the password. I can't think of a technical reason to do this, and it actually reduces the available password pool, thus making a brute force attack take less time. This practice seems too wide spread to not have some justification, I just can't think of what it might be.

This rule does not make much sense. I believe the rationale between this rule is to avoid people padding their short passwords with repetition of a character (which is a pattern, hence identifiable by password crackers) to meet the minimum length, instead of entering different characters to create a more complex password.

E.g. if the user enters Jane1 as a password and the min length is 8, it will be refused. Then the user might just chose Jane1111. With the rule enforced, he'll be forced to choose something like Jane1yxc. However, he might as well choose Jane1234, which is actually more insecure than Jane1111.


SQL vulnerable if input type = email check is enabled <input type="email"
class="form-control"
name="email address"
id="signinEmail"
placeholder="Email address"
aria-label="Email address"
value="INPUT"
required=""
data-msg="Please enter a valid email address."
data-error-class="u-has-error"
data-success-class="u-has-success"
aria-invalid="true"
aria-describedby="signinSrEmail-error">

regarding above quoted input field (each param in a new line for easier reading purposes)

Are those kind of input fields, which check specifically for valid_characters@valid.valid SQL-Injection vulnerable in any kind of way? Do I risk being exploited by implementing this kind of input field (which I discovered being used by someone else, so no credits go to me for creating this code.)?

I mean by trying to exploit with "HARMFUL CODE"@test.com won't work, the harmful code itself won't work as well, etc.

//NOTE:

<form class="js-validate mt-5" name="signin" action="/signin" method="post">

mentioned input field is member of said form class, which validates the SignIn via post-method, thus I think it's fairly secure implementing such code on a website, right?

SQL injection is a server-side vulnerability. It has almost nothing to do with your client-side code. If you do all your validation on the front end, what happens when a malicious user decides to not use your front-end at all, but instead send requests directly to the server?

So, this does not protect against SQL injection at all. To properly protect against SQL injection, implement server-side protections. You can use a modern web framework and/or ORM that completely abstracts SQL away, or follow the OWASP Cheatsheet.


Generating ECDSA certificate and private key in one step Similar to how it can be easily done for RSA:

openssl req -x509 -nodes -newkey rsa:2048 -rand /dev/urandom -keyout example.key -out example.crt -days 365

I'd like to generate an ECDSA cert/key in one step. I've tried:

openssl req -x509 -nodes -newkey ec:secp384r1 -keyout ecdsa.pem -out mycert.crt -days 30

Returns the below error

  Can't open parameter file secp384r1.

I am trying to specify the curve to use. If a key file exists, then you can specify it with ec:example-ecdsa.pem and it will work.

Possibly something like this could work with tweaking:

openssl req -new -x509 -nodes -newkey ec:$(openssl ecparam -name secp384r1) -keyout cert.key -out cert.crt -days 3650

This seemed to be the command you want:

openssl req -new -x509 -nodes -newkey ec:<(openssl ecparam -name secp384r1) -keyout cert.key -out cert.crt -days 3650


How would one verify that the public key from WhatsApp's servers belongs to the person I expect it to? WhatsApp had recently announced end-to-end encryption on all communications. While that's an impressive move, I still have a big open question mark.

The articles and this white paper suggest that the public key, upon generation, gets stored on the server. When I want to speak to another person, I ask the WhatsApp server for their public key, and use that in communication.
That same white paper says this about key verification:

  WhatsApp users
  additionally have the option to verify the keys of the other users
  with whom they are communicating so that they are able to confirm that
  an unauthorized third party (or WhatsApp) has not initiated a
  man-in-the-middle attack. This can be done by scanning a QR code, or
  by comparing a 60-digit number.

Oh, that's nice, how are those things generated?

  The QR code contains:

  A version.
  The user identifier for both parties.
  The full 32-byte public Identity Key for both parties.

  When either user scans the other’s QR code, the keys are compared to ensure that
  what is in the QR code matches the Identity Key as retrieved from the
  server.

But... those are all details that the server knows, and requires nothing special from the other person (it doesn't mention the QR being signed). How about the 60 digit number?

  The 60-digit number is computed by concatenating the two 30-digit
  numeric fingerprints for each user’s Identity Key. To calculate a
  30-digit numeric fingerprint:

  Iteratively SHA-512 hash the public Identity Key and user identifier 5200 times.
  Take the first 30 bytes of the final hash output.
  Split the 30-byte result into six 5-byte chunks.
  Convert each 5-byte chunk into 5 digits by interpreting each 5-byte chunk as a big-endian unsigned integer and reducing it modulo
  100000.
  Concatenate the six groups of five digits into thirty digits.

Again, those are details the server can easily calculate and present to me as valid verification data.

Am I misunderstanding this, or is there no real way of verifying that the public key I'm talking to belongs to the person I think it does?

Both the QR code and the 60 digit number need to be verified "out of band", for example:

Saying the number out loud in a telephone call
Meeting in person and scanning the QR code directly from the other device


Can I build trusted electronics device now a day? For example, if I want to build my own circuit to read or test USB stick content, then often I must use a computer to write driver, load driver...

That computer must use an OS like Windows or Linux... and even the code and the program that I use to load the driver to controller might be compromised and alternated.

So in the end, it is very hard (nearly impossible) to do everything from scratch without using third party hardware/ software/ OS/ code. But if the security is required, can this be done with enough budget? If it is not, then what is the alternative?

Another approach I can think of is just building the device any way, then test it, e.g. read and verify the content of the driver with different devices/ methods.

Another approach is build multiple generations electronics. E.g. the fist laptop is used to build a simple keyboard to write code, then that keyboard is used to write a second generation keyboard with different code/ approach... then with some generations the possibility of the keyboard is compromised is low enough to use to write code to new electronics device..

This is not only apply to simple circuit, but for example, a security customized laptop/ phone might be compromised because the wireless IC is compromised.

So how to build trusted electronics against the thing like, e.g. NSA?

I'd consider using open sourced OS like Fedora, Mint, Ubuntu etc.

Open Source Projects are now having more developers than ever and projects are really well monitored and maintained, like Kernel, GCC, glibc etc.

It's quite important to use still maintained and well reviewed libraries to build new software, and do it in such fashion that keeping it up to date is not difficult.

At NSA, they have requirement to use Mandatory Access Control which is called SELinux in Fedora. It's good even on the desktop, you can sandbox command line utility which is running on another user, which gives you similar process security to the one on Android.

Regarding firmware, the good approach is to be able to over-write and read all firmware by yourself, which is mostly doable today. Like you can read / write BIOS (and even lock it permanently), you can load firmware to Ethernet and Wifi.

And keep the source code in Git. It makes sure that there's no one tampering anything.

Regarding plugging USB sticks, you can disable certain types of devices from ports, like allow only storage but not keyboards etc.


/dev/random generate session key if a server uses /dev/random to generate the random session key with a client. How you can launch a Denial-Of-Service (DOS) attack on such a server?

You might refer to the problem that reading from /dev/random will block on some systems if there is not enough entropy available. Quickly drawing entropy from the system by creating lots of session ids might thus lead to the application blocking when creating another session id, thus making at least this specific part of the application not respond for some time - a denial of service attack.

How exactly one can make the application create new session ids depends on the application but for typical implementations it might be enough to send a single HTTP request which does not have a session cookie yet and sending lots of such requests can easily be automated.


Is there a full disk encyption software that shows different content depending on what password has beeen used? I'm searching for a 256-bit full disk encryption software that allows me to access different content on the same disk with different passwords. Like: Password A opens partition 1, password B opens partition 2, password C opens both partitions. Same principle with folders would also be sufficient. Is there a software like this?

TrueCrypt had a Plausible Deniabiliy feature that allowed a hidden encrypted volume inside another encrypted volume. It is not maintained anymore, but you can check CipherShed and VeraCrypt which are forks of the original project.


TLS to secure Basic HTTP Auth Basic Auth, including Bearer tokens, depend on using TLS to prevent eavesdroppers from getting at your sensitive credentials or tokens.  But I think there is an Elephant in the room that nobody talks about.

Users often only type in "www.somesite.com" in stead of "https://www.somesite.com".  AFAIK when you don't specify the protocol, the client browser will first try the default, un-encrypted HTTP connection.

The problem is that the user is basically asking for an un-encrypted connection to be made to the server because that's the default when no protocol is specified.  The browser could potentially include sensitive information in the request headers, including Basic Auth credentials, Tokens, (and even Cookies that are not set "Secure")

For API clients that send tokens the situation is similar, but partially mitigated by hopefully well written client applications that

Actually use only the SSL encrypted port to connect to, and
The Developer actually turned the "Check the SSL certificate"
option on before he published their app.

I'm of a mind to set up a MITM proxy on my home network to start checking and logging the apps that I use.  In particular I want to spoof some DNS records and see whether the apps actually baulk at sending your credentials/tokens to the wrong server.

I personally would have preferred JWT to be specified as being sent in a SECURE cookie only, rather than in the headers...  Does anybody here think my concern is not warranted?

EDIT: To clarify:  I'm not so much worried by the weakness of SSL or attacks against DNS, I am more worried about credentials being exposed because clients end up sending it over unencrypted connections in any case, whether due to user's bad behaviour or because the client just follows redirects to SSL ports but only after sending the user's credentials.  When designing APIs I will from now on add a listener on the unencrypted port.  If it receives any token on that port, it will

Not Redirect, and
invalidate the credentials, and
send the user a warning.

Hopefully developers who write apps that consume these APIs will get the hint.  Would blacklisting the IP for a few hours be too harsh?

P.S. Note:  With Secure cookies we still depend on the browser being correctly implemented.

the client browser will first try the default, un-encrypted HTTP connection, potentially including your Authorization header if the browser has got this details.

I think this assumption is wrong: The browser distinguishes between http:// and https://, i.e. credentials entered on https:// will not be included when accessing http:// and vice versa. This means the browser will only include the credentials for basic authentication on http:// if the user has entered the credentials before on http://. And the browser only asked for the credentials on http:// if the server issued a 401 (authentication required) on http://. If the server instead simply redirects to https:// and only issues the 401 there then the browser will never ask for the credentials on http:// and thus not store the credentials for http:// and not include the credentials on http://.


Installed sketchy Chrome extension - Potential malware infection? So... Tired me was browsing through Ikea's website this morning and tried to use one of their visualisation tool. Got an error message saying that I was not running the lastest version of Adobe Flash. Reluctant at first because I thought about their security issue a while ago, I still went ahead thinking "meh, they must have fixed it by now". I went to the chrome store, looked for a flash player extension and as a freakin dumbass, took the first one I saw without taking a look at the publisher and the few number of reviews for such an extension. As soon as it was installed, it opened a page for a music store out of nowhere. This is when I knew I f*cked up ...

I've immediately removed the extension. I uninstalled Brave this evening when coming back home, deleted all remaining brave folders on my ssd and performed a full system scan with Avast and a threat scan with Malwarebytes (both free versions). Nothing came out. I've also checked for any weird process running (via the task manager) and found nothing special. Should I be worried and is there anything else I should do?

The extension in question was Flash Player, offered by flash player... Yes I know, I should have seen that...

Thank you,
Oberom

I assume the extension you installed was https://chrome.google.com/webstore/detail/flash-player/ooonkoejkmhiacbhhkdgfeemioceapbh

It is named "Flash Player" and states it's "Offered by: flash player". I checked version 1.1.3. On install it opens https://themusic[.]io/

The requested permissions are:

Read and change all your data on the websites you visit
Manage your downloads

The music page it opens because on install it opens https://flplayer[.]net/welcome, which redirects there. On uninstall it opens https://flplayer[.]net/uninstall which simply says "Sorry if we don't fit your needs See you next time!"

Another interesting page is http://flplayer[.]net/config.php, from which it fetches a bunch of configuration options. This includes a value named analyticsId ("UA-117750115-1"), which seems an identifier for Google Analytics (seems unused), and a mixpanelId (58410f8ab299e0eb2b736f6e233eda37) which is used if extendedAnalytics was set.

Another weird feature it has is that when rendering embed box, if the protocol is https it gives the urls through the page https://greatapptst[.]com/redirect.php?url=<url> (which proxies anything)

As the browser itself mediates what the extension can do, I do not think it could have escaped to install a system program (no, not a keylogger, either). At most, it could have published some information about your browser and pages. Specially about the pages you visited after installing it. But apparently you uninstalled it immediately, so even in that case there's not much it could have harvested.
If you had, I


Is Shadowsocks MITM-able? Shadowsocks is a secure SOCKS5 proxy which utilises various ciphers (default AES-256-cfb) to protect the traffic in transit.

Shadowsocks uses symmetric encryption and, according to the site the server provides no messages back to the client if the shared secret is incorrect.

Therefore if my ISP wanted to perform an MITM attack they would need to compile a new version of Shadowsocks that accepts any shared secret (since they don't know what my shared secret is) and then spoof the IP of the original server I was connecting to, thereby capturing my traffic.

Is my thinking correct? Does this mean that all symmetrically encrypted network streams are mitm-able?

... need to compile a new version of Shadowsocks that accepts any shared secret (since they don't know what my shared secret is) and then spoof the IP of the original server I was connecting to, thereby capturing my traffic.

There is no such thing as "accept any shared secret" by the server. The secret is not transferred inside the connection but it is a pre-shared secret, i.e. client and server are configured with this secret and only after this is done the first connection can be established.

Thus the ISP can only MITM the connection if he gets access to the secret, either by hacking into client or server or by brute-forcing. From a look at the python source code brute-forcing is not that impossible in my opinion since the ISP can easily know some plain text data (web requests and response have a typical structure) and can pre-build a dictionary of passphrase to encryption key used to speed up the cracking since the same passphrase always results in the same encryption key.


Why do I need root privileges to send a raw packet from a UNIX machine? I was recently reading through the nmap port scanning documentation and it points out that to perform a SYN scan (-sS) you require root privileges because an unprivileged user cannot send raw packets. Why does the OS not allow an unprivileged user to send a raw packet?

The security model in UNIX is traditionally centered around having hardware and network controlled by the network administrators and then having unprivileged users separate from these administrators on the network. In other words: the network and the hardware are considered trusted because they are controlled only by a few selected administrators. This security model can also be seen by the simple security approaches taken by older services which rely on using privileged ports (i.e. port <= 1024) as part of their security - assuming that unprivileged users cannot bind to such a port. They also rely on IP based authentication - assuming that the use of IP addresses in the network is fully in control of the administrators.
Allowing unprivileged users to use raw sockets would break these security assumptions, since with raw sockets anything could be done in the network, like using privileged ports, spoofing IP addresses etc. That's why it is not allowed.
Note that this simple security model is hard to enforce in today's current and complex networks. In times where mobile clients, user controlled devices (BYOD), hardware of different kind (i.e. printer, phone, coffee machine) from lots of different vendors and with often weak security are part of the network, it is kind of impossible to enforce these traditional security requirements. That's why there are new approaches like Zero Trust Networking, which assumes much less control of the underlying network and the systems inside it.


Someone is pretending to be me Need some help!

Someone has opened up an email account and is sending emails pretending to be me, to my office. They are asking for large invoices to be paid into a specific account. We realised immediately this was a fake email account, but my question is, how do we get it shut down? It is a dr.com account.  We have strung them along, just for fun really and to waste their time, but at the end of the day I have a real concern they may somehow be able to access my contacts, in which case we have a real problem.

Any advice? Thanks in advance.

This particular scam is called CEO fraud. Contacting the police is a good idea, and you might be required to do so anyway. I would inform everybody in your company that this is going on, and that they should be prepared for this and similar attacks. Have a look at the security practices in your company, maybe do an awareness campaign.

In all likelihood these criminals will go away once they realize that their method does not work against your company. It is best to be prepared for anything, but usually internet criminals try one method against a multitude of targets, and won’t get too creative against a single one.


How do you create a password list for a forensics case based on the evidence I would like to compile a list of strings and filenames based on digital evidence obtained to make them into a password dictionary. I understand that FTK offers this solution but it's not free to use.

Is there any tools that can help aid this process instead of manually copying each string?

What you're looking for is Bulk Extractor. I haven't used it before, but have heard good things.


How to secure embedded code containing REST api call I am making a Google Analytics like service where you embed generated code into your website and it tracks certain data. I have a backend REST api, but I am not sure how to securely implement a call to it in the frontend without all the authentication data being exposed. I am worried that if a user embeds this code into their website with authentication, such as a session ID or a user ID, anybody would be able to just take that data and make a call to the api before the session times out and mess with the user's data. Is there any way to prevent this risk and safely design the backend api and the call so that it is much more difficult or impossible for people to make calls to a user's private api?

You can have something like a JWT token, where the user (front-end) will know, but can't read it. Then, for each request you send the JWT token and your back-end will know how to decrypt and validate if the user can perform or not this action.


How safe is to store a AES encoded password into a file? Basically, I'm considering to store an AES-Base64 encoded password into a hidden file, with a 600 permission, into a uncommon location of a Unix/Linux server.

That password would be used by an automaton in the crontab to connect into others servers.

How bad is this idea? (Considering that the root user is locked, and the servers don't have any access to the internet, and there's a proxy tunneling to connect into the server that will hold this hidden file)

First, do you really need to use passwords? SSH keys would be much more suitable for "an automaton in the crontab to connect into others servers".

If you do need to store such passwords, the proper setup would be creating a specific (non-root) user account for this case, storing the file in a 400 permission file owned by this user, and having the automaton binary run with setuid bit (https://en.wikipedia.org/wiki/Setuid) set to the same account.

I.e., for a normal user account that file would be readable only through that automaton and not by any other means.

I don't think that encryption adds any security there if the storage of encryption key isn't any more secure than storage of the password.

If the automaton is a binary and you include a key there, then you need to ensure that it's executable but not readable. If the automaton is an executable script, then you can't store the key inside it securely at all.


Secure text document's fingerprint The purpose is the same as with hashing: given set of confidential documents, I want to process them and store something secure like salted hashes/bcrypt.
Later, when new document is given, I want to check if it already exists in database.

Something like leak monitoring.

The problem is that if this new document is slightly modified version of the original one, system should also say that they are very similar.

Trying to solve this task, I considered first normalizing text (getting rid of punctuation, letter case, truncation, etc.) and then doing fuzzy duplicate search (near-duplicates and shingling).

Anyway, I am not sure that it is secure: for example, if shingle window is rather small, then brute force is possible. For window length = 3 and 50 letters, we get 125k combinations and few collisions. Salting wouldn't help either: attacker knows algorithm and can organize brute forcing not as 'xyz', but as 'xyzsalt' and try all 125k 'xyz' combinations.
Who knows what else can be wrong with security of this aproach?

So, that is why I want to ask: are there some secure algorithms for fuzzy matching/near-duplicate searching?

Hashing is indeed the opposite of what you are looking for (any change in the input leads to a completely different hash). You could try a perceptual hash instead.

As a side note regarding your hash/salt attempts:

why would you need salting? It is not like someone could reconstruct the original document (similar to reconstructing a password and comparing it to a hash -> thus the need for salting).
why bcrypt? This is a slow algorithm (perfect for passwords) but in your case you want speed, you do not need to slow down a potential attacker (again, nobody will reconstruct a document to hash it and compare to your hashes)


Web Attack: CCTV-DVR Remote Code Execution (Node.js - Swedish string.js URL) I have been using node.js and running live-server package in my project for a while with the following command:

node node_modules/live-server/live-server.js . --ignore=\"css/sass\" --open=./ --cors

Which uses the default http://127.0.0.1:8080/ address. The laptop I am using has "Norton Security" installed and today, without doing any change to the project's files, the program popped up a high severity alert with the following:

  Name: Web Attack: CCTV-DVR Remote Code Execution
  Action performed: No action is required
  Attacker's computer: 192.168.1.84, 50473
  Attacker's URL: 192.168.1.7:8080/language/Swedish${IFS}&amp;&amp;ping$IFS-c1$IFS-s41${IFS}192.168.1.84&gt;/dev/null&amp;&amp;tar${IFS}/string.js "MY_PC_NAME (192.168.1.7 8080)
  Destination address: MY_PC_NAME (192.168.1.7)
  Origin address: 192.168.1.84
  Traffic's description: TCP, Port 50473
  Origin: \DEVICE\HARDDISKVOLUME3\PROGRAM FILES\NODEJS\NODE.EXE
  Notes: the attack matches the signature of a known attack.

I am on wi-fi (WPA2-Personal) and just ran nslookup 192.168.1.84 and confirmed that this is one of the PCs in the network I'm connected. I am not in Sweden, but this is a place where different foreigners come to use the network, and I can tell by the attacker's computer name that the person is not likely to be Swedish either.

I don't know this person and what this kind of attack attempts to do. The Norton Security program I have installed is finishing its trial period in 4 days, and I was planning to use the default Windows Defender (Windows 10) after that. Any suggestions on how to proceed which doesn't require me cutting off the wireless?

Which uses the default http://127.0.0.1:8080/ address.

127.0.0.1 is localhost and not reachable from outside. If you would really only bind to this address then the attacker would not be able to connect to this server from another computer but only connections from your computer itself would be possible.

But the software you are using does not use the default address of 127.0.0.1 as you claim. To cite from the documentation:

  --port=NUMBER - select port to use, default: PORT env var or 8080
  --host=ADDRESS - select host address to bind to, default: IP env var or 0.0.0.0 ("any address")

Thus, it will not bind to 127.0.0.1 but to 0.0.0.0 by default. This means your server is reachable by default also from outside your own computer. To fix this you should

set --host=127.0.0.1 when starting the server. This will make the server only accessible from the local machine.
and better also enable firewall on your machine in case you have other services running which should not be reachable from outside.


Can firewalls detect and block outgoing by protocol Or specifically, what can be done to detect or block the following (other than closing port 443)?  If this is something that can or cannot be done based on the specific hardware used, please provide what this feature is called.

ssh -p 443 someuser@123.45.67.89

If the IP is static you can block using a firewall port 443 to/from the IPs you want to block. Otherwise, you are looking for an IPS like Snort https://www.snort.org/ You can use it to configure a specific rule for blocking a signature or pattern of SSH traffic with whatever other parameters you might need.


Why are attacks pointed to 'Null island' in tools like Norsecorp? Sometimes attacks are directed to this particular location(0°N 0°E) when looking at  norsecorp:

Does this serve any purpose other than being a location for unknown destinations? How does an attack end up here?

Those tools use GeoIP databases that map IP addresses to approximate locations to display location data as here is no physical way to tell where data is actually flowing (and there's no guaranteed those DBs are true nor up to date).

Sometimes those databases don't know about a particular IP and return 0,0, which is what you see here.


Why enable SMTP STARTTLS if OpenSSL is dangerous? There are a bunch of people in the anti-surveillance movement who are virtually demanding that I enable SMTP STARTTLS support in my environment, in order to enable opportunistic MTA-to-MTA encryption. The same anti-surveillance people are meanwhile complaining that OpenSSL is poor-quality code with a high likelihood of severe undiscovered vulnerabilities.

Is exposing OpenSSL (most MTAs including ours only support OpenSSL) to the Internet a worthwhile risk, for the benefit of opportunistically preventing eavesdropping? It seems like the risk of people eavesdropping on email in transit pales in comparison to the risk of OpenSSL being exploited on the mail server to steal stored data or install a persistent back door.

I think you're overestimating the risk of enabling STARTTLS. Sure, there have been some incidents with OpenSSL recently, but does it mean we should all stop using HTTPS?

In your situation, here is the trade-off:

Using STARTTLS may open up security holes on your machines
Not using STARTTLS will allow anyone snooping (on the network, on underwater cables...) to read the e-mails effortlessly. (Contrary to what you imply, this is not a risk - it's happening, as Snowden's documents have proven.)

Basically, you have to choose between mitigating possible future security issues and defending against current attacks.

Unless you are are a high-profile target and fear that 0days may be used against you, I'd advise you to go with STARTTLS. Alternately, if you really don't trust OpenSSL, you can probably look into GnuTLS (although it had its share of problems too) or wait for OpenBSD's LibReSSL.

UPDATE : A portable version of LibReSSL has just been released by OpenBSD... It still lacks testing, but this means you could yet get the best of both worlds, provided you trust them more than OpenSSL's developers.


Who is talking to my laptop? No PCAP or firewall-- in BYOD environment Is there a method or a linux log to record IP addresses (and other network data) that are attempting to talk to a laptop sitting within an enterprise network from that laptop without running pcap-- thinking BYOD environment?

For instance, if I am sitting in an enterprise network and I would like to see "who today attempted to talk to me, either benign or potentially malicious".....could I see "IP X sent 2 ICMP packets at ___" or "IP Y attempted to connect to your box via ssh" or "your local IP connected to IP Z" , all without running tcpdump/wireshark?

I know running PCAP, setting up a firewall, or a honeypot-like Snort sensor (MHN) would tell me this, however, what if I am just a laptop in a BYOD environment and would like to understand the environment better without the resources of running PCAP.

Thanks!

An easy way to log any incoming (or outgoing) connection attempts is to use IPtables. IPtables has the ability to log arbitrary information to the syslog. An easy way to accomplish this is to set up a rule in the INPUT chain that sends all unaccepted traffic to a new LOGGING chain, which will output those packets to syslog and finally drop them.

iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP

Then, you could watch your syslog with:tail -f /var/log/<log_file> | grep IPTables-Dropped
Source: http://www.thegeekstuff.com/2012/08/iptables-log-packets/?utm_source=feedburner


Sending encrypted file and password by email I know that a password for an encrypted file distributed by email should be sent out of band (i.e. not via email), and that there are better options for distributing information securely.

But, let's say someone ignores this advice and uses email for both, albeit in separate emails separated by some arbitrary time delay.

Assuming that hosted email services are used i.e both source and destination email servers are in 'the cloud' and  we only consider the risk of observation of the emails as they travel across the Internet (between the sender's domain and the recipient's domain).

My initial thought is that it should be assumed that the encrypted file has been compromised, but upon reflection I don't know enough about Internet routing protocols in practice to decide whether their dyanmic nature is a factor for consideration or not.

So the question is: does the way routing protocols work mean that it is possible to come up with a likelihood that the two emails will follow the same route across the Internet and thus both be susceptible to unauthorised observation at the same point?

Ignoring the fact that most data is stolen at the nodes rather than in transit, your thinking isn't really quite right about how networks work, and how attackers think about traffic interception.  Networks aren't just random points on a grid where a different path is chosen all the time.  They're organized in a fashion where there's often going to be common points where interception is possible.  This is where an attacker wants to insert him/her/itself.

Consider how the NSA behaves.  The NSA tries to insert itself into these key points.  You can clearly see this on one of the Snowden leaked slides:  The point being, you don't have to "get lucky" and choose the right path, on the right day when you've inserted yourself into a choke point on the cloud.

Also, consider that attackers make "active attacks" and try to redirect traffic rather than sitting passively and hoping traffic will come their way.  Simple examples of this are ARP poisoning and DNS poisoning.  More sophisticated examples are the NSAs "Quantum Insert" project.


Reflection Attacks on Server I was reading a research paper entitled "Steps to Defend Against DoS Attacks" when I came across this point:

  "A reflection attack on a server would require server-client-server
  communication, and most clients are not going to respond to a new
  connection request from a server and hence reflection attacks on
  server will be prevented"

It was written under the heading of Application of IPv6 addressing aiming to prevent DoS attacks.

My question is that how server-client-server communication is needed for reflection attack on a server?

I Googled for it but couldn't get to answer.

A 'Reflection-based DoS Attack' in the traditional sense means that a number of computers spoof their source IP address to the same address (10.1.1.99) who is supposed to be the intended victim, and then the computers connect to a 'reflector' (10.1.1.88). The reflector attempts to respond to all those connection attempts by connecting to the spoofed address, but ends up flooding the victim with unsolicited traffic.

With IPv6, the addressing scheme is designed to prevent spoofing because a portion of the address is supplied by the network(s) the machine is a part of, so these types of attacks could not be launched.


can someone watch my facebook video chats from a computer im still logged in on? can someone watch my facebook video chats from a computer im still logged in on?
Say i video chat with someone and my facebook is open on a third device, can that third device watch the video im receiving?

No. The video is end to end.  All devices would 'ring' but video is only made to the one that 'answers'.