Why should password hash verification be time constant? In the asp.net core PasswordHasher type there is is remark on the VerifyHashedPassword method

 /// <remarks>Implementations of this method should be time consistent.</remarks>

And then to compare the hashes it uses code that is deliberately not optimised and written not do early exits in the loop.

// Compares two byte arrays for equality. The method is specifically written so that the loop is not optimized.
[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.NoOptimization)]
private static bool ByteArraysEqual(byte[] a, byte[] b)
{
    if (a == null && b == null)
    {
        return true;
    }
    if (a == null || b == null || a.Length != b.Length)
    {
        return false;
    }
    var areSame = true;
    for (var i = 0; i < a.Length; i++)
    {
       areSame &= (a[i] == b[i]);
    }
    return areSame;
}

At first I thought that without this timing could be used to determine how close the hash was, if it takes longer then more of the hash is the same.

However this doesn't make sense because the hash has gone through 1000 iterations of SHA256 at this point. So any change in the password would produce a completely different hash, and knowing that your password produces almost the correct hash does not help you find the correct one.

What is the purpose of ensuring a constant time hash verification?

Assuming neither of the hashes are secret and the hashes are secure (which SHA-256 is), there is no reason to check the hash in constant time. In fact, comparing hashes is one of the well-known alternatives to verifying passwords within a constant time routine. I can't say what reason the developers would give for doing this, but it is not technically necessary to make it constant time. Most likely, they were just being cautious. Non-constant time code in a cryptographic library makes auditors anxious.

More information about the theoretical weaknesses is discussed in an answer on the Cryptography site. It explains how, with a significant amount of queries, it can be possible to discover the first several bytes of the hash, which makes it possible to perform an offline computation to discard candidate passwords that obviously wouldn't match (their hash doesn't match the first few discovered bytes of the real hash) and avoid sending them to the password checking service, and why this is unlikely to be a real issue.


Analyzing UPnP entries from home router I'm using a tplink router for my home LAN and just noticed that in the UPnP section in its control panel there are two entries with App description: Teredo of tipe: UDP and ports: 55566 and 49868

How can I analyze what application is using those forwarding? Does it seem suspicious?
(There is no remove button in the web interface of the router so I cannot just remove those entries...)

The purpose of UPnP is that devices within the network can discover and connect to each other without further configuration by the end-user. That's why UPnP connections are registered by your router, but aren't editable. The only option you have (with your router) is to disable or enable UPnP entirely.

The description of the application might refer to the Teredo tunneling protocol, wich is used to enable ipv6 communication within a ipv4 network. It is suspicious that the ports you mention aren't de default Teredo ports (3544). You might want to check with devices within your network if they have ipv6/Teredo enabled, or if your ISP is providing ipv6 services through Teredo tunneling. As long as your ISP doesn't require ipv6 (most of them don't), then it is safe (and maybe even safer) to disable any ipv6 services within your network.

It is generally regarded a bad practice to leave UPnP open towards the internet, because it can be used to gain access to your internal network. You can test if UPnP is exposed to the internet with this site.

Consider if you have any devices or applications that need UPnP or if you can do without it.


Data integrity of malicious content in the database From a data integrity standpoint, if I persist the following code into my database:

<script>
   alert('hi');
</script>

should I sanitize it before persistence, for instance making < into &lt and then on retrieval doing the decode?  Or is it safer to only sanitize on retrieval, for instance in a UI?

Since injection attacks exploit control sequences in the way the output is interpreted, and since different output formats use different control sequences (think JavaScript versus SQL versus HTML), your sanitization technique needs to reflect where the output is going. If you sanitize for output upon input, you're making an assumption about where that output is going to be sent, which may prove to be incorrect, perhaps due to some future change or some usage case you didn't think fo.

Therefore, as a rule I would suggest sanitizing on output to reflect the specific injection sensitivity for the format you're outputting in.

Note that if you're storing pre-formatted input and the context of the formatting is not available upon output (such as storing HTML for a blog post), you may do some checks upon input, but this is a slightly different scenario than just general escaping.

So again, as a rule escape your output rather than your input, but make exceptions as necessary with the understanding that those exceptions need to be watched with extra scrutiny as you're creating a hole in your app that you need to carefully guard.


Can Let's Encrypt be used by someone like the NSA to effectively break SSL/TLS? Let's imagine for a while that Let's Encrypt is an NSA project, and let's imagine that soon, almost everyone will be using it. Would the NSA have any cryptographic advantage because of that, when analyzing SSL/TLS communication?

Very short answer:

  Would NSA have any cryptographic advantage because of that,

Yes. And that applies to any certificate authority: Whomever your users trust to authenticate your website is able to forge a valid certificate. Verisign, Let's Encrypt, doesn't matter. They have everything they need to make your user complacently be subject to a man-in-the-middle attack.

Note that it is known that some CAs that are trusted by default on many systems/browsers/clients are subject to laws requiring access to the signing keys. And as far as I remember, there's also already publicized cases where law enforcement used that.

  when analyzing SSL/TLS communication?

Aside from the MITM scenario explained above, in theory, no. A CA just signs your public key, it doesn't get any more insight into the encrypted streams.


Real life examples of malware propagated by SIM cards? The laptops in use at my company have SIM card slots, which are actually used by some of our users. I am threat modeling our devices, so I was wondering if there are any realistic exploits that can be used on these laptops, no matter if the users use a SIM card or not.
According to this question, it is in theory possible for malware to be stored on SIM cards, although unlikely. This question was about phones, while I am asking about laptops, but I imagine that if an exploit for phones exists, then an exploit for laptops is also possible and maybe even likely. However, the answers only mentioned that it is possible in theory, but there were no examples given.
So, my question is if there are any real-life examples or just even proof of concepts for malware like this.
Thank you.

TL;DR: For laptops, you should be fine.

Networks: no advantages that couldn't be gained more easily though the Ethernet port. Can be fixed by having BIOS password and encrypted drive (not a threat).
JavaCard applications: Your computer won't run these. They run on phones and the modem in your laptop likely just issues standard AT commands and doesn't implement the menu / control interface.
Access to the operating system: while the SIM card is a computer of its own accord it has a very limited interface (it is a hardware security device) and would just communicate with the modem in the laptop. If someone wanted to be able to hack the modem they would need to find a specific vulnerability in your particular modem. This is getting to new heights of hypothetical and even then your modem is just talking to the operating system though a standard, secure driver.


Why are MD5 and SHA-1 still used for checksums and certificates if they are called broken? I was just reading about SSL/TLS stuff, and according to this site (which is rated as A by Qualys SSL Labs), MD5 is totally broken, and SHA-1 is cryptographically weak since 2005. And yet, I noticed that a lot of programmers and even Microsoft only give us SHA-1/MD5 to check the integrity of files...

As far I know, if I change one bit of a file, their MD5/SHA-1 will change so why/how they are broken? In which situations can I still trust checksums made with SHA-1/MD5? What about SSL certificates that still use SHA-1 like google.com?

I am interested in applications of MD5 and SHA-1 for checksums and for certificate validation. I am not asking about password hashing, which has been treated in this question.

SHA-1 and MD5 are broken in the sense that they are vulnerable to collision attacks. That is, it has become (or, for SHA-1, will soon become) realistic to find two strings that have the same hash.

As explained here, collision attacks do not directly affect passwords or file integrity because those fall under the preimage and second preimage case, respectively.

However, MD5 and SHA-1 are still less computationally expensive. Passwords hashed with these algorithms are easier to crack than the stronger algorithms that currently exist. Although not specifically broken, using stronger algorithms is advisable.

In the case of certificates, signatures state that a hash of a particular certificate is valid for a particular website. But, if you can craft a second certificate with that hash, you can impersonate other websites. In the case of MD5, this has already happened, and browsers will be phasing out SHA-1 soon as a preventative measure (source).

File integrity checking is often intended to ensure that a file was downloaded correctly. But, if it is being used to verify that the file was not maliciously tampered with, you should consider an algorithm that is more resilient to collisions (see also: chosen-prefix attacks).


3DES vs DES for VPN connections I'm trying to get Android 2.1 phones to connect to our corporate VPN, but it would appear they only support DES rather than 3DES for encryption.

Is it safe to use DES, am I going to get hacked if I change the encryption to DES?

In standard terms (i.e. FIPS 46-3, which defined DES and 3DES from the US federal point of view [withdrawn in 2005...]), 3DES is a "kind of DES". So it is possible that by claiming "DES support" your VPN software actually implements 3DES. I am now assuming that you have checked that point and that the software in Android knows only of the original DES, not 3DES (which is kind of surprising for an OS as recent as Android 2.1, but who knows).

Cracking a DES key is feasible but not easy. This is a 255 average work factor. It has been done with specialized hardware (the EFF "Deep Crack" machine), then again with standard PC and other contributed machines (but a lot of them). An FPGA-based generic engine has been demonstrated to cost about 10000€ and to be able to crack a 56-bit key in less than a week (on average). So one has to assume that in a corporate setting (assuming that the "attackers" have huge incentive to discover trade secrets) a VPN protected by a 56-bit DES key can be cracked.

Still, using smartphones to access sensitive data over the VPN strikes me as a much weaker security point. Smartphones are used in unprotected environments (that's the point of having a mobile system...) and are possibly the most frequently stolen object these days. For a determinate attacker, using a FPGA machine is not very expensive -- but mugging the smartphone owner with a 5$ wrench even less so, and, lo! the attacker gets a free smartphone afterwards). If the VPN gives access to anything sensitive, then letting people use it from smartphones is a kind of offence.


What security risks are there in allowing someone to upload PHP scripts? Let's say that a partner wants to upload a PHP script to my Apache server. What kind of mayhem could be caused by this?

Which PHP parameters pose threats? If those PHP parameters are fully disabled, would allowing PHP to be inserted on my servers then be safe?

These are some PHP parameters that I know of that pose a security flaw. What others are there that are unsafe?

  Writing to server:

  fwrite
  file_get_contents
  FILE_APPEND

  Opening files on server:

  fopen
  file_get_contents
  include
  fread
  url_get_contents
  curl_init
  curl_setopt

  Deleting files:

  unlink
  unset

Are there any other security flaws that I should be thinking about before allowing partners to add .php files onto my server? I imagine that there might be a lot that I'm unaware of.

I'm also worried about loop scripts that could use up all of my RAM and CPU, backdoor access attacks, malware and the like. Are there any measures that I can take to prevent any of that and more from happening?

If there is Javascript, JQuery or other languages embedded in the PHP script, are those dangerous as well? And what kind of parameters in other languages would I need to disable in order to protect my server?

How do websites like jsfiddle and codepen keep their sites secure while allowing people to post their own code?

It's very dangerous, because you are allowing to someone to upload PHP file with unknown code and unknown intentions, so if you need this functionality as part of your web site, you should harden your server, for example:

Set a only one directory to upload PHP files from users, you should apply right user permissions (read, write or execution) for this directory, remember create a specific user for this directory, not use root user.
You can create a .htaccess file for directory, then you could set specific settings for that directory (Configuring .htaccess file).
Validate input user, even you should set a specific name format and size maximum for PHP files, if a PHP file doesn't match with that format or its size is bigger than what is allowed then application shouldn´t allow to user to upload that file.
Use canonicalization before use file functions, for example: realpath, basename. This helps you to avoid path traversal attack.
You should disable PHP functions with high risk, for example: exec, shell_exec. You can do this through php.ini file, for example, you could add the following line helps to disable functions for OS command execution and settings management:

disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

The following line helps to disable functions for include or open files from external sources:

allow_url_fopen=Off
allow_url_include=Off

Official documentation php.ini file

Those are some basic recommendations.  You should analyze your web application and your needs to set the right settings for your server and web application.

I hope this information helps you.


How secure is the 2016 XLSX Excel Encrypt with password function? Is this able to be cracked without a brute force? With a long enough password, would I be safe storing my nuclear launch codes in an encrypted excel sheet?

Current versions of Office hash the password a large number of times to create the key and encrypt using AES-128.  I wouldn't protect nuclear launch codes with that, but it's relatively safe.

Can it be brute forced?  With today's technology it'd take millions of computers to do it in a reasonable period of time.  So, yes it can be brute forced but unless you think NSA, GCHQ or FSB are after your data, you're probably fine - assuming Microsoft didn't do anything stupid in the implementation.  As noted on the Matasano Crypto Challenges: "There are tens, probably hundreds, of obscure little things you can do to take a cryptosystem that should be secure even against an adversary with more CPU cores than there are atoms in the solar system, and make it solveable with a Perl script and 15 seconds."


Would appending junk data to user passwords before hashing affect security? I've seen similar questions on the site but not this exact one.

The closest one was Altering passwords before storing where the accepted answer sums up by stating that transforming the password is wasted CPU cycles that could otherwise go into higher iteration count on your actual hashing.

While that much is correct, consider the following scenario:

Lets say your application uses one host for the application code, and another host for the database/storage.
It is possible, that sometime in the future, your database would be compromised, but your application code would remain secret.

If that happens, the attacker may try to reveal user passwords with a mixture of either brute force or wordlists with regex, something that is likely to uncover at least some passwords, and more as time passes.

Obviously, if you found out that your database has been compromised, you'd reset all user passwords. But in the delta time between it actually having been compromised, and you finding out about it, the attacker has a potential attack vector to access certain users' vulnerable accounts.

So I've been thinking, specifically for this scenario, wouldn't simply appending some junk data to user passwords before hashing make this attack vector much weaker? (i.e. make it harder for an attacker to reveal any passwords in time before you find out what happened and reset them)

I'm not talking about general transformations but instead specifically about appending because:
1. it ensures that all passwords remain unique after modification, thus not losing entropy.
2. it's a relatively low cost computation task in the process of a server accepting registration forms and formatting responses.
3. it's simple, and does not add code complexity that would make the application harder to maintain in the future.

The string to append would be a constant string, stored in one place in the application code. Obviously, if the application code gets compromised, the whole thing is pointless. But if only the user password hashes were compromised:

would this be effective at all in slowing down an attacker? (i.e. make it take longer to reveal user passwords using modern methods)

And, in general:

would this introduce any new vulnerability in the system?

Example:

Application server has a constant string: "!@#$%^&(),;"
User A registers with the password "secretpassword"
The server concats the two, creating: "!@#$%^&(),;secretpassword"
Then bcrypts the new string, and stores the resulting hash in the database.

For every future login attempt, the constant string would be appended in the beginning of the user's password (on the server) before recalculating the hash.

Now lets say I have a million users, and an attacker got hold of a million password hashes that my application uses to authenticate the users.
The attacker also knows that I'm appending a constant string to the beginning of user passwords on the server, in fact I'm stating it publicly on my register GUI.
However the attacker does not know the actual string that I'm appending.

would User A's account be safer (i.e. it would take the attacker longer to reveal his original typed password "secretpassword" or find a way to log in to their account and take hold of their data) or would it be the same?
would some other User X become less safe now because of this change, or would no other user be affected for the worse?

What you are proposing is called pepper. It's another type of salt, but it is not stored. This will not help much, because according to Kerckhoffs's principle, you must assume the attacker knows everything on your system, except the key. In this particular case, assume the attacker can read every single file, every record on the database and every log. He only don't know the user's passwords.

If your system is open for registration, the attacker could even register himself, read the database, get his own hashed password, and bruteforce the secret string. If the string is the same for every hash, as soon as he discover the secret string for his password, all your million users are compromised as well.

You can't plan security based on something that immediately loses all usability forever once is broken. As soon as the secret string is discovered, all your passwords are vulnerable and you cannot just change it. You will have to wait all users to login, get the cleartext passwords for each one, change the secret string, and re-hash it. It can take months or years for all your users re-login. Unless, of course, you go full hardcore insecure mode and store the cleartext passwords somewhere too.

You will increase the security by using a strong hashing function, and adding more rounds on the hashing process, not by adding anything on the password, or hash, or both.


How can I tell whether this computer is part of a botnet? One of the computers that I manage (in the family, not business) has a weird set of files in its boot: bash.exe, curl.exe, uname.exe, sed.exe, rm.exe, tail.exe, cut.exe, awk.exe, cat.exe, chmod.exe, ls.exe, grep.exe and so on.

I know for a fact that no family member has installed anything unusual like cygwin on this computer -- it's a plain consumer pc with Win7 + Skype + Firefox. That's why these entries worry me. As far as I can tell, this computer looks compromised.

I've checked the list of installed programs (in the Control Panel) and there's nothing unusual there. The machine is practically a "laptop for grandma" so I'm absolutely certain that no user installed anything special. If anything, this comes from "outside" somehow.
I installed McAfee and did a full scan -- nothing came up.
I've yet to try tools like CCleaner but perhaps that will reveal something.

How can I confirm whether this computer is compromised, and how can I clean it?

If it's not a botnet, what is it then?

I know a complete reinstall would be best, and I am preparing to do so. But I want to take this situation as a learning opportunity.

For the identification of any presence of infection of botnet, close any running programs that will send requests(browser, game, skype, etc) and you can use wireshark to check for any abnormal traffic.

For a personal computer checkup, you can try Hijackthis or DDS. Get a log of either one of it and analyze for any suspicious programs(you can google for the filename of the program and the path that it SHOULD be at).

A website that you may use to perform a checkup on the file would be systemlookup.com. Just check on the filename at the search bar and type the filename of the file that you wanted to search.

You may also check the CLSID(can be found at Hijackthis's logs) of the file to verify the validity of the file by selecting CLSID on the search bar of systemlookup and copy pasting the CLSID into the search bar and search for it.

NOTE: The two programs above are not a virus removal tool but a check up tool instead.

You can take the incentive to remove the potential malware yourself, but do it at your own risk and do it if and only if you are very sure that it is a malware(through many inspection on the file).

However, if you do not have the knowledge or you require any help on removing the malware, you can seek assistance at bleepingcomputer
If you do need help at bleepingcomputer, please read this before posting


Is there any added benefit to using a random keyfile of more than 512 bits? Most of the online guides I found about using dm-crypt with a random keyfile use files bigger than 512 bits (64 bytes).
For example:
dd bs=512 count=4 if=/dev/urandom of=keyfile iflags=fullblock

As the biggest key a cipher can use is 512 bits (aes-xts-plain64 splits it into two 256 bits key for AES-256), is there any advantage to using more than that, given that /dev/urandom is considered cryptographically secure and that the spec limits the keyfile to 8 MiB?
The cryptsetup man page also mentions the --master-key-file option but I did not find it mentioned elsewhere.

Short answer: no

Long answer: For plain mode, the manual for cryptsetup states in the "Notes on Password Processing" section:

From a key file: It will be cropped to the size given by -s. If there is insufficient key material in the key file, cryptsetup will quit with an error.

So unlike passwords entered from the terminal or stdin, the keyfile is not hashed, only cropped, so you'll get no extra entropy out of a longer keyfile. cryptsetup will even warn you about this if you try to specify --hash plain in plain mode with a keyfile.
For LUKS mode, it will read the keyfile completely (up to --keyfile-size, defaults to 8192 KiB) and hash it, but you won't get more entropy with longer keyfiles as long as your source is good enough.


How can people send me spam emails from the future? Is this an exploit of the email system of some sort?  I receive a great deal of spam every day, and my accounts in Yahoo and Gmail sometimes show me spam emails from the future. Yes, the future.

Sometimes it will give me a day ahead when they send it, which could mean they are a day ahead via time zones, but sometimes I have also seen a week ahead, but rarely I find emails sent a month in the future.

Are these spammers exploiting a part of email that allows them to spoof the timestamp of the email? I have always been curious how they are managing to send me mail from the future.

That's not an "exploit", rather the way e-mail works.

Datetime, sender, receiver, and all other headers of an e-mail message can be set by the sender to whatever value he wishes; mail protocols make no security check on them.  Hence, spoofing the sender of an e-mail (as spammers, scammers, and phishers often do) it's a child's play.

As Priyank correctly said, if you look at the full headers of the message you received you'll see that only the first hop (the sender) bears a date in the future; all the other hops (the MTAs between the sender and you) are correctly timestamped with the actual date.


sensitive data temporarily stored, then redacted: PCI compliant? I am at a startup where we have chat support. Agents chat with customers and sensitive data may be transmitted during the chat session window. We store this sensitive data in our database for the duration of the session.

Once the chat session closes (either by the Agent or the Customer), we redact the sensitive data.

So, let's say a customer shares their CC# number during chat.

In our DB, we'd store 1111 2222 3333 4444 while the chat session is open.

Once the chat session ends, the stored CC data turns into <num> <num> <num> <num>

Is this sufficient for PCI compliance and/or protecting sensitive data?

The simple answer is no - that would most likely not be complaint with the requirements in PCI DSS. Sorry.

You may get two types of payment card data, the 15/16 digit cc numbers (PCI calls these PANs) and the CCV2 from the back of the card (This is a form of sensitive authentication data or SAD).

You can not store plaintext PAN in a database (ie on non-volatile storage) - it does not comply with Requirement 3.4 - Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches ...

Of course, you could have a long debate about "stored" and how many seconds something is on disk before it is "stored", but most assessors would equate any disk storage as stored (and also check log files). NB: If the DB is in RAM then it's not stored.

Additionally the receipt of PAN by "chat" can be problematic. If chat is a web app over TLS then that's OK. If it something like IRC or Skype then you have a problem with Requirement 4.2 - Never send unprotected PANs by end- user messaging technologies (for example, e- mail, instant messaging, SMS, chat, etc.)..

Hope this is helpful.


Password resets - what practices should web services follow? Many of you may have seen How Apple and Amazon Security Flaws Led to My Epic Hacking, where a Wired reporter's Amazon, Apple, Gmail, and Twitter accounts were successfully hacked.  The hacker followed an elaborate sequence of steps, at each step using the password recovery process at one web service to obtain information needed to attack the reporter's account on the next web service.  The attacker was able to successfully exploit the variation among different services' requirements for what they require to perform a password reset, to chain his attack and eventually successfully mount a catastrophic attack on the poor Wired reporter.

In light of this, what practices should web services be following, to protect their password reset functionality and prevent recurrence of such a failure?  What does the industry need to be doing to ensure this doesn't happen again?

I've actually been working on some ideas around this area, so here's a dump of my thoughts so far. I apologise in advance for the ridiculous length of this answer.

Password reset mechanisms have to be designed with three major goals in mind:

Security
Usability
Reliability

For a good mechanism, we need to reach a balance between the three.

A few assertions that I'd like to make before starting:

You cannot rely on users' computers to be secure.
Security through obscurity is not security.
Crypto is hard. Don't roll your own.

Right, on to the actual answer!

1. Multi-factor authentication

Multi-factor authentication (MFA) is one of the most secure methods for account recovery, and human authentication in general. For those of you that are unfamiliar with MFA, it works on the principle that you must have more than one credential in order to authenticate:

Something you know (e.g. password, secret answer)
Something you have (e.g. key, hardware token, etc)
Something you are (e.g. fingerprint)

Note that having multiple of one type, e.g. two passwords, or a password and a pin, does not count as MFA. I'm looking at you, online banking sites.

1.1. Something you know

When resetting a password, a common way to authenticate the user is to ask them some questions. Unfortunately, these questions are usually things like "What school did you go to?" and "What's your mother's maiden name?", which are incredibly easy for attackers to find out through social networking. Furthermore, many users dislike answering these questions when signing up, so they just hit a bunch of keys and invalidate the purpose of the question.

For e-commerce webapps, and other webapps that store private personal information (e.g. address / phone number), one might ask for that information. However, keep in mind that this information might be found online too.

An alternative would be to ask contextual questions, based on the user's experience on the site. For example, Hotmail asks for an email address that you have recently communicated with, as well as some other information about activity on your account. This is quite adaptable across most types of webapp, but isn't always applicable.

1.2. Something you have

Often sites will describe emailing a link or one-time password to your email address as a form of MFA. I assert that this is a false assumption. Users share passwords between accounts. This is an absolute fact, and you cannot prevent it. As such, you must assume that an attacker already has access to the user's email address. We'll cover the implications of this later.

The proliferation of cellphones has made them a great mechanism for two-factor authentication, as a form of out-of-band check. SMS reset tokens are easy for the user to understand and use, and an attacker having access to the phone is unlikely. However, this method is not without flaws. The biggest problem is when a user loses their phone, or changes provider. This completely invalidates the phone as a usable reset device. Another problem is that users don't always have their phone with them.

Using an app on smartphones partially fixes this problem. If a user changes their provider, the app remains on the phone. Allowing both SMS-based and app-based resets allows for a reasonable expectation of reliability.

Alternatively, allow the user to associate a login provider account (e.g. OpenID) and use a valid logon for that account as a "something you know" proof.

Other potential mechanisms:

Physical token (e.g. RSA SecurID, USB token) - not exactly viable for most places, but useful for banks, internal corporate systems and other high-security situations.
File - Randomly generated file given to the user on signup. Hash stored in database. Upon reset, user asked to provide file. Not the best usability or security, but potentially useful.

1.3. Something you are

This is where things get fun and sci-fi. Biometric authentication is something that has become more popular recently. Quite a few laptops include fingerprint scanners, and you can pick up cheap USB ones for a relatively small cost. Another popular biometric mechanism is facial recognition, via webcam. Both of these are excellent in terms of security when done right, but they both have a few problems:

Most implementations are probabilistic, and therefore insecure. What stops an attacker from holding a photo of your face up to the camera?
You can't rely on every user having a fingerprint scanner, and those that do aren't all compatible with each other. Furthermore, you're interfacing with hardware, so that requires a native app to talk to your webapp.
The field of biometrics is relatively new, so there aren't any well-aged properly-studied implementations with fully understood security models.

All in all, the "something you are" model works for in-person identification, but isn't really feasible for webapps unless you're providing your customers with fingerprint scanners and appropriate software.

1.4. MFA best practices

Single-factor authentication is not enough. As we've seen from all the recent breaches it's difficult to keep passwords secure, and even when they're hashed they can still be broken. MFA is necessary for both login and password recovery. Mobile authentication for recovery purposes solves most problems, as long as the mobile device is still usable. In the case of mobile authentication not being possible, you must have a manual verification process in place, where they have to convince a human that they are the real deal.

2. Reset mechanisms

There are a multitude of different password reset methods out there, many of which fall way behind in terms of security. I'm going to discuss some that I've seen in the wild, explain their good and bad points, and propose some better ones.

2.1. Emailing the password back

The most basic mechanism is to just email the user's password to them. Please don't ever do this. It's horrible beyond measure. First, it requires that you're storing passwords in cleartext, or at least in a reversible format. You must hash passwords properly, and follow best practices for salting. Second, you're emailing the user's password in cleartext, over a cleartext protocol, over the internet. There's a special level of hell reserved for people who do this.

2.2. Generating a new password

Some sites generate a new random password, hash it, then email it off to the user. This isn't a good idea for quite a few reasons, though most of them can be mitigated in some way. The most fundamental issue is that you're emailing a usable password to a user in plaintext. Other issues with this method include:

Many users are lazy, quite a few will reset and just tell the browser to remember the random password.
A lot of sites don't force you to change the password upon first use of the password.
An attacker having access to the email account has access to the password, regardless of what mechanisms you used to authenticate the user in the first place.

2.3. The reset link

This is one of the better (and, thankfully, more popular) mechanisms. It involves authenticating the user, then emailing them a one-time reset link. Once the reset link is used, the user is prompted to set a new password. Once that's been done, the link is invalid. Further security can be provided by including expiry times on the links, and enforcing that the link is invalid after the password is set or after the user's session times out.

The downfall of this method is when we remember our earlier assumption. The user's email account is not safe. It does not count as "something you know". Whilst an attacker's time window is short, they can still break in. Of course, all of this is further invalidated if (or, rather, when) the user forgets their email password.

2.4. Never leave the site

This is the holy grail, really, but can only be used alongside strong multi-factor authentication. Once the user authenticates themselves using a combination of security questions, out-of-band checks (e.g. cellphone), key files, biometrics, human verification, etc. they are immediately redirected to a password change form. This entirely bypasses the need to use email addresses at all.

If you truly believe that using an email address to send a link to is necessary, consider offering a no-email reset option which increases the number of checks that you require to be passed.

3. Conclusion

It's difficult to balance security, usability and reliability at the best of times, but this situation is directly dealing with a user that has already proven themselves to be unreliable. I'm not saying this in any kind of deprecating sense, but rather that we are all fallible.

It's important to keep a password reset system usable and simple, without skimping on security. Before implementing a massive 3-factor authentication process on every aspect of your webapp, think about what you're protecting. If you're just a small company selling things online, you can probably get away with basic 2-factor on recovery. If you're a major retailer, bank, or social networking site, you should be using strong 2-factor on recovery (multiple types of each), and 2-factor on logins from unrecognised sources.

In a sentence: keep it simple, think about your audience.


What can a trusted certificate do? I am doing some reading about security on mobile applications because I found an article about Man in the Middle Attacks.

I saw in that article and in many other places (including security.stackexchange), that if the user installs a certificate of an unknown 3rd party, that 3rd party can exercise MitM attacks in other apps of the device.

Basically what I want to understand is why? How can this 3rd party certificate be a vulnerability on other apps? I want some understanding of how these certificates work in that regard.

I read about certificate authorities, root certificates, chain of trust and related matters, which makes me even more confused on how something "self-signed" would be a security vulnerability.

Can anyone give me a brief explanation on how/why this happens? Or even provide me with links/books with relevant information.

I saw in that article and in many other places (including security.stackexchange), that if the user installs a certificate of an unknown 3rd party. That 3rd party can exercise MitM attacks in other apps of the device.

If you install a certificate for a certificate agency (not a certificate for a site) then you effectively trust the certificate agency fully, i.e. allow it to sign certificates for any other site - even for sites where other agencies have already issued certificates. And this allows man in the middle attacks.

This would be similar if you have a new friend and you trust this friend fully. If then some shady guy comes and claims to be your bank and presents a document signed by your friend which attests this claim, then you would believe this guy just because you trust your friend fully. Thus it is possible for someone to impersonate someone else with the help of your friend. And this make man in the middle attacks possible, where the man in the middle impersonates the real destination.


Browser - what gets saved to the disk We run scraping jobs on behalf of users. We use webkit-gtk as browser to do the scraping. Each job is executed as a separate process

So as not to mix user data we have isolated following data per user.

Cookies
Flash cookies
Cache files
HTML 5 storage

Do I need to worry about any other types of files that normal browser sesson will save? The "browser" does not have any other plugins apart from flash. Browser does not save any password and auto form fill is disabled.

You seem to have the basic user data covered, but I'm not sure why try to isolate it like that.  I would run each user's browser instances with an in-memory home directory/storage area.  Then when the process terminates, all of the data is destroyed, no risk of leaving anything behind.  Headless Webkit like PhantomJS provide flags specifically to move these data to their own directories, which can be placed on a tmpfs ramdisk.  (Webkit-gtk seems to be a library, so I assume you've wrapped this in your own program?)


What are the advantages of cloud-based firewalls? What are the advantages of firewall based on cloud? Does it cause heavy traffic and make it slower? If it does, is the impact significant?

A firewall based on a cloud, as I understand it, will send the packets to the cloud for a check, after that, it will return only the appropriate packets to the company.

For example, if I want to visit the company's website, I will send a http request which will go to the cloud for a check. Then it will pass the packet to the company itself.

Will it cause  traffic overload? (Because in this scenario, I will send each packet to the cloud and get answer from it).

Depending on the type product you are asking about and the environment you are trying to defend there are several pluses and minuses.

Some potential pluses depending on the product:

Pluses:

1.) This isn't the norm but if you are talking about managed firewall services the product may have integration with larger analytic databases which allow the company to see a lot more traffic and respond faster to new attacks than a typical individual organization would.

2.) Anti-DDoS / Anti-DoS capability, again this really depends on the product/company (you didn't specify) but some third parties companies have multiple large connections to the Internet where they can build unique defenses against DDoS and DoS attacks and also have specialized infrastructure to leverage different DNS and BGP security components to reduce large-scale attacks. (This is a huge topic)

3.) The two above do not typically apply to basic cloud-compute firewalls (again I'm not sure which you are asking about) but in the case of some cloud services like Amazon's AWS there is better integration for whats known as elastic services where you can start and stop servers as needed and the firewalls "can" be automatically configured dynamically. This can be done on non-cloud firewalls but it's MUCH easier to do this type of orchestration in cloud-based environments designed around this task.

4.) If it's a managed service that has 24x7 teams and your organization is not staffed 24x7 this could be a huge benefit but do note that many cloud compute platforms leave all the security up to the end user so this answer really depends on which type of service you are talking about (could be a plus or a minus depending on the product).

Minuses:

1.) It's harder to see when things are misconfigured such that data can leave the organization. Note: I'm not saying this isn't manageable but lots of people new to cloud compute environments make many mistakes such that wouldn't have happened when all the data is forced through a physical cable that people can see.

2.) Hypervisor flaws underneath the firewalls may create risks to an entire environment in a cloud compute environment. There are other more interesting CVE's but as an example a recent one affecting some cloud compute providers is CVE-2016-5363

3.) A third party has access to all of your traffic and can control your security configurations. Weaknesses in the third party network are now weaknesses in your network. This can increase your attack surface dramatically.

4.) In most cloud compute environments you lose access to infrastructure-based NetFlow, or it's harder to get, or the data is not complete especially if your environment uses any serverless compute services. Some people add this back on at the host level but if the host's kernel is compromised it's TCP/IP stack may not be reporting malicious communications which then won't be accurately reflected in your NetFlow. Out of band NetFlow is a more accurate measurement specifically due to this issue.

5.) Capability to change hardware/software in an emergency is reduced. If your cloud-based firewall goes down there may not be anything you can do about it until the provider can correct the issue.

6.) You are outsourcing this security work to an organization who will not care about your data or your business as much as you do. Not a horrible thing but something to keep in mind.

There are many other smaller pluses and minuses but I'd need to know more about the specific system or service you are asking about. Likewise depending on the product or specific cloud platform (depending on which you are talking about) there may also be a lot of other issues that you will want to consider which are unique to that platform. Far too many to go into detail here.

The choice between the two is based on what you are trying to defend, the specific risks to your organization, and the trade off of any advantages either one brings to the decision.

Both cloud and traditional solutions can be really good but they are very different and they require good integration into your environment. These aren't products that you buy and just forget about.

It's always important to look at the security problem as a whole and see how these components fit your organization and what you are trying to achieve.

To answer your "speed" question. If and only if you are talking about having a cloud-based firewall in front of a traditional network there can actually be really big speed increases as some of the companies who do this have faster, lower-latency connections to the Internet backbone and they can cache content locally. This has the effect of moving parts of your services or services your organization is accessing closer to your users. Similarly they may add compression where it's supported by the various clients accessing the servers (this is a smaller issue speed-wise as most people configure their servers to do this but where that was not done their will be a speed increase). Some companies like Imperva can also cache content for you and act as a Content Delivery Network (CDN) which will give you additional speed improvements. But a lot of this depends on what your situation is.

Generally there are benefits in the form of the co-op model in that a large company offering these services can bring more technology to the solution than a smaller individual organization would tend to buy on their own. None the less for high-security data this may not be worth the additional risks.

I'll also mention that some organizations use both as a way to get the best of both worlds. I like this when it's appropriate.

Finally I need to mention that this answer is also very time sensitive as that market is still emerging so the pluses and minuses will change a lot over time.


How hard is it to retrieve IKEv2 Server Certificate from the server? I got access to a VPN via IPsec and IKEv2. The provider gave me a username, a shared secret and a server certificate. Since the certificate was self-signed, the manual came with specific instructions on how to install it.

The manual also states, that you should remove the certificate file after import (in order that noone else can also import it). That sounded odd, since the file is the public key. So it is only used to verify the integrity of the server. So I thought, how can we connect to the server without having the certificate?

Since I did not find any option to disable the server certificate validation on neither Windows nor macOS, how hard is it to download the certificate and import it?

For HTTPS/SSL, such a file is send over the wire for every connection in plaintext, because SSL verifys the server first and encrypts afterwards. IKEv2 first opens an encrypted channel using DH-Key Exchange and then verifies the
server certificate. Since the certificate file is encrypted before transmitting, you cannot grab it from Wireshark.

A google search didn't yield any results, so my questions are:

How hard is it to download the certificate via IKEv2?
In case a tool for that already exists, can you post a reference to it?
In case there is no ready to use tool, how long would a programmer need to write one?1

1: The tool doesn't need to be perfect, it just needs to download the certificate from one specific server. The imagined programmer has some years of experience but has not written any VPN stuff.

How hard is it to download the certificate via IKEv2?

That depends on the server's configuration and the type of client authentication.

If the client has the server certificate installed and trusts it, the server technically doesn't have to send it. The client will just use the local certificate that matches the server's IKE identity to verify the signature in the AUTH payload.

If the server is not configured to omit the certificate, certain authentication methods will prevent attackers from retrieving the certificate. With both certificate and pre-shared key authentication the client will be authenticated first. The server will just respond with an AUTHENTICATION_FAILED error notify if the client authentication isn't successful.

Only with EAP authentication (e.g. username/password via EAP-MSCHAPv2, or certificate via EAP-TLS) is the server authenticated before the client (the client will not send an AUTH or CERT payload in the IKE_AUTH request, but the server will send both in its first response).

  In case a tool for that already exists, can you post a reference to it?
  In case there is no ready to use tool, how long would a programmer need to write one?

I don't know of a tool for this specific use case.  But e.g. strongSwan's charon-cmd command-line IKE client could be used with increased log levels to dump the server certificate. Another option would be to get the IKE keys (either via log or save-keys plugin) and use Wireshark to decrypt the IKE_AUTH response and extract the certificate from there.


What is TCP spoofing? I know about IP spoofing is it the same thing?
The question originated from the question
Is TCP more secure than UDP?

"Spoofing" in the context of networking means that you create communication in a network system which appears to originate from another host. In order to do this successfully, you need to impersonate them on every protocol layer of the application you want to impersonate them on.

Just injecting IP packets which seems to originate from another host is insufficient to impersonate that host during a TCP connection, because every TCP segment has a 32bit sequence number. A segment with a sequence number which is out of line will be ignored. That means in order to successfully insert a TCP segment into an existing transmission you need to guess the next sequence number, or your segment will be discarded. This isn't so hard when you can eavesdrop at least on the client, but when you can't, you can only brute-force it. With more simple transport protocols, like UDP for example, you don't have that problem. UDP has no sequence numbers, so unless an upper protocol layer replicates such functionality, you can just insert additional segments which will then be treated as if they were coming from the real host.

You also have another problem when you have no existing connection and instead want to establish a new TCP connection which appears to originate from another host. In order to establish a TCP connection, a 3-way handshake is required. (client sends SYN, server sends SYN,ACK, client sends ACK). The SYN,ACK by the server includes a random number which you need for an acceptable ACK. So when you can only send IP packets but not receive any of the packets intended for the spoofed host, you will have to guess this number.


Find unlisted web pages on a site? If I have a website with an index.html page that was just a landing page with no other links, and I also have another html page hosted on the same domain that has no links to it, is there any way someone could find the page except through being told that it exists?

The tactics basically amount to guessing:

Standard directory testing: This guesses typical webpage files, like /manager/login.jsp and the like.
Dictionary Attacks": This guesses dictionary words, like "employee".

There are many tools that do this, like Burp Suite and Dirbuster.

The other technique that I like to use for finding hidden pages is searching Google. Simply putting in site:*.example.com will return every single page on example.com that Google knows about. So, if Google-Bot has stumbled upon your page, I'll know about it too!

There's also the chance that someone will just guess it. It's not that hard. Now, a page like example.com/lsjglkjlktjwlkfjsldkjfijflkwjflksdjflkdsjflkdsjf would be quite hard to find :)

Takeaway: if you don't want someone to see it, put an authentication challenge on it.


Certificate chaining:Intermediate Certificate Authorities Wikipedia says:
For example, if a certificate issued to "example.com" and issued by "Intermediate CA1", and the visiting web browser trusts "Root CA", trust may be established in the following manner:

Certificate 1 - Issued To: example.com; Issued By: Intermediate CA 1

Certificate 2 - Issued To: Intermediate CA 1; Issued By: Intermediate CA 2

Certificate 3 - Issued To: Intermediate CA 2; Issued By: Intermediate CA 3

Certificate 4 - Issued To: Intermediate CA 3; Issued By: Root CA

What is meant by trust here?Can my browser trust an intermediate certificate so that the certificate chaining stops there and my brower can start a session with server?

With standard browser, it will most likely not work. However, nothing prevents such behavior with standalone applications (see Thomas Pornin's answer to SSL root certificate optional?), in such case one would talk of a trust anchor, ie. it is not a root certificate (it is not self-signed) but is nevertheless a trusted certificate usable as starting point to build the certification chain.


Is there a way to accept signed requests without storing client's password in plaintext? We are developing REST Web service. We will give Identifier and Secret string to each of our REST clients. When doing requests, clients will authenticate themselves using HMAC algorithm (they will sign body and headers of HTTP requests using Secret string). REST service will receive HTTP headers, body, finds client's secret from database using his Identifier, sign it and looks whether computed signature is equal to the signature provided by the client.

Actually, it's better explained at Amazon S3 authentication documentation page.

In order to use this scheme we have to store clients' Secret keys in plain text, right?

Is there another way to authenticate clients without storing their Secret keys on our servers (or store them in non-recoverable way, for example their MD5-hashes)?

Strictly speaking, the use of the term "signature" about HMAC is improper; it is widespread, but still incorrect: signatures are about asymmetric algorithms with a public and a private key, such as RSA.

HMAC uses a secret key (i.e. a bunch of arbitrary bytes) which is used for computing the MAC and for verifying it (it is actually verified by recomputing it). So, in your problem, yes, the server must store either the secret key, or some data which is enough to recover it.

Note that the secret key K can be derived from the password in a non-invertible way. E.g. through a hash function or, better yet, with a Key Derivation Function. The server will store the key K "in plaintext" and knowing key K is enough to produce valid HMAC values. However, this forces an attacker to use some specific software for that, not the standard client which requests a user password. Depending on the context and your attack model, this may or may not be a security improvement.

A way to achieve what you are looking for, but with higher complexity then a plain HMAC, is to use SRP. SRP is an asymmetric key exchange protocol with mutual password-based authentication, with the following characteristics:

No need for public key distribution (PKI, certificates...).
Client authenticates server and server authenticates client, in the same pass, even in the presence of active attackers ("Man-In-The-Middle" attackers are defeated).
No active or passive attackers learns enough information to perform offline dictionary attacks (a dictionary attack is guessing the password by trying random words; the attack is offline if it can be done without interacting with the honest client or server for each guess).
What the server stores is not enough to learn the password or impersonate the client (but it allows offline dictionary attacks, which is unavoidable).

The key which results from the SRP protocol can then be used for a MAC algorithm such as HMAC. It needs not be stored: it is just kept in RAM for the duration of the session.

SRP can be integrated in TLS, as explained in RFC 5054. The easiest, most standard supported way to use SRP in your context would be to use HTTPS (i.e. HTTP within a SSL/TLS tunnel) with the TLS part using SRP for key exchange. GnuTLS is an opensource implementation of SSL/TLS which supports SRP.


Security Standards for storing private customer data A certain government regulation in my country mandates all non-resident donors to provide a copy of their identification (usually, the passport).

So, we ask the donors to upload a copy of their passports while making a donation on our website. (Which is then verified by our admin, internally)

We have taken measures to ensure that the images are stored carefully and that they cannot be retrieved by an external user on www (and the access to this data is limited to only a few people in our organisation). However, some donors are still skeptic about the safety measures taken by us.

Question : Are there any industry-wide standards that provide guidelines on how to store this information? Are there auditing agencies who can audit our practices related to this? Something like what PCI is for credit cards?

Various countries have their own regulations on this, for example the UK has the Data Protection Act 1998 ( http://www.ico.org.uk/for_organisations/data_protection ) and there is HIPAA in the US ( http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html )

Also some regions such as the EU mandate data protection regulations for their member states.

All the major IT audit firms, such as EY, KPMG etc can do data protection audits.


Proof 7.3 from the PCI DSS standard 7.3 Examine documentation interview personnel to verify that security policies and operational procedures for restricting access to cardholder data are:
  · Documented,
  · In use, and
  · Known to all affected parties.

As a service provider providing monitoring for customer on their networks and datacenter locations, I wonder how I can proof this rather verbal question for my PCI DSS assessment validation.

The company has in place security information and test to validate that all employees has received information how to handle sensitive data such as credit card information and leakage, etc.

But how do I make a proof of the above quote?
How do I proof that by monitor their network and systems, that we don't log any kind of credit card information and cardholder data?

The audience for that guidance is QSAs- Qualified Security Assessors- whose job it is to appear onsite, examine documentation, interview personnel, and perform other audit-related activities to ensure they are comfortable issuing a reporting indicating the company is PCI compliant.

In terms of the specific proof- the auditor will decide what evidence to consider- whatever documentation you have, configuration, log files- in determining whether you meet the standards. They should provide some direction to you regarding the specific pieces of evidence they need to see.

Higher level, as a service provider whose customers have to be PCI compliant and whose engagement with those customers exposes systems you control to your customers card data environments, you have to have your own PCI compliance documentation- either your own Report on Compliance provided by an auditor, or, should your customer transaction levels be low enough, a Service Provider Self Assessment Questionnaire. That documentation gets provided to customers as evidence when they go through their own PCI audits. Customers should not be coming to you for answers on specific questions on their own compliance.


Can WebAssembly execution be disabled in browsers? I've recently found out about this new technology, which recently became a World Wide Web Consortium recommendation and also that now almost all main browsers support it and it is enabled by default, see e.g. this.

I was not able to find in e.g. Firefox about:config to disable it:

Unlike JS:

As noted on Wikipedia, the technology poses maybe even higher risk than JS. How can one disable it in browsers if one so wishes?

I did some more search and disabling is not complex. In e.g. https://github.com/stevespringett/disable-webassembly for Firefox one should:

  Enter about:config in the URL bar and change javascript.options.wasm
  to false

I've checked with sample app https://subzey.github.io/wasm-canvas2d/ and it indeed changes working app to not-working.


Can't tell If The OpenVPN Server I Setup Is Encrypted using Wireshark? This might sound dumb, but I set up an OpenVPN server on a Synology NAS.  When I connect via the client at home to the server, everything works for.

I know you can read packets in Wireshark.  If I start sniffing on My WiFi that I'm connected to at home, packets show for the OpenVPN protocol and there are few lines that say Synology (I believe this is a handshake) but everything else, every line of data is gibberish so I'm assuming it's encrypted?

That also said, when I connect to the VPN another local area connection appears in Wireshark as an adapter to sniff.  If I sniff the new local network this is NOT encrypted, but isn't that normal?

Essentially you're sniffing the new adapter itself locally as soon as you connect via the client?  Or is that NOT normal?  Why does it show gibberish like it's encrypted on the WiFi via Wireshark, but not the new connection created upon connection to the VPN called Ethernet 2?

The VPN creates a virtual network interface and sets a route so all traffic goes through this interface. If you sniff on this VPN interface everything will be in clear. But everything which is put into this VPN interface gets encrypted and then send trough another more real network interface (WiFi in your case) to the VPN endpoint. That's why if you sniff on WiFi you see everything encrypted.

At the VPN endpoint you then have the same setup, i.e. the encrypted traffic comes in through the "physical" interface, gets decrypted and then comes out in plain on the VPN interface.


Howto restore factory default state of an USB pen drive? The proper way to secure erase a SSD is to issue the SECURITY ERASE UNIT command. Then the SSD controller should send a BLOCK ERASE command to all physical blocks.

One caveat: the SSD has to be connected directly to the SATA interface. Don't use a SATA-to-USB adapter!

Since we cannot plug an USB pen drive into a SATA port, what is the proper way to secure erase a USB pen drive and restore its factory default state?

This will not do the trick:

$ sudo hdparm --security-set-pass PASS /dev/sdb
$ sudo hdparm --security-erase PASS /dev/sdb

Before marking this question as a duplicate: most duplicates are closed and suggest to dd everything several times, but that won't restore the factory default state.

Unfortunately, there is no standard way to do this. USB flash drives are not the same as SATA drives and they do not follow the same specifications. There is no way to initiate the ATA Secure Erase because such a function is not even part of its firmware. Additionally, because of the way the firmware operates (dynamic wear leveling and overprovisioning), you cannot actually wipe everything on the device just by writing to the block device, as is explained in more detail in this answer.
The most effective way to wipe a USB flash drive is to only write encrypted content to it and forget or destroy the key. If that is not an option, then physical destruction is a requirement. No software is able to securely erase the data on an average USB flash drive with sufficient effectiveness.


Social engineering attacks terminology Let's suppose that a hacker send an email containing a Word document with a malicious macro to a sysadmin.
Does this attack fall under the category of spear phishing?

Spear phishing mails are an attack targeted at a specific person or group. Targeting is done by providing subjects or content relevant for this group. he main difference between "normal phishing" and "spear phishing" is that the attack is only send to few people and it is more adapted to these people. This also means that often a  unique or less common exploit is used in the spear phishing which will not be detected by the usual antivirus.

Thus a mail containing a document which uses macros to infect the system is not necessarily a spear phishing attack. It will be a phishing attack if it is one of these widely send mails containing alleged DHL delivery information or invoices. It will be a spear phishing attack if it is only send to the sysadmin and maybe few other people and contains information specific to their person, their work or otherwise interesting information which seduce the sysadmin to open the attached document.


Why would a switch be configured to Fail Open? I can't understand why a switch would be configured to Fail Open? Surely an attacker could easily exploit this by MAC Flooding which will cause the switch to act like a hub and broadcast messages to all network interfaces?

The only reason I can think of is to prevent any critical systems to fail from loss of communication if a switch was configured to Fail Safe?

I would appreciate your thoughts on which contexts would it ever be appropriate for switches to be configured to Fail Open?

...because a switch is a Connectivity device, not a Security device.  It is designed to enable communication, not to secure the network.  That design bias emphasizes availability over security in situations where both are threatened.

Much pain would be avoided if people would remember that when designing networks.


make specially encoded template available for file uploads A comment to this blog post at sans.org about secure file uploads suggests making a pre-formatted template available for users when they need to do file uploads.  The user would use the template to add their own data and upload the resulting file.  It suggests "encode the template in some way that an attacker would have a difficult time spoofing..."

This would supposedly help stop malicious files masquerading as the correct file types.

Would this work and how would one "encode" the template?

Firstly, I don't think what that commenter posted is great general advice.

I'm assuming what they mean is try to validate some attribute of the file format you're expecting. For example, if you're expecting a .docx file you might validate that it's an archive containing a folder called /word/ and that directory contains a file called document.xml and that document contains some tag/markup either unique to your template or required by .docx files.

The idea is that it'd be difficult for an attacker to make a file which conforms to these requirements but is still malicious.

Frankly I think this would only work in certain very specific scenarios and I think most of the security would come from obscurity (ie. the attacker not knowing exactly what your validation criteria are).

The advice about assigning files a random name, not putting them in a publicly accessible directory, not giving them execute permissions, etc. is more important.


Asynchonous Linear Feedback Shift Register : test vectors Well I've been working on coding LFSR structures for my research projects.
Being able to find sources on the subject, I've been able to test a single LFSR with different initialisation and TAP values, to convince me that the implementation is correct.

I'm now on working on asynchronous LFSRs structure (combination of LFSR, with asynchronous shifting behaviour), but I'm in need of test vectors to ensure my implementation is correct.

Do someone know where I could fine some? I'm also aware that the A5/1 algorithm used for mobile communications is one instance of Asynchronous LFSRs , but still I can't find the test vectors for this protocol either.

The pedagogical A5/1 implementation (which is the only publicly known "reference" on A5/1) contains a single test vector, which the code actually tests when executed (see the test() function).

A LFSR is a structure which produces a sequence of bits from on internal state; at each "clock", a single bit is output, and the internal state is correspondingly updated. An "asynchronous" LFSR is a LFSR which you do not always clock, based on some externally specified arbitrary rule. Being asynchronous is not a property of the LFSR itself, but of how it is invoked. From the point of view of the LFSR, nothing is changed: when a "clock" occurs, one bit is produced and the internal state is updated. Consequently, you will not find test vectors for "a lone asynchronous LFSR" because there is no such thing as a LFSR being asynchronous by itself: asynchronicity stems from an extra piece which controls whether the LFSR shall be clocked or not. You may find test vectors for some algorithms which use one or several LFSR in an asynchronous fashion, e.g. A5/1.


Will TLS_FALLBACK_SCSV on a server that only supports TLSv1 block a connection from a client using TLSv1.2 I've read the draft RFC in relation to TLS_FALLBACK_SCSV and understand that if both the client and server implement this feature and a client sends this as part of clienthello, the server must reject the connection, if it's version of TLS is higher that the version of the client.

However, it's not clear to me what the correct action should be, when a clienthello contains a version of TLS higher, than that supported by the server, i.e. the client requests TLSv1.2 but the server only implements TLSv1.
Should the server in this case reject the connection, or should the client and server be able to negotiate to TLSv1?

Could someone please confirm as I'm looking into an issue where the above would be the case and the remote server which only implements TLSv1 rejects the client connection.

The client will send TLS_FALLBACK_SCSV only if it does a TLS handshake with a downgraded version and the server will only reject a connection containing TLS_FALLBACK_SCSV if it can do a better version. Examples:

Client can do TLS 1.0 and TLS 1.2, i.e. TLS 1.2 is the best. Server supports only TLS 1.0. Client will try with TLS 1.2 first. Usually the server replies with TLS 1.0 because that's all it supports. But some server are broken and completely fail the handshake in which case browsers do a connection downgrade. In this case the browser does a TLS 1.0 handshake but sets TLS_FALLBACK_SCSV to indicate that it does a fallback. Since the server only does TLS 1.0 anyway it will not complain but accept the connection.
In the second example the same client is used but the server support TLS 1.2 too. A man in the middle is sitting between client and server and disrupts some connection in the hope for force a TLS downgrade. After the first TLS 1.2 connection from the client will be disrupted and fail the client will try again with TLS 1.0 but set TLS_FALLBACK_SCSV. This time the attacker will let the connection pass and the server will receive the TLS 1.0 handshake which includes TLS_FALLBACK_SCSV. Since the server can do better than TLS 1.0 it will reject the connection.


How secure is static key encryption? I was looking at using the encrypt option in an application but I've read some comments saying it is not so secure because it uses static keys.

How easy is it to break static key encryption? Does it require lots of data points or just lots of time?

A static key is one you use more than once over a long period of time. It is often considered less secure than using an ephemeral key (that changes each time) because:

An eavesdropper gets more material to work with.
If an attacker breaks the key, they can decrypt multiple messages.
It gives the attacker the possibility of arranging a known plaintext attack.

However, static keys are often easier to implement.  And in some cases none of the above matter. And security is a process, not just using the strongest possible algorithm. (Or else we'd all use one-time pads!)

So the answer is "sometimes more, sometimes less, it depends".


Can I reencrypt my GPG private key with more password rounds? As noted elsewhere, SSH private keys can be reencrypted (in different formats) with more rounds of iteration in the password-derivation function.

Is there a way to do something similar for an already extant GPG private key? Can I simply modify it to require more rounds of password derivation to make it harder to bruteforce?

From what I read in the GnuPG manual, you may use --edit-key and the passwd subcommand to change the passphrase on your key; if an iteration count was provided on the command-line with --s2k-count, then the new password hashing should use the specified count.

(I have not tried it; this is just theoretical.)


What is important when selecting a VPN provider? I am new to using a VPN service and came across the past at How do I pick a VPN provider? however am unsure if I need to use a personal VPN service or if OpenVPN fits my needs which are as follows;

No logging whatever so e.g. encrypted servers, no tracking of originating IP address, etc
Minimal or next to no impact on speed
The ability to use the service on multiple computers without having to purchase a new router
Unlimited downloads and uploads
Works with all web related applications e.g. web browsing, video streaming, chatting, audio streaming, etc
Reliable support and service

No logging whatever so e.g. encrypted servers, no tracking of originating IP address, etc

Most VPN providers will do only the minimal logging. Ask the support staff for exact details before signing up

  Minimal or next to no impact on speed

The closer the server is to your location, the faster the speed will be. VPN's have a speed impact due to no cache on encryted data. Some VPN services, such as Astrill.com include a system in their software that recreates the cache localy (if turned on) speeding up the system slightly.

  The ability to use the service on multiple computers without having to purchase a new router

Most VPNs are simple software installs on your PC. Usually the end user agreement allows you to install on multiple computers as long as only one is used at a time. If you want to use multiple computers on the VPN at the same time, you may need to buy additional keys to access the network. Again ask the support staff as this may vary.

  Unlimited downloads and uploads

There are many VPNs who offer unlimited traffic. Look on their websites or ask the support for details.

  Works with all web related applications e.g. web browsing, video streaming, chatting, audio streaming, etc

All VPNs I've tried work with the services you listed.


Where email orginates I keep getting emails from an unknown person. In the header file, I see this:

authentication-results: spf=softfail (sender IP is 25.152.82.59)
smtp.mailfrom=outlook.com; gmail.com; dkim=none (message not signed)
header.d=none;gmail.com; dmarc=fail action=none header.from=outlook.com;
received-spf: SoftFail (protection.outlook.com: domain of transitioning
outlook.com discourages use of 25.152.82.59 as permitted sender)

Can I assume the email orginates from 25.152.82.59?

Can I assume the email orginates at 25.152.82.59

Not really. You can maybe assume that 25.152.82.59 was somewhere in the path of the email, i.e. it could be the original sender but it could also some mail server in between forwarding the mail. And besides that the header could just be faked.


Is this good/secure method for client-server communication encryption? Something came to my mind, and I wonder if this is proper method for client-server communication, and if this method is wide-used.

On connection, client generates seed, encrypts it using asymmetric algorithm(RSA for example), and sends it to the server.

Using CSPRNG, both client and server generate array of random bytes(using the same seed known only to client and server).

When client/server communicate, it adds random byte to each byte of message depending on offset.

For example, first byte of message since begging of connection is added to first byte of random bytes array. Opposite client/server then subtracts random byte from message byte.

Is it secure method? How is it different from sending key of XTEA (for example) using asymmetric algorithm, and using symmetric algorithm(XTEA) for rest of communication?

What you are describing is known as a Stream Cipher.
As to the differences, the linked article can be cited to get you started:

Stream ciphers are often used for their speed and simplicity of implementation in hardware, and in applications where plaintext comes in quantities of unknowable length like a secure wireless connection. If a block cipher (not operating in a stream cipher mode) were to be used in this type of application, the designer would need to choose either transmission efficiency or implementation complexity, since block ciphers cannot directly work on blocks shorter than their block size. For example, if a 128-bit block cipher received separate 32-bit bursts of plaintext, three quarters of the data transmitted would be padding. Block ciphers must be used in ciphertext stealing or residual block termination mode to avoid padding, while stream ciphers eliminate this issue by naturally operating on the smallest unit that can be transmitted (usually bytes).
Another advantage of stream ciphers in military cryptography is that the cipher stream can be generated in a separate box that is subject to strict security measures and fed to other devices such as a radio set, which will perform the xor operation as part of their function. The latter device can then be designed and used in less stringent environments.


How to figure out if someone has been using TeamViewer 8 to access my computer when I was not here? I came to my computer today and have not been here since monday afternoon. I am using windows 7. There were some error messages showing even on the log in screen about memory violations done by spotify and one more (I can't remember), and I just clicked them away, even though it is not normal on my PC. Sometimes it freezes on the login screen and I have to reboot, but this was different. But I did not take a note of the messages as I just didn't care.

After logging in, I noticed that my Teamviewer client was running (the GUI was showing). I thought this was odd, since I haven't been using it lately. I was a bit curious, so I checked the log. I will not include it here, as I don't know how to read it and I do not know what could identify me. It seems that it was an update leading to this, but I am not sure. Probably, but I don't like the fact that the GUI was showing with my ID and password showing. They could have silently updated it or have given me a message...

So, this leads me to the question: How to figure out if someone has been using TeamViewer 8 to access my computer when I was not here? What to look for in logs and perhaps the Windows 7 event logs? And a bonus Q: Is it safe to have TeamViewer 8 running in the background at all?

Running Teamviewer isn't very secure: read here

To determine who was logged in - look here:

C:\Program Files\TeamViewer\VersionX\Connections_incoming.txt
C:\Users\XXX\AppData\Roaming\TeamViewer\Connections.txt


Will encrypting the same file with GnuPG and the same key produce the same ciphertext? If I encrypt the same file twice with GnuPG, using the same key, will I get the same result? or is it using some random/psudeo-random segment to improve security like rsynccrypto?

Generally speaking, no, encrypting the same file with the same key will not produce the same file, for three reasons:

The OpenPGP format (which GnuPG implements) uses hybrid encryption: a random, symmetric key is encrypted with the recipient's public key (of type RSA or ElGamal), and that symmetric key is itself used to encrypt the message body with a symmetric encryption algorithm. Hybrid encryption is used because asymmetric encryption are very limited in their range (e.g. a 2048-bit RSA key cannot encrypt more than 245 bytes in one go) and have high overhead (both in CPU and resulting message size). Since the symmetric key is not saved anywhere on the sender's side, a new random key will be created each time, and will be different with overwhelming probability.
Asymmetric encryption itself is randomized. E.g., with RSA, the padding includes random bytes. This is needed "in general", because the public key is public, so everybody knows it; if encryption was deterministic, attackers could run an exhaustive search on the message. This would not be an issue in the specific case of OpenPGP (the message is a random key, large enough to defeat exhaustive search on its own), but standards for RSA or ElGamal have a larger scope and include random padding.
When doing the symmetric encryption itself, a random IV is used, and will be different (with overwhelming probability) for each invocation. See section 5.7 for details.

The third point also applies when doing password-based encryption (encryption is done with a password, not with a recipient's public key). Password-based encryption also adds a fourth randomization, which is the salt in the password-to-key transform.


How long do keys stay on keyservers? Do GPG/PGP keyservers "garbage collect" old keys which have expired, been revoked, or simply haven't been updated in a decade? Or does the server (theoretically) keep every key it has ever seen from the beginning until the end of time?

Is there any other reason keys are removed (such as if spam or abuse was detected)?

Do GPG/PGP keyservers "garbage collect" old keys which have expired, been revoked, or simply haven't been updated in a decade?

A kind of "garbage collection" might theoretically be implemented for some OpenPGP key servers, but currently isn't (at least not for the large pool of synchronizing key servers).

There are several reasons:

Sharing information on expired and revoked keys is important, as there still might be somebody out there who hasn't updated the key yet, and does not know of a (new) expiry date or the revocation.
Pretty much the same applies to keys not updated. There still might be people that have not received important changes to your key yet.
All keyservers trying to replicate the whole web of trust help in regard to deletion attacks. It makes removing keys/users by an attacker much more difficult, and the whole web of trust more robust.
Transient trust also relies on keeping old connections, if you remove them, the web of trust would be weakened.
Especially regarding the SKS synchronization protocol, which uses set-based reconciliation (in the end, it calculates the difference between the key server's information, which is then exchanged), this would break key server synchronization, or at least make it much more complicated.
What happens if anybody just uploads your key again?

  Or does the server (theoretically) keep every key it has ever seen from the beginning until the end of time?

Don't ever expect information on key servers to disappear. The whole key server network is built around not losing any key information. Keys and signatures get revoked (or expire), not deleted. If you haven generated a revocation certificate yet, do so. Now. And store an offline printed copy somewhere you definitely won't lose it, it is your last chance to declare a key as unused if you don't have control over it any more.

  Is there any other reason keys are removed (such as if spam or abuse was detected)?

Whom to ask deleting the information, where to report abuse? There is no single instance for managing key data.

It is even close to impossible contacting all key server owners (there are hundreds!) and pledge for deleting a key. You'd have to convince all of them to do so; and they're spread all over the world, law inforcement wouldn't be helpful, either.


Securing communication The problem:

I have an open-source client (a Firefox add-on written in JavaScript) and a server containing somewhat sensible user information: username and user history (all from YouTube). The client is able to add new entries to history and to query full history (by telling his username). The communication is on HTTP protocol. The problem is that, there's no passkey or any authentication. This means than anyone can fake to be somebody, by creating fake HTTP requests, with modified GET data, and retrieve a full history of another user.

How can I generate a password (or hash), that can't be guessed, but it can be used to authenticate the client?

Possible solutions (or what have I thought / tried already)

1. Create a registration system for this service

I could add a registration form and a login form, and associate service user with YouTube user with some kind of verification, but that's too much hassle for the user. It's really just a basic service so this would be an overkill.

2. Make it closed source

Firefox add-ons are not necessarily open sourced. By making it closed sourced, I could do a simple trick like creating a costum hashing function (or just simply a costum salt for the hash) which is hidden by the closed source. This way I would generate a password direclty from the username. There are two options here:

a.) Create it as a C++ XPCOM component. I tried that. But turns out, this is also an overkill. It's very incompatible across gecko versions and I haven't even got to compile it across platforms. It's really hard to debug, there's almost no support at all and most importantly: I don't like the idea of maintaining a binary piece compiled for every version of Firefox for every platform just to have 5 line of code encapsulated in a 300 line interface. Also, what if I decide to port this add-on for Chrome? There's no such thing as XP-COM.

b.) Make it an obfuscated JavaScript. I don't know how to write JS code that is hard to decipher. It's also much easier to just copy paste the obfuscated code, change the initial parameter and have the hash for the desired username. With the XPCOM component is so hard to work, thus isolate and run it with false username, that I almost consider that as acceptable security :D.

3.) Get password from YouTube

If I could get a code from YouTube, just as easily I am getting the username (get a dummy page in background and fetch the username from source code) I would be saved. But I can't. There's no way I could get the real password, maybe if it's saved I could get that way, but I can't base on that. Well, I don't need the real password anyway, anythings fine as long as it's a secret, it's unique to user and constant by user (every user has one and only one, available anytime).

a.) I searched YouTube's source code and the embedded player's parameters and found something, but wasn't secret. It was somewhere in the profile, and I could see other user's codes. So this means: I found nothing.

b.) I also checked the cookies. But after a re-log-in there was no cookie value that haven't changed it's value. Not that I could understand what cookie does what.

Overview

The problem with all these are that... they are so unprofessional. I posted this question in hope of some cool method invented for scenarios like this. A handshake or something.

I need this because I have to write a Terms of service for my add-on. And I can't just write inside that I'm saving your history to an external server for the benefit that you can use my add-on across many computers without any security, That anyone who downloads Fiddler, and knows what HTTP protocol is can simply view what videos have you watched.

Sorry for the question being so long, and sorry if it's off topic (I hope it's not).

There's no way to implement this in such a way that it is manageable and has effective security. That you have to use HTTP (and therefore not HTTPS) makes it very, very difficult to protect the system against MITM / replay attacks. Generating a hash determinisitically from the username directly does not really help - it doesn't solve the MITM problem and exposes the system to brute force attacks.

You could just generate a random value, store it in a long lasting cookie and use it as a session identifier (effectively a password surrogate) matching it to a username on first access - this will still be vulnerable to XSS and MITM - but then you've got the additional problem of how you reset the users password.

You can't get the youtube account password from the youtube - but you can get it from the user along with the youtube username and test it for validity.

I think you could do a lot worse than what is done here - using a long lasting session id, authenticated against openid or a application specific service. (But do bear in mind that this is not totally secure).


How to monitor HTTPS traffic using wireshark? How do I monitor HTTPS traffic using wireshark?

Type tcp.port==443 to the search bar to filter the traffic to HTTPS only.


Setting Access-Control-Allow-Origin: * when session identifiers are injected in the HTTP headers Is it considered as secure for an application to set a header access-control-allow-origin: * if during the normal usage of the application, the client credentials are injected in the headers by the JS code? E.g.:

GET /application/secretStuff

X-Authorization-Key: aaa
X-Authorization-Secret: bbbb

This means that if an external malicious code tries to make a call to this URL it will be able to see the response, but this will be an authorization error anyway.

I understand there is at least one important drawback with this, namely the increase of the attack surface. But I'm looking to understand if this approach has other major problems.

This means that if an external malicious code tries to make a call to this URL it will be able to see the response, but this will be an authorization error anyway.

Yeah, that is correct. To be able to get anything of value out of it, the attacker needs to get the credentials. If these are stored in local storage, in JS variables or whatever they will be protected by the same origin policy that the browser enforces.

So there is no major problem with your CORS policy in of itself. But there are many related issues that you need to think about: Is the authentication scheme good? I assume third parties are supposed to use the API since you want to enable cross origin requests, so how do the third parties get the secrets? And so on.


Can my ISP provide my parents with what sites I visit? Ok so I'm LGBT, but I'm not out to my parents. They wouldn't be very accepting- and I don't want to be in an environment where they know because trust me it would be a bad situation. However, I want to start connecting to online LGBT resources. I'm currently living at home and I don't want them to find out if I go to LGBT sites and things like that. If I use incognito mode on google chrome I know it stops it from displaying the sites on my internet history, but the ISP still can see it. Is there a way my parents could get the list of what sites I visit from my ISP? My dad knows a lot about tech and security as well- so is there anything I can do to stop him seeing it knowing that he knows a lot about internet security and might know if I'm trying to hide something?

All the sites you visit regardless of what you use software wise (incognito mode etc) need to do a DNS resolution, i.e query the domain name for an IP address.

If you are in the UK your ISP will have a record of all this, I cannot comment on other jurisdictions but would be surprised if the vast majority did not have the same level of data.

If the sites you are visiting are HTTPS, then that is all the ISP will have just the domain name of the site, if however the site is only HTTP, your ISP will also have full visibility of the sites content.

If your dad is tech savy he can also see all of this if he wants. At the very least he can view router logs and see the site domain names.

Your best defence here is to use a hardware based VPN, again you could use a software VPN but there is a chance it may be interrupted and you device would just revert back to the regular network while it re-establishes a connection (There are way to stop this but it requires some know how).

Another option is TOR, however this may be more trouble that it is worth if you are not familiar with it. It would allow you to mask all your internet traffic from both your family and your ISP but there is a learning curve with it.

Some valid arguments against your dad for using such devices include:

Getting round content restrictions
Using a lot of public WiFi, you want to be sure you are safe
Your uni/school/place of work have request it
you don't want your ISP knowing what you are doing


Does Readdle (Spark) keep my logins/passwords on their own servers? I have installed Spark application (mail application from Readdle) on my Mac and found out suspicious logins from California in the logs of my mail server.

I am in Russia and don't use this application's password in any other applications. I have checked the IP addresses (104.196.115.172, 104.196.189.179, 104.197.31.95, 104.196.161.60) - it looks like Google Cloud.

I have created a new mail account on the different mail server and checked mail from Spark application. The same story: after 20-24 hours I have found logins from the USA:

I have created a request on Readdle support, but didn't receive any answer after 2 days.

I am not security expert, but it looks very queerly. First of all, Readdle keeps my login and password on their own servers. Second, they periodically connect to my mail account using my login and password.

What do you think about it?  Do I need to worry or is it OK?

Here is a reply from support:

  We use server side pushes to send you fast notifications. In order to
  send these push notifications, Spark server needs to check your email
  account — either using Oauth token (for Google, Outlook and yahoo
  account) or via your credentials. Our servers are located in the US,
  so probably yes, these are connections from our servers.

I would preferer to have an option to turn off this notifications. Now I have changed the email client.


Can I use a satellite phone for 2 factor auth sms and such? Would 2 factor authentication SMS messages or other kinds of internet security notifications work with satellite phones? E.g. companies like Google, Paypal, Facebook, banking institutions and others would still send/recognize phone numbers associated with satellite carriers? Any experience?

As mentioned in the comments, there should not be a technical problem using satellite phones for 2 factor auth, but there is a cost aspect for the service provider that might stop it. As the service provider normally pays for the texts used for 2 factor authentication, there may be limitations set up.

On this site you will see how the supplier mentions the fact that satellite phones would be a huge expense for the business.

  Maximum call rate : Since you are paying for the outbound calls , you also have the option to limit the cost per minute associated with
  these calls. You probably do not want your end-users authenticating
  themselves using Satellite phones (that would be very expensive,
  ouch!)