Couldn't credit/debit cards easily be made more secure? As a person who is going to get my first credit or debit card, I began researching a bit about security of them and a couple of questions came up about why the system is designed the way it is.

I read about large leaks of credit card data from websites, sometimes it was millions of credit card data hacked which would later be sold and used for fraud. Couldn't such leaks be avoided if the merchants didn't keep the details of online transactions? In other words, why payment processor like Visa or Mastercard can't act as a middleman? Before buying a product online, a shopper would be redirected to the payment processor's website and it would be there where the card details are entered. If the payment processor accepted it (the data would be correct and the fraud detection mechanism wouldn't be triggered), Visa/Mastercard would take the money away from the buyer account and send it to the merchant. That way the merchant can ship the product and, as the middleman is a trusted third party, it can expect to receive the money later. The difference is that the merchant doesn't have to know the details of the card that was used in the transaction, so it cannot be leaked in the future. Why doesn't it work that way?
Is a CSC (card security code, a 3 or 4 digit code printed on the card) always required when buying online and if not, what does it depend upon if it's required - is it up to merchant whether to ask for it? If they are always required, why is it such a big deal when millions of credit card details leak due to a hack? A fraudster would still need the CSC code to buy anything online, right? Or are the CSC codes always included in the leaks because online stores didn't remove them after transactions (I read the law says that they shouldn't be stored after a transaction is completed).
Why the CSC number is only 3 or 4 digits? Couldn't fraudsters try all the possibilities? Or is there a maximmum number of attempts before a card is blocked?
Why is the CSC number even printed on card? If the card is stolen or somebody writes down or memorizes the number, the card holder is compromised. As far as I know, online transactions use CSC and offline transaction use PIN which you type in the terminal (like in a restaurant). Wouldn't it be better if there was just one password not written on the card that is used to authenticate both types of transactions?
When I read headings like "10 millions of credit card numbers leaked" do they actually mean only the numbers? Isn't the numbers alone useless without data like expiration date, name of the card holder, which as far as I know are also used to authenticate a transaction?

All very good questions. There is a lot of nuance and history here that short answers have to elide that is worth the research if one is interested.

  Couldn't such leaks be avoided if the merchants didn't keep the details of online transactions? In other words, why payment processor like Visa or Mastercard can't act as a middleman?

Merchants are not supposed to store payment details following a transaction- except in rare cases where users are engaging with merchants to create a recurring transaction, e.g. a subscription- but some nevertheless do, in contravention of requirements they have to follow for taking card payments, colloquially called PCI after the organization that administers them (which is sponsored by the payment brands, Visa and Mastercard). These improper storage points have of course been compromised leading to significant fines and costs for the merchants involved.

However, storage, whether proper or improper, is far from the only attack point. There has to be machinery to capture the card details from the cardholder at the point of sale and communicate that with the various banks involved- at minimum the acquiring bank, the bank with whom the merchant has a relationship allowing them to collect cardholder payments- and cardholder banks, the banks responsible for approving the use of credit or confirming the availability of funds for debit. This communication is often logistically brokered by payment processor middlemen, which operate in various layers, specializations, and relationship shapes, depending on industry and so forth.

All players in the communication flow have to adhere to PCI requirements around "cardholder-data-in-transit" but as one might imagine they all do better or worse at this and all have been subject to compromise as well.

At any rate- the answer is that attackers go where the weak points are. There are many weak points in the overall payment machinery, so many that the Federal Reserve last year started a national program to systematically improve both security and latency in all payment systems (see https://fedpaymentsimprovement.org/).

That certain weak points have been exploited and there has been a recent history of public shaming is not an indication that there are not other weak points lurking in the system.

  Why doesn't it work that way?

The mere presence of a middleman does not provide better security, though it can reduce the attack surface- or simplify the attacker's problem, depending on how well they do their job.

However, what you are really referring to is a better protocol- which can provide better security- and that's what we are seeing with the rise both of chip-based payments (called EMV in the US) and its online cousin tokenization. Both of which work by using cryptography to create single-use payment credentials at the point of sale, rather than always distributing a reusable payment credential. Lots to google there if interested.

  Is a CSC (card security code, a 3 or 4 digit code printed on the card) always required when buying online and if not, what does it depend upon if it's required - is it up to merchant whether to ask for it?

It is not always required when buying online. The decision is usually the merchant's, which can experimentally weigh:

reduction in sales due to consumers having to enter more data to complete a transaction
reduction in fraud due to what might be loosely called an additional factor that is slightly less available to fraudsters
reduction in fees from acquiring banks on transactions that use the CSC vs those that don't.

  If they are always required, why is it such a big deal when millions of credit card details leak due to a hack?

It's a big deal from a news perspective because, for various reasons, more consumers pay attention to issues of this kind now. Largescale leaks from several years ago that were far more damaging in absolute terms received far less media attention.

It can also be a big deal for the retailers involved from a business perspective because the rules- called PCI, as mentioned earlier- have gotten tighter, and fines and penalties for violating the rules have gotten larger. So when retailers violate the rules, like storing cards when they should not have, the impact can now be materially significant to their business.

It's less of a big deal from an operational or fraud perspective, because all the parties are accustomed to the remediation- send consumers new cards, invalidate the old ones, rinse and repeat. Expiration dates have gotten shorter on newly issued cards, so loss of a large number of cards is to some extent just an extension of normal workflow for card providers.

  Why the CSC number is only 3 or 4 digits? Couldn't fraudsters try all the possibilities? Or is there a maximum number of attempts before a card is blocked?

The code that performs system of record transaction processing checks for various indicators of real or attempted fraud, including multiple attempts against the same payment instrument within a particular time frame.

There is also a lot of geographical rationalization- use of the same card number in two physical Point of Sale systems in different geographical areas in the same day will get heightened scrutiny.

But there are many other signals here- payment fraud is a very interesting and active application area for machine learning.

  Why is the CSC number even printed on card? Wouldn't it be better if there was just one password not written on the card that is used to authenticate both types of transactions?

Convenience, all around.

It is absolutely fair to say that the CSC number does not rise to the level of being a second factor, but it is also absolutely fair to say that a second factor is still infeasible in the real world when it comes to usability and convenience. Even security people still struggle with second factors, much less ordinary consumers.

A more common "second factor", so to speak, is required use of cardholder zip code, which is much more common than required use of a CSC.

My sense is that on balance, CSC is attributed with a relatively modest reduction in fraud at relatively modest infrastructure expense, but that it has not been considered a success. Chip payments and tokenization are much bigger impact.

  When I read headings like "10 millions of credit card numbers leaked" do they actually mean only the numbers? Isn't the numbers alone useless without data like expiration date, name of the card holder, which as far as I know are also used to authenticate a transaction?

A reported compromise will be of whatever the compromised party considered to be sufficient data to capture payments. Card number and expiration date are the only data points that are always required by payment processors and other downstream systems. Other data points like name, address, zip code, phone number, CSC, email may or may not be, depending on the particular details of the merchant, the business, their provider relationships, and so forth.

Most of the use cases around additional data collected at payment time are for marketing rather than strictly for payment verification.


Does HTTPS Encrypt PHP Arguments? I am working on a web app that will need to have a secret key(s) passed from one server to another - I'll need to do this over PHP. Consider the following URL:

https://www.myserver.com/secure/somePHPFile.php?supersecret=bananas

Could a malicious person intercept the request and read the 'supersecret' argument?

The same question had come up in stackoverflow some time back,please find the link below.

https://stackoverflow.com/questions/893959/if-you-use-https-will-your-url-params-will-be-safe-from-sniffing

To summarize the answers mentioned in the link, the url parameters that are sent to the server will be encrypted and hence is not vulnerable to interception, however if you are referring any 3rd party from your page (eg:jquery) then unless the reference is via ssl, the entire url will be present as clear text in the http referrer field and that can be intercepted and read.

Possibly the urls can be logged as plaintext on the server, in the  browser history and maybe there are browser plugins that cache the url.Hence it is not a good practice

It is better to send sensitive parameters using POST.

Additionally i have confirmed by running wireshark while accessing https://google.com. the URL had a lot of parameters and everything was encrypted by ssl.


Secure key generation and authentication in PHP I'm not sure how to phrase this so I'll just explain my scenario and hopefully you can help.

I have to create a site that will have 50-100 students all selecting courses they would like to take for the next semester. As each student ideally should only be able to access the site for a week, I was considering generating a key and emailing the key to them. This key would be 8-10 alpha-numeric characters kind of like: 8fgea2awde. The key would be stored in the database with an expiry date linked to the users account. Then once the user logs in with their key a secure session is created and authenticated while they are logged in. I know it's not very far from the username & password approach.

I know Oauth exists, although I have no idea how it works. Ideally I wouldn't like to "roll my own" security, I'd like use a third party but I'm not sure how that would fit into my situation.

I was wondering if this was a good approach? Do you maybe know of a better or more widely used approach?

You'd be saving me a lot of hell.

The question is more geared towards is it a good idea to generate
  passwords for the users and email it to them?

Reasons not to do this include:

It could be vulnerable to shoulder surfing. A user walking past while another user opens their email not expecting a password to be displayed could have their credentials stolen. This is particularly a risk at a college environment where everyone is using the same system.
This violates a policy of never outputting passwords. A more secure system only ever has passwords input - stick to this rule and you will tend to find you generally end up with a fairly secure system in terms of password management.
Anyone who has temporary access to an email account will be able to grab the password undetected. For example if the workstation is left unlocked for a very short period it will enable a very passive attack where very little evidence of the compromise remains.

A more secure system would email and instead include an link and a cryptographically secure one time code. This will enable the student to follow the link, enter the code (the link and code can be combined with the query string, however this is slightly less secure as URLs are logged by default, stored in history and can be exposed in the referer header) and then set up their own password.

Once the password has been setup, the link cannot be used again, making any later use of the email benign.


why MAC address can not be used as session identifier instead of session ID? why MAC address can not be used as session identifier instead of session ID?

why the physical address (MAC address) cannot be used as a session identifier during the communications between servers and client?

The MAC address is an identification of the specific network card at layer 2 (data-link layer). It stays only constant within the local network where no routers are involved. Once the traffic crosses a router the original MAC address is lost, i.e. the packets now have the source MAC address of the router. And if the packet is transferred by another router the MAC address is replaced again.

Given that in typical setups server and client are not within the same local network, the server has thus no knowledge of the clients MAC address at all and thus cannot use it as an identifier for the client.


How to determine if mail was encrypted during transport using the header information? First things first: I know about the difference between end-to-end-encryption and transport encryption.

Back to topic:
I already read some things about how mail server handle transport encryption, e.g. How Can You Tell if an Email Was Transmitted Using TLS Encryption?.

Here are two examples for incoming mail to my provider's mail server (I edited the second one):

Received: from mout.gmx.net (mout.gmx.net [212.227.15.19])
    by mx02.posteo.de (Postfix) with ESMTPS;
Received: from XXX (YYY [1.2.3.4])
    by mx02.posteo.de (Postfix) with ESMTP

Does the occurrence of ESMTPS in the first example mean that TLS was used for transport encryption?

Does the occurrence of ESMTP in the second example mean that the mail was transferred unencrypted between the two servers?

Does the occurrence of ESMTPS in the first example mean that TLS was used for transport encryption?

Yes, but only if you believe the MTA that inserted that header and every MTA that touched the message subsequently. Any of those MTAs could write that information into the header even if it isn't true.

  Does the occurrence of ESMTP in the second example mean that the mail was transferred unencrypted between the two servers?

No, here's a counterexample:

Received: from XXX (XXXX [IPv6:XXX])
    by XXX (XXversionXX) with ESMTP id XXXX
    (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
    for <XXXmy-addressXXX>; Tue, 23 Jun 2015 10:24:53 +0900

That mailer appears to have chosen to include information about the connection crypto in parentheses and did not write ESMTPS. So it appears there are definitely multiple ways of indicating this information in the header and you'd have to recognize them all. But once again, you cannot trust any of it anyway.


How to know the windows security dialog asking for username password is genuine? I recently faced one issue. It appeared my outlook launched a dialog saying it needed password. It looked like this

I noticed the "->" character in the domain name which usually it auto fills. Also the image it is showing is the default windows 7 user image. I have changed it and it doesn't reflect that. e.g. if I launch remote desktop, here is the windows security dialog which comes up.

What's going on? Is Outlook launching some custom dialog for password? How can user trust such dialog? Is any app free to launch such dialog?

What's going on?

Deviant software behavior. It may be a simple bug, or it could be the side effect of a malicious program. it's hard to tell without more information.

  Is Outlook launching some custom dialog for password?

It looks like Outlook ow whatever programs you are using are sending data to a standard authentication mechanism. My guess is that there may be some language translation occuring: i.e. from some language to English.

  How can user trust such dialog?

You would need some assurance mechanisms in place. An integrity checking mechanism is a good place to start. You will need a know good integrity value and a system capable of periodically checking your current software against the known good values.

  Is any app free to launch such dialog?

More or less yes. Windows provides a framework to programmers for presenting GUI components to users. Even if the authentication mechanism is protected the dialogue GUI can be faked and has been on many versions of Windows in the past.


Is it dangerous to delete my email account? If I delete an email from a popular provider (Gmail), would it be possible for somebody to register a new email account under the same name and use it to steal my identity? For example, my email address is abc@gmail.com and after it is deleted the name becomes available again so the attacker registers the same address - abc@gmail.com.

Not only would that person be able to impersonate me by sending emails from an address that belonged to me but also access accounts that were previously created with that email account (if they had any knowledge of where I was registered in, because the inbox would be empty, or they could also try logging in on popular websites like Facebook or Ebay to see if they return "no account with this email address" or "wrong password") and access them (by using "I forgot my password" links that send the link to reset the password to the email that is now in control of the attacker).

Yes, any provider that allows old emails to be reused opens you up to accounts registered with that email being recoverable.

Attackers can already spoof the email From: field, but there are mitigations in place, especially with a provider like Gmail. So registering your abandoned email would be a significant win for an attacker, if their goal is to impersonate you.

Using PGP to sign your emails would help with the impersonation aspect, but not with the account recovery attack.

You also never know if your email provider will change their policy in the future, to allow reusing old emails. If you want them to stop retaining your emails, this does put you in a complicated position.


Security concerns with uploading an image We have to implement a user profile image upload feature in our web application. The user can upload his profile image.

After uploading the image, it will be saved to a DB2 DB, and it will be rendered only to the user who uploaded the image after the login.

Technology stack is J2EE, AIX, DB2.

We received a strange complaint from our security department that this feature needs to be dropped because the user may upload a virus and this will infect the server!

I don't understand how a user will upload the virus. At the end of the day, the virus is a program that needs to be executed, right?

Second thing: the platform is UNIX-AIX. Even if a user uploaded a malware the server will not be infected, right?

Last thing: there is a possibility that the user would be infected by XSS in the case where a JS file was uploaded instead of image. But, I can see that in our case this is not valid because only the user can upload the image and it will be rendered only to the user.

Is my understanding is right?

As schroeder mentioned, you may have neglected some detail here, which makes your security group nervous.

There are a number of classes of attack the security group may be concerned with.  Just a few for example that might be worrying them:

File Upload - you don't mention how this is handled.  Some questions to consider - Is there enough temp space on disk, what happens to the temp file after the upload, can the user specify the file name, how is the file size determined and enforced?  Any and all of these could be vectors for an attacker.  The most obvious one would be to tell the server the file is one size, have the server allocate that much memory, then send something bigger and corrupt the server's memory, possibly getting code execution.
Store in the database - can the user specify a file name, or is their username added to the database table, and if so, what does the SQL to store those values look like?  Are you sanitizing the input, or using stored procedures, or does you code do something like (pseudo-code) "db.store($picture_file, $name, $table_users)" ?  In the latter case, that's very bad, and likely to expose you to SQL injection . Not strictly speaking a "virus" but something your security department would care about.
Upload authorization - Could someone else upload a file on behalf of a different user (e.g. could they guess a user number in a URL parameter)?  Or, you mention XSS.  What if the user is victimized by some other site via XSS to upload a payload to your site?
AIX OS resistance - No OS or specific flavor of Unix is 100% safe.  Assume the attacker is out to get you (or your user) and has done their homework and has crafted AIX-specific shell code.

Basically, what it comes down to is that we don't have enough details for a thorough security audit of the feature, but your security team does.  The details matter and the list of the technology stack provided tells us nothing about the vulnerability profile of your specific application.

One can make a reasonably secure "image file upload" function for a service, but nothing in your initial post suggests excessive paranoia on the part of your security group.

Talk to them, find out specifically what they don't like about the feature, and work with them to provide the functionality you want in a way acceptable to them.


Is it less secure to sign the semantic representation of payload then the lexical representation? I think an example illustrates my questions best.
Let's say that I want to send a JSON message.

  { "payload": { "b": 5, "a": 1 }, "signature": "...9oZRsvygw1pTFuRcfXXpFKMRBmkrzdTn6lzS..." }

Alternative X would be to put the payload in a string, possibly base64 encoded, and sign that string.

Alternative Y would be to make a canonical representation of the semantic content of the payload and sign that.
For example I could create and sign the following string instead

  {"a":1,"b":5}

Note that in the semantic representation the keys are ordered based on name and not initial order.

Would it be less or more secure to sign the semantic representation?

Both should be secure as far as I can see.

Ordering the keys (assuming the remote reader does not care about ordering in the initial example) in theory makes it slightly more secure because it limits options for the attacker when trying to create a collision - but if you are using a cryptographically secure signature then you shouldn't care either way. You should not think in terms of "more/less secure", only in terms of "secure" and "not secure" where secure is not known to be breakable within a reasonable timeframe with current public knowledge and technology.


Why is "something you know" the weakest factor of authentication? Quoting from CompTIA Security+ guide

  The first factor of authentication (something you know, such as password or PIN) is the weakest factor.

Why? it makes sense when we say that humans/users are the weakest factor in any system from security point of view as we humans forget, make mistakes and break easily. But it makes no sense (to me a least) that getting kidnapped and tortured (in order to give up my password) is more likely to happen than me losing a smart card or a key fob?

In the typical case, something you are and something you have can only be true for one person at a time. If you lose your token, you know you have lost it.

Something you know can be copied by someone without your knowledge. If someone has your password, you may not be able to tell that they are actively exploiting that knowledge.

That is one reason to change your password regularly. It shortens the window where a password breach could be exploited.


Using Multiple Keyfiles in Truecrypt Suppose if I have a truecrypt container who's main password is 20+ characters long and say, I use three random pictures as a keyfiles. It seems this way I could even use five keyfiles at random but what's the advantage of using them?

Isn't it just using one key file would be sufficient for improving security of password?

To know the strength of your password, don't look at its length, but at its potential. A password is as good as it is random, i.e. as good as the number of other values it could have assumed.

A simple case is when the password was generated as a sequence of random letters, each letter chosen uniformly and independently of the other letters. Since there are 26 letters, a 20-letter password implies 2620 = 19928148895209409152340197376 combinations. An attacker trying to guess the password will need, on average, to try half of them before hitting the right one. The accumulated cost would be tremendous, so the attacker would have very little chance of breaking through it. This number of possible, equiprobable combinations is often called entropy (not exactly the same notion as in physics, but close enough) and traditionally expressed in bits: you have an entropy of n bits if the number of equiprobable combinations is close to 2n. With 20 random letters, this means about 94 bits of entropy.

Moreover, TrueCrypt uses a good password hashing function, namely PBKDF2 with a random salt and 1000 (or 2000) iterations. Password hashing is a subtle matter, and TrueCrypt does it correctly.

To make the story short, if your password entropy is anywhere beyond 70 bits, your security is fine -- meaning that the cost of brute-forcing the password would far exceed the cost of simply obtaining the data through other means, such as abducting you and your family, or simply buying you out. We are talking about several (many) billions of dollars here... So, with random letters (all lowercase, let's make it simple to remember), 15 letters are enough. If you add uppercase letters and digits in the mix, 12 letters suffice, but the password may be harder to remember, and harder to type, especially on tablets/smartphones.

A crucial point of password generation is the need for good, impartial randomness. If you chose the password in your head, then it is not random. Witticism is not randomness; quite the opposite indeed. It is hard to estimate how much random can be a human-generated password, but it is often observed that such passwords are assumed by their owners to be a lot more random than is actually the case.

In the example above, I used letters but the calculation easily expands to any set of "symbols", even words. See this answer for details on a famous example.

The key files serve two purposes:

To provide some extra entropy to a weak password.
To provide some extra entropy which does not come in through the same path as the password.

Indeed, a poor password can be brute-forced if it does not have enough entropy, but even good passwords can be preyed upon through various methods: keyloggers, well-placed security cameras, sleep-talkers... Some of these methods will grab the password but not the key file, so the key file may save your skin in some situations.

The key file adds some security only insofar as the attacker does not know the file contents. However, it is a file. It is written on physical media. It is made available to the machine itself upon disk unlocking. We must assume that someone who steals the machine will also have a copy of all the files which could serve as key files (it depends on where you store them, but they are probably close to the machine since you need them to boot it). So the secrecy of the key file is not about the file contents, but about which file is used. For instance, if you have 100 possible files, then entropy is multiplied by 100 (in "bits" notation, this means about 6.6 extra bits). On the other hand, you have to remember which file was used, so that's some extra effort beyond the one needed for the password itself.

Personal opinions:

I note that key file processing in TrueCrypt is singularly homemade and weird; my cryptographer's senses are quite alarmed at this assembly of CRC-32 and haphazard scrambling. It would have been much simpler and better to simply hash each file, then hash the concatenation of the hashes and the password itself.

Also, the scenarios where key files have any value are rather restricted: these are scenarios where the attacker could grab the password, but not the key file, or not the information about which key file was used. For instance, a camera which has a view on the keyboard may also see your screen and easily obtain that information.

Therefore, I deem key files "not worth it" and I find that using the brain memory capacity to remember the key file to use is better employed at remembering a stronger (more random) password.


AES successful decryption using wrong secret key I have a problem with AES encryption. I need to encrypt plaintext using CTR with a random IV. Then I need to encrypt the IV with the same key.
I know that it is not required to encrypt the IV, but I need it for my usecase.

To decrypt the message I simply first decrypt the IV and then decrypt the cipher with the decrypted IV and the key.

Currently I am using EBC to encrypt the IV, as otherwhise I would need another IV to encrypt the previous IV and so on.

The problem is that I am able to decrypt the cipher using a a completely different key from the enryption.

What am I doing wrong?

import java.security.SecureRandom;
import java.util.Arrays;
import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.spec.IvParameterSpec;

    public static void main(String[] args) throws Exception {
    //Generate a random AES Key
    SecretKey key1 = generateAESKey();
    byte[] plainText = "some plain text".getBytes();

    //Gerate random IV
    byte[] iv = new byte[16];
    SecureRandom random = new SecureRandom();
    random.nextBytes(iv);

    //Encrypt plainText using the generated key1 using CTR
    byte[] encryptedWithKey1 = encryptCTR(plainText, iv, key1);
    //Now encrypt the IV using key1 with ECB
    byte[] encryptedIvWithKey1 = encryptECB(iv, key1);

    //Generate another key
    SecretKey key2 = generateAESKey();
    //First decrypt IV with wrong key, which resuts in wrong IV
    byte[] decryptedIvWithKey2 = decryptECB(encryptedIvWithKey1, key2);
    //Using this wrong IV decrypt encrypted payload with wrong key
    byte[] decryptedWithKey2 = decryptCTR(encryptedWithKey1, decryptedIvWithKey2, key2);

    //Expect plaintext and decrypted cipher using wrong key to NOT be equal
    System.out.println("should print false: " + Arrays.equals(plainText, decryptedWithKey2));
}

    private static byte[] encryptCTR(byte[] plainText, byte[] iv, SecretKey key) throws Exception {
    IvParameterSpec ivParameterSpec = new IvParameterSpec(iv);

    Cipher cipher = Cipher.getInstance("AES/CTR/NoPadding");
    cipher.init(Cipher.ENCRYPT_MODE, key, ivParameterSpec);

    return cipher.doFinal(plainText);
}

private static byte[] decryptCTR(byte[] encrypted, byte[] iv, SecretKey key) throws Exception {
    IvParameterSpec ivParameterSpec = new IvParameterSpec(iv);

    Cipher cipherDecrypt = Cipher.getInstance("AES/CTR/NoPadding");
    cipherDecrypt.init(Cipher.DECRYPT_MODE, key, ivParameterSpec);
    return cipherDecrypt.doFinal(encrypted);
}

private static byte[] encryptECB(byte[] plainText, SecretKey key) throws Exception {
    Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding");
    cipher.init(Cipher.ENCRYPT_MODE, key);

    return cipher.doFinal(plainText);
}

private static byte[] decryptECB(byte[] encrypted, SecretKey key) throws Exception {
    Cipher cipherDecrypt = Cipher.getInstance("AES/ECB/NoPadding");
    cipherDecrypt.init(Cipher.DECRYPT_MODE, key);
    return cipherDecrypt.doFinal(encrypted);
}
    public static SecretKey generateAESKey() {
    SecureRandom random = new SecureRandom();
    byte[] keyBytes = new byte[16];
    random.nextBytes(keyBytes);
    SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
    return key;
}

CTR mode is a way to, in essence, turn a block cipher (which operates on "blocks" of data of a specified size, transforming them in a way that is deterministic based on the key and the input block, but contains complex internal math) into a stream cipher (which is, essentially, a secure pseudo-random number generator that you seed with the key and IV, generate a length of pseudo-random bytes the same as the length of your data, and then XOR them). Because the actual encrypt/decrypt operation (with regard to your data; CTR mode technically involves using your block cipher to encrypt successive numbers - the eponymous counter - to produce the pseudo-random numbers) is just XOR, there is no way for the algorithm to verify that the key is correct. Mathematically, there's nothing preventing you from taking plaintext stream PT, XORing it with pseudo-random stream PR1 (encrypt), and then XORing it again with a different PR2... you just aren't going to get PT back out again!

In fact, in general there's nothing preventing you from decrypting encrypted data with the wrong key. Some padding schemes (used to ensure that your data is a multiple of your block size, which is irrelevant for stream ciphers and counter-based modes of operation, so you aren't using one) include what amounts to a checksum that can be used to detect incorrect decryption (or tampering with the ciphertext) with decent reliability (worst case, with only one byte of padding needed, you'd still have only a 1/256 chance of a random key not producing a detectable error), but this is not secure; a competent attacker can bypass this check. In fact, often enough, an attacker can exploit this padding check to decrypt your message without knowing the key at all (via a padding oracle). There are some block cipher modes of operation that are what's called AEAD (Authenticated Encryption with Associated Data) modes, which include a cryptographic verification that the ciphertext was not tampered with between encryption and decryption, and that the same key was used for both (thus authenticating the decrypted message: you know it is the same as the message that was encrypted). The most common AEAD mode is GCM, which is also a counter mode (but does require additional space for the authentication data, if you want it to be any more secure than CTR). You can also authenticate the decryption in other ways, such as using an HMAC (Hash-based Message Authentication Code), which combines a cryptographically secure hash function with a secret key (can be the same as your encryption key) to produce a verification value (which needs to be sent/stored along with the ciphertext) that can be used to verify the key is correct and the message hasn't been tampered with. In general, though, encryption/decryption by itself provides no guarantee that the message out is the same as the message in, either because the ciphertext was tampered with or the wrong key was used! Encryption, as a general class, provides confidentiality of the data and nothing else.

  What am I doing wrong?

Trying to build some very weird cryptosystem when you don't actually understand crypto. Don't do that. Rolling your own cryptosystem is only slightly less of a bad idea than rolling your own crypto primitives, and while one might argue that it has a lower barrier to entry (you don't have to know nearly as much math, for example), you still don't meet it.

For example, I can't even guess why you think your IV needs to be encrypted, but if your use case actually requires it (unlikely), you're probably trying to do something that can't be done (at least, not securely). The IV is just to ensure that encrypting the same data with the same key does not produce identical ciphertext; its actual value is irrelevant so long as it is non-repeating and unpredictable (which is why it's typically long-ish and generated randomly) and certainly not secret. If you're expecting the IV to serve some other purpose than that, you're trying to use symmetric ciphers wrong.

A MUCH better idea would be to explain what you want your cryptosystem to do, and in the case that there's nothing which currently does that exact thing already and it's not impossible, let people knowledgeable the field design a new system to do it. Seriously, even experts screw up all the time. We're on the third standard for WiFi security (WEP, WPA, and now WPA2, with WPA3 coming out to address problems found in WPA2) and the fifth for TCP security even if you ignore the never-published v1 (SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, and now TLS 1.2, with TLS 1.3 around the corner), and even if the original versions of those were designed by crypto amateurs (I don't actually know, and it seems unlikely, but those were different times), the intervening versions weren't... and we still found weaknesses in almost all of them.


Why should I choose SHA (such as SHa-512), instead of bcrypt or PBKDF2, for FIPS-compliance? Due to regulation, my company needs to be FIPS-compliant.

I was looking at the current list of FIPS-approved cryptographical methods and I notice that neither bcrypt or PBKDF2 are in this list.

Does that mean I should use salted SHA-512 for password storage?
Is that a good idea?

FIPS 140-2 does not cover the topic of password hashing. Thus, there is no password hashing function which would be "FIPS-approved" in that sense. Using SHA-512 "as is", with or without some salt and regardless of how you inject the said salt in the engine, would not grant you the NIST approval. NIST simply does not approve (or disapprove of) password hashing.

The closest you can get in the NIST world is SP 800-132, that lists approved methods for password-based key derivation, something which is quite close (but not identical) to password hashing. NIST approves PBKDF2, as long as the underlying primitive used in PBKDF2 is itself "approved" (i.e. it is HMAC used with one of the SHA-2 functions).


Firewall on smartphones PCs communicate with the help of ports,eg. HTTP communication takes place over port 80. Due to the nature of these ports, an open port is an avenue for an attack. That's where firewalls come in.

The smartphones also communicate with the Internet. But, AFAIK, they don't come configured in any way with a firewall of any kind. Doesn't that mean that my phone is practically open for access by anyone?

If nothing is listening on a port, no connection can be made to it, firewall or not. The same applies for desktop computers and servers. In theory, you're still safe without a firewall if nothing is listening and the TCP stack in the OS isn't vulnerable.

We have the habit to use firewalls on desktops/servers because they are available and every layer of security helps, but mobile OS developers thought that was unnecessary and are confident in their TCP stack implementation (I suppose a firewall would induce additional CPU load which will decrease battery life).

There is actually a long debate on Serverfault about whether you should use firewalls on servers, you should check it out and make your own choice whether you want to install a firewall on your mobile device.

Also note that most mobile networks out there use carrier-grade NAT which means, at least on IPv4, that your device isn't directly reachable from the Internet and this provides some sort of basic protection (you're still exposes to attacks coming from that same mobile network). Of course this point no longer applies with IPv6.


Why is it not possible for browsers to completely detect the Phishing pages? The browsers have some capability to detect the phishing pages, but they are not able to detect all. Why is that?

Phishing still remains to be one of the most convenient way to hacking. Why is it not possible for browsers to detect all phishing pages, and not only the obvious ones.

Usually browsers don't actually detect the phishing page but rather use a blacklist of URL's provided by services such as PhishTank or OpenPhish. While some of the websites posted in these lists are provided by programmed detectors, most are reported by users.

The Chrome browser will use Google's large phishing DB compiled from Gmail reporting and other sources to block the visiting of such phishing pages. Google's DB (Google SAfe Browsing DB) is open to use and can be found here.

There is no one really to blame as phishing pages can be very complex and very targeted making it very hard to detect as a human and especially as a programmed detector. Browsers are trying their best to help out by blocking anything that is in the blacklists.


How does disallowing guest NAS access mitigates MitM attack? About a year ago, Microsoft has disabled guest access to NAS devices in Windows 10. As their community website explains, this was done for security reasons:

  While the server may be fine not distinguishing among clients for files [...], this can actually put you at risk elsewhere. Without an account and password, the client doesn't end up with a secure connection to the server. A malicious server can put itself in the middle (also known as the Man-In-The-Middle attack), and trick the client into sending files or accepting malicious data.

I must admit I don't understand this argument. How hard is it to create a malicious server that accepts any username/password? It looks like this explanation is dumbed down to the point it doesn't explain anything. Could someone explain how disabling guest access prevents MitM attacks in this case?

Consider the following scenario:

You set up your NAS box at home with guest access.
You set up your laptop to connect to the NAS box with guest access.
You configure your backup program to back up your data to the NAS box.
You take your laptop to a coffee shop and join the free WiFi.
An attacker sets up a NAS box on the coffee shop network.
Your laptop thinks this is your home NAS box, connects to it successfully using guest access, and backs up your data to the attacker's NAS box.

The attacker now has a backup of your system, including pictures, documents, etc.  By disabling guest access, you prevent your laptop from successfully connecting and making the backup.

This security fix is a patch that now requires that all connections be "authenticated". For most home users of Windows, that means they must set up a HomeGroup.  The coffee shop attacker cannot set up a fake NAS box that would fool your computer, because he does not know your HomeGroup's password.

HomeGroup uses SMB to mutually authenticate peers, and SMB uses a challenge/response protocol to ensure that passwords are never sent over the network.  Instead, challenge/response uses math to prove the client knows the password without actually sending the actual password.


Using local files securely on website I have a website on which users can select a file from their local machine, manipulate it and then save it.

The website is written entirely in JavaScript to ensure it's purely client-side. Is the content of the file that the user selects completely secure (from the perspective of the website itself, I realise the user could have malicious code on their local machine, etc.)?

Secure in the general sense that a MITM (or similar) attack couldn't
  successfully get the data from the file the user uploaded on the
  client-side

MitM is not possible in such a scenario as the file never leaves the client so the attacker cant intercept it. However, an attacker with Man-in-the-Middle capabilities could still intercept your JavaScript code in transmission, so it is highly recommended to use HTTPS everywhere.

  The website is written entirely in JavaScript to ensure it's purely
  client-side

Well if there is no server side processing you have greatly reduced the attack surface.There is also no user base(cookies,jwt) i assume so an attacker cant target that either.The only thing i can think of is cross site scripting.An attacker could inject malicious javascript and then wait for the user to upload something,when the victim does he can simply retrieve that file.

Also i might add from androl's comment that you could also be "hacked" via vulnerability you introduce by using any piece of program that is vulnerable.But i wont comment on that.Always be updated and informed to prevent from such


Additional security for WebRTC/DTLS-SRTP with PGP? I am having a thought experiment. Can you help me?

Two clients who both use PGP.
They initiate a WebRTC call using DTLS-SRTP via a 3rd party server.

Is there any benefit of encrypting, via their PGP, the handshaking ...

Q1: ... when the communication is peer 2 peer.
Q2: ... when relay server is required due to routing issues.

I think both will be beneficial, but Q1 hardly, Q2 on the other hand maybe more worthwhile?

Thanks,
Paul.

DTLS-SRTP builds on DTLS which applies its own encryption layer. The handshake, by construction, is done outside of any encryption, and that's fine.

"Relay servers" are a red herring. The two clients will talk to each other by sending data packets which will go through a number of other systems. Whether you consider some of these systems as "routers" or as "relays" does not matter; security properties ensured by TLS (and DTLS) don't depend on the actual transport method.

Inserting PGP keys in the mixture does any good only if you want to use these keys as basis for authentication. This is theoretically possible, meaning that the protocol has been defined -- but it remains to be actually implemented and deployed. With this support, the X.509-based certificates of SSL are replaced with PGP public keys; this maps to DTLS as well. Getting rid of X.509 certificates is a good idea if you have other means to achieve mutual authentication, and PGP keys can be such means, as RFC 6091 describes.


What are the risks of encrypting a database with a single symmetric key An application is required to store sensitive data* on each user. Additional columns are added to the database which store cyphertext encrypted on the application server. The algorithm of choice is symmetric (AES) and a single key (assume that this key is correctly stored and distributed to the application servers).

My initial reaction to this design that I would favour using a different AES key per row, and storing each key encrypted with an asymmetric key next to the cyphertext.

Is my initial reaction correct? Would treating each database row as a "session" be more secure?

*Not your grandma's cookie recipe level. End of company level stuff. Ideally the system should be secure against information disclosure by anyone person inside or out of the company, or at least limited.

The risk isn't about the number or type of keys.

The risk is about where you're going to store those keys. Assuming your application needs to access the database, it will need a copy of those keys. If those keys sit on the application server somewhere, they can be stolen.

Until you tell me where the keys will be stored, your idea is simply creating more complexity. It's security through obscurity.


Convert RSA public key to the right format I need to send a public key to my bank. I'm using CoreFTP which allows the generation of keys using RSA. It says that it generates "OpenSSH compatible certificates [sic]" when you press the generate keys button.

The keys it generates have

-----BEGIN RSA PUBLIC KEY-----

at the start (and then the key and then an end marker).

My bank rejects my public key and says it should begin ssh-rsa.

I suspect "RSA" and "OpenSSH" have variations that neither end are being clear about what they generate/expect.

How can I convert my key from the format the CoreFTP is providing to the format my bank wants?

I believe the reason is that the CoreFTP is actually generating OpenSSL keys and not OpenSSH formatted ones.

Perhaps your question is already answered on Stackoverflow?

https://stackoverflow.com/q/1011572/643314

From Victor Matare on SO:

You can do the same with ssh-keygen:

ssh-keygen -f pub1key.pub -i -m PKCS8

will read the public key in openssl format from pub1key.pub and output it in openssh format.


Is it advisable to accept STUN server connections? My firewall reports outgoing connection attempts via com.apple.WebKit.Networking to a number of STUN servers (namely, stun.nas.net, stun.node4.co.uk, stun.voxox.com and stun.wwdl.net). This is requested by the Safari (Apple's browser) process. From what I can see STUN servers are required for VoIP connections. I found a brief run-down on STUN here, with more detail on the relevant Wikipedia page.

I don't run any VoIP services from my iMac (at least not knowingly). The only app that'd come to mind are maybe some conferencing software I once installed and Skype.

So far, I have not accepted the connections and haven't discovered any detrimental effects, but I'm wondering what might have been the initial trigger for the connection attempt.

STUN (Session Traversal Utilities for NAT) is a mean for a device which sits behind a NAT firewall to learn the public IP address of the Internet connections which is beding natted. I.e. your laptop may have been assigned a "private" IP address as per RFC 1918, for example 192.168.1.123. Any software on your laptop asking the operating system "What is my IP address" will get 192.168.1.123 as an answer, which isn't helpful for applications which try to use protocols that were simply made without NAT in mind.

The NAT unfriendliness of protocols usually kicks in whenever a client connects to a server and is supposed to tell the server its own IP address in order for the server to be able to initiate connections to the client (as opposed to just sending answer packets on the same IP connection; this is handled by NAT routers.

STUN is a means for a client to learn the public IP address of the NAT router through which the connection is natted in order to use that information when registering with a server that wants to call back now or later.

The 95% use case indeed is VoIP telephony, especially SIP.

If you found that the STUN requests originate from the Safari process, it cannot be either Skype or any other conferencing software, as that would typically spawn a separate process.

STUN (and TURN) might be used by Safari for WebRTC connections; though that should only happen while you are using any such sites, i.e. video chats in the browser.

Otherwise - to answer your original question - there is

no reason to allow those connections unless you intentially use any services which need them and
I would want to find out what piece of code (browser plugins?) try and make those connections

It may turn out it's something you just did not think about. But it may also turn out to be something harmful.


Using OAuth 2.0 without token storage I am building a system for a product which requires authentication and authorization. Naturally I have chosen using OAuth 2.0 as it is a commonly used protocol and has proven to be useful.

I am considering implementing tokens without storage - as described here: http://bshaffer.github.io/oauth2-server-php-docs/overview/crypto-tokens/

This would save me a lot of trouble with token storage, and of course means I have to go to the DB only for the initial login (when I issue the token).

Since I am not seeing this in common use - Are there any substantial cons to this approach? Is this a big security compromise?

I understand that I won't have some functionality (like logout deleting the token), but I feel this will have very big benefits when it comes to scaling the application.

The use of encrypted OAuth tokens is good approach to satisfying the security requirements in RFC-6749 section 10.  Encrypted OAuth tokens are in common use, Facebook is a good example.

OAuth tokens expire based on the expires_in parameter. Which means that a given token would be valid for a short time after the user logs out,  which is very low risk issue that majority of applications ignore.  Once the user logs out,  session riding attacks like XSS and CSRF should not be possible even if the OAuth token is still valid.


Encrypting a fixed format message? I'm planning to send across TWO pieces of information over the internet from machine A

A site identifier which will be like:

$SiteName = "EXAMPLE" (in plaintext)
Encoded text which will be like:

$Secret = encrypt($SiteName.'-'.time(), $key)

When I get these two pieces of information on machine B, I lookup the $key based on SiteName. If it decrypts and gives me "EXAMPLE", and within say 24 hours, i consider it a valid request.

Is this a safe mechanism?

The encryption methodology is :

$encrypted_string = mcrypt_encrypt(MCRYPT_RIJNDAEL_128, $key, $input, MCRYPT_MODE_CBC);
$transmitted = bin2hex($encrypted_string);

You do not describe the attack model (i.e. what kind of things an attacker may want to achieve) so I have to do some guesswork here...

A first thing to note is that you are encrypting the "SiteName", which you also send in cleartext, so one has to assume that any attacker observing a message in transit knows the "SiteName". You also encrypt the current time, which is public data (the attacker has a clock, too). Encryption is meant to transform some data in a way which keeps things confidential, but here the input to the encryption function is only public data. So you are using an encryption system for something other than what it was designed for, and that's a worry.

As you describe it, what you seem to be after is a way to authenticate a timed message: you want machine B to make sure that whatever software runs on machine A deliberately produced a given blob, which includes the production time and date. This calls for a Message Authentication Code, not encryption. The usual MAC is HMAC which uses an underlying hash function (when in doubt, choose SHA-256); with PHP, see function hash_hmac(). It is possible to make a MAC out of an encryption system, but it is somewhat tricky and there is no a priori reason to believe that mcrypt_encrypt() does something which is a good MAC; not that I know how to break it, but it is better to use a tool which has been specifically designed and studied to be a good MAC, and that's HMAC. So you want the message from A to contain the SiteName, the message production time, and a MAC computed over SiteName and the message production time, with $key as key.

Of course, nothing prevents an attacker from replaying an existing message, which may or may not be a problem with you, depending on what machine B does when it receives a "valid request". As a side-note, relying on current time has some practical issues, because there are many users who are quite happy with a system clock off by a few years (I work in the field of digital signatures and X.509 certificates, which have validity dates, and an unset system clock is the number 1 reason of failure).


What is most secure CAPTCHA system? Artificial intelligence has now become a real security threat, some bots using advanced algorithms can solve even the most distorted of CAPTCHAS text at a high accuracy.

Assuming that I'm developing a form the some important banking operations which needs the implementation of the highest level of security , what is the most secure CAPTCHA system that I should use.
Actually I'm not seeking a specific product recommendation and I don't care about CAPTCHA's usability , just the most secure concept ( I wont complain if there are some implemented examples though)

Thanks :)

Most secure is very subjective. Even Google's Captcha system has been known to be broken on ocassion, one example out of many. Treat Captcha as a speed bump to deter people from putting in a lot of effort to break it. Checkboxes if your speed bump is good enough is... maintained by a trusted company, regularly updated, and is useable. I know you said ignore usability, but the human factor cannot be ignored.


How to securely share only some information with a middle-man site Scenario: you run an app OurApp which deals with users' sensitive data, some of which you are allowed to share with third parties (with the user's consent, of course) and some of which you are not allowed to share even if the user consents.  You wish to integrate with a site MiddlemanSite which the user already has an account with.  MiddlemanSite will display a dashboard page which directly incorporates the data you are allowed to share, with click-through links to ourapp.com to view the data that isn't allowed to be shared.

Example: MiddlemanSite is the classic petstore app, and OurApp is a veterinary practice, which is allowed to share data like notifications that a user's pet is due a vaccination or checkup, but not the pet's full medical history.

Challenge: what workflow do I use for authenticating the user to OurApp which ensures that the private data is only accessible to the user directly, and not to a compromised or malicious MiddlemanSite, notwithstanding the fact that most of the user's interaction takes place on MiddlemanSite?

Thus far the best authentication workflow I can come up with is this:

It's clear that we need to have a direct dialogue with the user when first linking the two accounts: we need to do this anyway because we need to collect a secret (in our case an API key for yet another service, which we need in order to make our service work) directly from the user.  So when MS posts details to the "this user of ours has just asked to affiliate their account with OurApp, here are their details" endpoint, we return a redirect url for the user to be directed to, where we ask for the SuperSecret.  We can consider the user to be 'verified' if they know the SuperSecret.

Then we can set a cookie in the response to that submission which will allow us to identify that user in future visits; so when they click links on the MS dashboard they authenticate with both a token in the link query string (which MS will have access to) and the cookie (which MS won't).

However, re-validating the user on a different device or after a long time is more challenging.  I don't want to require the user to re-submit the SuperSecret because generating it is a pain, and we don't want the user to have to set a separate password for OurApp.  The best I can come up with is a quasi-two-factor-auth link sent directly from OurApp to the user's email or phone, which the user has to access in order to re-validate.  But given that the email/phone data was submitted to OurApp by MiddlemanSite in the first place, I'm uneasy about this being easily spoofable.  The best I can think of in terms of mitigation is to display the submitted information back to the user on the signup screen, so the user has a chance to see if it's being mitm'd.  And I can't think of a way of supporting the user changing their email/phone settings on MiddlemanSite and safely propagating that change to OurApp.

Questions:

0) Is there a standard protocol for this sort of authentication workflow that I should be using instead of reinventing a wheel?

1) Are there obvious security weaknesses in this workflow, beyond its extreme verbosity?  Assume that MiddlemanSite is either fully compromised or itself malicious, and seeks to gain access to users' non-shareable data.

2) Is there a better protocol I could use for re-validating users to replace using their email/phone records?  Needs to support the user logging in to MiddlemanSite on a new device and immediately clicking through from their dashboard to a page on OurApp.

This is a really big question, and one that might benefit from being broken down a bit. I'll start with question #0, though.

Is there a standard protocol? Several. It depends on exactly how you want to do this. Consider this extremely simple approach:

Cross-Origin Resource Sharing (CORS): The user logs into MS, and MS sends an authenticated CORS request to a /SharableData endpoint on OurApp (this endpoint, and only this endpoint, will return Access-Control-Allow-Origin: https://middlemansite.com and Access-Control-Allow-Credentials: true). If the user has an active session on OurApp, the sharable data is returned such that MS can read it. If the user's browser has no current session on OurApp, an error indicating this is returned and MS offers a link to OurApp so the user can sign in OurApp. If the user has a session on OurApp but has not allowed data sharing with MS, OurApp can either send back the same error as before (may lead to user confusion but conceals from MS the fact that the user even has an OurApp account), or can return an "unauthorized" error and MS could offer the user a link to their data sharing settings page on OurApp.

Advantage: Easy to scale to multiple middleman sites. Each MS, when on-boarding to OurApp, supplies some basic info about itself (name, icon, whatever) and the origin that the requests will come from. You verify that the details are valid, and allow the user to toggle sharing with that site. No need for secret keys, etc.
Advantage: No need for a server-to-server request flow. The MS server cannot access even the sharable data directly - it can only do so via the user's browser when the user is signed into both sites and browsing MS - and neither server needs to store any server-to-server keys or be configured to allow outbound requests.
Disadvantage: Requires sessions on OurApp to last long enough that the user can complete their browsing on MS without needing to log into OurApp annoyingly often (can be mitigated by having two sessions for OurApp, a short-lived session that is used when actually interacting with OurApp and a long-lived session that only gives access to the user's sharing-allowed data, with at least the latter stored as a token in a cookie).
Disadvantage: Potentially inconvenient back-and-forth between sites when setting up (could be mitigated with a "returnTo" query parameter that enables sending the user back to trusted third-party sites like MS, though beware creating an open redirect by accident).
Disadvantage: Potentially allows cross-user access to shared data, if on a shared browser a user logs out of MS but not out of OurApp, and then another user logs into MS (can be mitigated by having MS supply some kind of identification string - a name, phone number, email address, or whatever - with the CORS request, and rejecting the request if the ID string doesn't match the current session on OurApp). On the other hand, nothing you can really do about this; if a user shares a browser with somebody they don't trust and fails to log out of everything they were logged into (perhaps by using Private/Incognito mode and closing the window), there's not a lot that you can do to protect them).

Other options could include using a shared authentication provider (SSO) that attests the user's identity to each site (complicated when the users already have accounts, though; you need to support linking them) and letting a user on OurApp grant access to MS, or using a "connected app" model (probably via OAuth, which is widely used and supports all the desired functionality) where an authenticated user on MS can request that the user's browser provide an access token from OurApp, and OurApp first makes sure the user is logged into OurApp and then that they want to share the data. There are tradeoffs, of course; the SSO route requires all the sites cooperate on their SSO identity provider and existing account management, and the OAuth route allows a MS to query all the sharable data for all users who have granted access at any time, instead of only when the user is actually browsing the MS and also logged into OurApp (with at least a long-term low-access session).


How to approach Web App? I'm doing testing on the app, if we take only login url as a starting point.

How to expand my horizons?
I want to make my surface wider, really kinda stuck on this one.

Take a look at the OWASP ASVS, the application security verification standard. It is focused on web applications and provides a guideline for the security tests you should perform during a penetration test. Especially chapter V1.2 and chapter V2 cover a broad range of tests that should be done in regard to authentication. Keep in mind that some of them cannot be performed black box.

If you are actually stuck on the login form, I recommend asking your client to provide you with valid user accounts. Doing a penetration test on a login form, which you cannot bypass, will not add much value for your client, so he should be glad to supply you with accounts.


Is Mumble encryption end to end? Is it possible for a Mumble server operator to monitor or record users' conversations? Or are Mumble conversations encrypted end-to-end?

Mumble's home page states it uses public-key cryptography. This is done by using the TLS protocol, which is mentioned in the FAQ.

With public-key cryptography, the private key is always known by the server. Thus, a Mumble server administrator indeed has access to the private key - usually in the form of a X.509 certificate - which can be used to decrypt the TLS handshake to derive a session's symmetric cipher key. This key is used to encrypt and decrypt all data transmitted over the connection. In other words, an administrator certainly is capable of decrypting all traffic.

Also, nothing stops a server administrator to log and record communication on the server.


My Lantern cloud server has a domain name that looks like typo-squatting, should I be worried? Lantern is an app to avoid censorship. It is hosted at getlantern.org.

I just noticed that the cloud server my client is using is actually roundrobin.getiantern.org

Notice the i in getiantern instead of getlantern.
They look extremely similar with the app's font, I had to look very closely to see the difference.

Should I be worried?
Or can the getiantern domain be trusted?

getiantern is not found in the Lantern source code.

There are two possibilities in my mind:

Given the fact that you state that the apps font is very little, could it be that roundrobin.getiantern.org is in fact roundrobin.getiantem.org? Notice that the only difference is rn and m at the end of the domain name, and with some fonts it may be difficult to read especially if you have the domain getlatern in mind.

Why am I asking this? The domain roundrobin.getiantem.org is mentioned in the source (line 63).

The second option is found in the same code file on lines 33-43:

final File cfcerts = new File("cloudflare-certs");
final File[] certs = cfcerts.listFiles();
for (final File cert : certs) {
    LOG.info("Loading cert...{}", cert);
    try {
        DEFAULT_HOSTS_TO_CERTS.put(cert.getName(),
                Files.toString(cert, Charsets.UTF_8).trim());
    } catch (IOException e) {
        LOG.error("Could not load cert?", e);
    }
}

What it does is looking in a folder named cloudflare-certs and loading all hosts for the certificates in that folder. It may be that there is a certificate for roundrobin.getiantern.org. But if so you should be carefull in the git repository there is no such certificate.

As far as I could see with a quick view, Latern tries to take an host from a certificate and connects to roundrobin.getiantem.org if this fails.

If none of the two options apply you should perhaps really be worried as someone may try to manipulate your traffic. Or you may accidentally downloaded a malicious package with different servers.


What's a good fuzzing framework for fuzzing a local standalone application? I have been looking for guides and tutorials about how to fuzz and so far everything I have seen has been for web servers. If I wanted to fuzz something along the lines of calc.exe or a program that echoed back arguments passed to it. What framework should I use and how should I go about it. I am looking for help fuzzing an application which receives 0 network traffic and receives input via dialog boxes or command line arguments.

Updated answer: If you are using Windows, try the CERT Failure Observation Engine (FOE).  It is a fuzzing framework for Windows.  It has the ability to do file-based fuzzing, to click on dialog boxes, and other stuff.

Previous answer:
I suggest you start with zzuf.  It is the simplest, easiest to use command-line fuzzer for fuzzing standalone programs that read their input from files, stdin, or the command line.  It is extremely easy to use, and a good starting point.

You could also look at the CERT Basic Fuzzing Framework.

Then if you want to get more sophisticated you can look at other fuzzers (Spike, etc.), but that'll get you started.

If you want to fuzz programs that receive input via dialog boxes, sorry, I don't know what to recommend.


What perils are there in allowing user input of parts of an ODBC connect string? I'm developing an application that allows user to input hostnames, database names, usernames, and passwords for database access. The application will construct a ODBC connect string by filling in the placeholders. In C, that would translate to something like:

snprintf(connStr, sizeof(connStr),
         "DRIVER={%s};SERVER={%s};DATABASE={%s};UID={%s};PWD={%s}",
         myDriver, hostName, dbName, userName, passWord);

First thing I thought -- I need to excise the ";" character from everything. (And instruct users their passwords can't contain semicolons.)

Am I vulnerable to some kind of hostile input in this case? (Before you ask, yes, I will check for excessively large input. You can assume the connStr buffer will be enough. Either that or I'll use a higher level language with managed string types.)

To expand a little on one of @Sigtran's points, filtering on special deliminator characters is of course a key control when protecting against injection attacks, however it is also advisable to protect against the potential for creative encodings by utilising as restrictive as possible a white-list approach rather than simply replacing characters such as ; ' etc. Some regex such as this could perhaps be used (if you don't break legit functionality with only alpha/num/dashes of course):

/[^A-Za-z-_0-9]/g, ""


Why can't the client server speak directly to an identity provider like Facebook in OAauth 2.0 OAuth 2.0 used for authentication by Google makes sense given that the server and client both trust Google but not each other.

As I understand the authorization code is passed back to the server (in server side flow) as a URL parameter. To prevent security issues like the confused deputy, the authorization code is a one time use and the server can use the authorization code to obtain an access token and refresh token.

My question is why can't this process be simplified if Google (a trusted entity) directly sends the access token to the server (and not through the client)? This would eliminate the need for an authorization code. Google can be sure it's sending the access token to the right place because the client would have registered the redirect_uri with Google beforehand. It seems to be a general pattern that these protocols have the identity provider only send things to the server through the client.

While it would be possible, the process would be more complex and therefore a faulty implementation more likely.

For example it could work like this:

redirect to OAuth authentication endpoint, include a session identifier
user logs in
OAuth provider sends authentication token and session identifier to requesting server
user's session is linked with the authentication token
user is redirected to REDIRECT_URI

The session identifier is needed, because else an attacker with good timing could take over the authentication token. As you can see the session identifier is replacing the authentication token to identify the client in this example, which means that sending the token from server to server is just an additional step.

  the client would have registered the redirect_uri with Google beforehand

The registration would make the system less flexible, because currently only the calling service needs to decide which OAuth provider to trust. By using registrations the relation has to be established on two sides.


Can software keyboard add security to decrypting FDE'd Drive Having a LUKS Full Disk Encrypted Linux installation means that I need to input my decryption password before the Operating System can even start.

This will require me to use a hardware keyboard on the machine.

Now, if I have a portable installation of a Linux distro, can adding a software keyboard that shows up right with the decryption password prompt be more secure when using on foreign hardware, instead of using the untrusted hardware keyboard?

How would that add to security?

i.e. does LUKS password have to be stored anywhere, like say in RAM, as long as the OS is in use? And if I'm using my own Operating System as said earlier, can this password, if stored anywhere, be stolen by this foreign hardware?

Most “keyloggers” are in fact general spyware that detect many things other than key presses and are not at all fazed by on-screen keyboards. But such a keylogger would be software running in the operating system. It's possible to store malware in the computer's firmware, but that's a rather advanced threat; while malware in the firmware of many peripherals can access the RAM, figuring out what the software is doing from outside the OS is difficult. This being said, once someone has written the software, anyone can run it, so it's easy to spread software attacks.

So relying on an on-screen keyboard does reduce the risk of a keylogger attack when running an OS you control on hardware that you don't fully trust. It doesn't eliminate it, however. Using hardware that you don't trust also has the problem that you can't know that it's really executing your program. It would certainly be possible to write spyware that analyzes the OS on your drive a bit and invisibly injects itself into it.

If you really don't trust the hardware, don't use it, period.

If you kind-of trust the hardware, then you can reduce but not eliminate the risk by reducing the hardware attack surface. Eliminating the keyboard is an advantage in at least one situation: in a cybercafé-type environment, when you trust the administrator of the machines but you fear that someone will perform a discreet modification such as inserting a hardware keylogger into the keyboard. Still, once the software for the attack has been packaged, it's easy to insert a piece of hardware that's actually a USB hub with the attacker's hypervisor, causing your OS to run inside the attacker's hypervisor and thus exposed to the attacker's spyware. You're just requiring the attacker to be a bit more sophisticated.

Once again, the only way to have confidence in a computer is to trust its hardware. If you don't trust the hardware, you can't trust any software that runs on it.


Is locally reusing a password a bad practice? All my valuable data is in VeraCrypt volumes. The (very strong) keys of the volumes are stored in a single KeePass database, which uses a reasonably strong password.

I want to encrypt my backups too, in a way that enables me to restore them, even if I loose all the data on my computer (the VeraCrypt volumes and the KeePass file).

Is it risky to use the same password for the KeePass file and the backups encryption ? If someone cracks my KeePass database, he gets the key for the VeraCrypt volumes (and my data) ; if someone cracks my backups' encryption, he gets my data too.

How could reusing a password in this case lower the security ?

The point about not reusing passwords is damage containment. You do not want a breach in one system revealing a password that grants access to other data and systems that would otherwise have remained secure.

If the two usages ultimately protect the same data, then it makes sense to use the same password. Your case is a bit different: the two usages are "cascaded". By encrypting your backups, you are applying an extra encryption layer over that which is already provided by KeePass and VeraCrypt. If your master password is strong, that extra encryption layer is redundant. You could make unencrypted backups.

Arguably, you should make unencrypted backups, in case the encryption system for the backups happens to be weaker than the one used by KeePass. When doing password-based encryption, the password must be processed with a proper password-based key derivation function (see this); KeePass makes an effort and the iteration count can be configured. If the encryption system is not as robust as KeePass in that respect, then it may help the attacker: the attacker will run his dictionary attack on the backup, and once he found the password, he can then apply it to open KeePass and unlock the VeraCrypt modules.

Summary: if you can make sure that the backup encryption system processes the password in a way which is at least as resilient as KeePass to dictionary attacks, then using the same password is harmless. Otherwise, it can be harmful and you should abstain; i.e. encrypt with another, independent password, or don't encrypt backups at all.


Secure automatic authentication to samba share I need to pull some data from network storage to a publicly available laptop that is running Linux. The network storage used to be provided via a server that could be connected to via ssh, but it has now been switched to a server that only provides access via samba. I used to connect from the laptop to the server with SSH keys and I sand boxed the key on the server to only run rsync to make it more difficult for the compromised laptop (it is publicly available after all) to limit the damage (or at least make it more difficult) to damage/compromise the server. It probably would have been better to push from the server to the laptop but the IP address changes depending on where it is used and I frequently couldn't get through the firewall the laptop was behind (it is used in peoples homes).

I asked IS how I should implement the data sync on the new system. There response was to store my password in plain text on the publicly available laptop and use that to mount the samba share. There comment to me was:

  I would suggest that storing a plain text password on your machine is no more "dangerous" than storing both of your public/private SSH keys on the same disk. Anyone who "roots" your machine can log keystrokes to learn passwords in either case.

I am pretty sure this advice is just wrong. I work at a university and we use a single log on active directory set up. With the SSH key someone can get access to a single service on a single server, while my password will give them access to "everything". Is there a way to securely mount a samba share without making my password available? For example, maybe setting up a (virtual) server that acts as a go between.

A second, and decidedly softer, question is, is the advice about plain text passwords so bad I should report the IS person, who is on the file storage team, to someone on the IS security team?

They're quite correct. If you store credentials on the laptop and the bad guy compromises it, the bad guy gets those credentials, end of story.

Counter-intuitive as it sounds, plain text is the correct way to store credentials in this set-up. It is pointless to encrypt them, because the laptop has to be able to decrypt them, so you have to put the decryption key on the laptop and you're back where you started, except you've added pointless complexity. (Interestingly, this is why DRM systems invariably turn out to be snake oil. Doesn't matter how you encrypt a movie, you have to give the end user the key to decrypt it before they can watch it.)

Where you've got a problem with the new set-up is that you're proposing to use your personal credentials to access the storage. You need to have a separate set of credentials, just for this purpose, that are locked down so that they can only access the specific share.


How to design a single-request, non-CA-based custom server-to-server authentication method? We have a series of services exposed as web servers. Potentially, every web app could contact and be contacted by any other one. I want to secure the communications between the applications, which means ensuring that both parties are who they say they are. I want my applications to only be allowed to communicate between themselves: this is not a matter of frontend-backend communication, and no app is in the hands of customers or external users.
That said, I also want to avoid the complexity of setting up a CA, generating TLS certificates and so on. We want the security checks to be as streamlined as possible, and possibly easy-maintenance and easy to migrate. Also, we are going to add new applications, and the current method (which I'll describe in a second) is already too cumbersome according to my manager.
I want to understand what the risks are in a scenario in which we implement a quasi-PKI infrastructure, which means I would use industry-recognized encryption algorithms (no custom encryption at any stage) but in a custom workflow.
Let's consider a single connection between a provider and a consumer of the service, and for simplicity's sake let's call them server and client.
All connections are HTTPS-based, except maybe when developing. This should take care of MitM attacks and of server authentication.
What we currently have is as follows. The server has a registry of authorized client applications, and each of them has a GUID and a secret key. When a client contacts the server, it sends its GUID in a custom HTTP header; the server recognizes the GUID from the registry and challenges the client to an authentication challenge (essentially HMAC): a request is sent to the URL stored in the registry, containing a random string, the client responds with the result of encrypting the random string using its secret key (for example with RSA-256). If the server receives the expected response, then the client is authenticated and the response is served.
The secret key is never sent over the network, which keeps it safe, and the challenge string changes every time, which protects against replay attacks.
The weakness is that, if a third party learnt the client's application GUID, they could make requests to the server and the server would send the challenge to the real application, without noticing. This can be fixed either by checking the provenience of the request (but I think that can be spoofed) or by making the client record its requests, so that it rejects authentication challenges that do not match a request it made.
However, this system requires us to define the client application in the registry, pair the access information in the registry and in the client's configuration, and implement the challenge handler in the client. Also, access information may be different between development, staging and production (I'd say it's best it be different). If we factor in 15-20 applications (and growing), each managing its registry as a server, each potentially being a client of several others, you can see this becomes an important setup overhead.
What I'm aiming for is to remove the authentication challenge. Removing the authentication challenge speeds up the process and eliminates the need for a challenge handler. A server would still keep a registry of authorized clients, with a secret key for each client.
Instead of HMAC, the challenge would be time-based, even though I don't like having an interval during which the result would stay the same (which exposes to replay attacks for a short time). However, I can't figure another way to have an always-changing authentication code without the server offering a seed.
So, to sum up, the question is two-fold:

is it any less secure to use industry-standard encryption algorithms in a custom workflow (assuming the custom workflow doesn't introduce security holes itself)?
how to perform the authentication without the authentication challenge, without also exposing to replay attacks?

Here's a few thoughts and suggestions.
(1)

All connections are HTTPS-based, except maybe when developing. This should take care of MitM attacks and of server authentication.

At this point you need to have a PKI in place to ensure integrity of connections;
(2)

What we currently have is as follows. (...) The secret key is never sent over the network, which keeps it safe, and the challenge string changes every time, which protects against replay attacks.

Your methodology doesn't look bad at face value, however the major issue is key distribution. How do you handle/store/distribute these secret keys?
(3)

The weakness is that, if a third party learnt the client's application GUID, they could make requests to the server and the server would send the challenge to the real application, without noticing. This can be fixed either by checking the provenience of the request (but I think that can be spoofed) or by making the client record its requests, so that it rejects authentication challenges that do not match a request it made.

I'm not sure how you can verify the provenience of this value. Also sending the challenge code to a spoofed client shouldn't be a security issue in your implementation. As in, this should not be of use for an attacker, as it would if it were netntlm.
(4)

What I'm aiming for is to remove the authentication challenge. Removing the authentication challenge speeds up the process and eliminates the need for a challenge handler. A server would still keep a registry of authorized clients, with a secret key for each client.

Sounds like adding a weakness and complexity.

is it any less secure to use industry-standard encryption algorithms in a custom workflow (assuming the custom workflow doesn't introduce security holes itself)?

You are asking a question with a caveat where the caveat is the answer. If you design and implement a secure system, then the system will be secure. The matter is, however, can you be confident of this?

how to perform the authentication without the authentication challenge, without also exposing to replay attacks?

This is a long winded response. A secure authentication protocol needs resilience against brute forcing, replay attacks and in some ways impersonation of authenticated peers. It is up to you to work out how to do this.
I understand this is the answer you want to avoid. But using PKI with client side certificates addresses most of these points, certainly (1) (2) and (3), and you might be able to forego (4).


Way to secure store personal data This is not for business or corporations, but for personal situations.

I rely on gsuite, google drive, google docs, etc.. not that too much 'heavily', but I use it to send most of my business emails, personal and team docs sharing.

However, there some sensitive infos(like personal info, security keys, really private info that I want nobody to see), and I don't trust google that it will store it secure.

I thought about encrypting it and saving it locally, or encryting it and saving it in cloud.

What is the best way to storage personal and sensitive files?

Encrypting and saving like on a hardware encrypted usb seems like the best, but there is always the risk of losing it.

Is encrypting and saving in the cloud more secure?

Tell me your ways you store your most important and private data.

It depends on the nature of the data if you are storing. Ultimately it is a security/convenience trade of.

Using strong encryption before you save it to the cloud is very secure as long as your key is strong. The draw back is you lose many features of GSuite as you are effectively now just storing binary blobs.

You also have the problem of sharing yours keys with who ever wants to view the data.

Another option may be to use GSuite for all non sensitive data and roll your own solution like own cloud for sensitive stuff. This does mean you need to set up and secure you own service and server but it gives you total control.


What's wrong with a website including a password in a confirmation email? I recently registered for a website and received an email that said "Thanks for registering, here's the username and password you used to sign up".

The webmaster assures me that plaintext passwords are not stored in the database, but even if the plaintext is only kept long enough to send the email, that's still a bad sign, right?

Are there other risks besides "email is insecure so you shouldn't email passwords"?

When a webmaster sends you a plaintext password, that usually implies that they do not hash passwords, which is a bad sign. But when the webmaster assured you that they do so right after they sent the confirmation mail, I would assume good faith and assume that they say the truth. Those few microseconds more during which the system has access to your plaintext password is unlikely to be a realistic additional security risk. But sending cleartext passwords in email is still a dangerous anti-pattern which should be avoided:

Emails are generally transferred and stored unencrypted. That means a password could get compromised by your mail provider or any servers in-between.
It is vulnerable to accidental (or intentional) shoulder-surfing. The reason why all password-inputs obscure the characters entered is that you can register an account and log into it while you have another person with you. But when the password appears in clear-text in the confirmation-mail, that person will see it (you have no reason to believe that the mail will contain any sensitive info except the usual "welcome to yadda yadda click here to activate account yadda yadda", so you would have no reason to tell them to look away when you open it).
It compromises your account when someone gets a peek at your email. For example when you accessed it from a public computer and didn't log out or leave your desk without locking your desktop while you have company. One could argue that your email account is your master-key to your online identity because it allows you to reset or request (unhashed password! bad!) the password of almost any other account you have, so you should protect it at any cost. But requesting passwords through email would leave traces and tell you how and when your password was obtained. Just scrolling through your mail while you aren't looking would not.


Why use a USB WiFi adapter with Aircrack-ng? What are the limitations we have when we are performing aircrack-ng pen testing using laptop's built-in WiFi adapter? Many pen testers are using USB WiFi dongles for this purpose and I wonder why.

What are the best available WiFi USB adapters for this purpose? I have purchased the TP LINK-WN722 adapter but it didn't get installed properly in Windows 10.
I am using Kali inside my Win 10 box as a VM. Can I use my WiFi USB adapter as a WiFi interface in my Kali VM ?

The main reason is because you need the adapter to support monitoring mode.

This mode allows the adapter to not only sniff all packets coming from the AP to the clients but also from sniff the data from the clients to the AP.

  Can I use my WiFi USB adapter as a WiFi interface in my Kali VM ?

You can use it to get WiFi access but it will not work with aircrack-ng.

Notice: There are some computers that have the monitoring option built in the default adapter.

You can read more about it in this answer.


Prove that you deleted the file Is it possible to prove a date that you Deleted a file through the recycle bin? I delete a folder of pictures 2 months ago and somebody is asking to prove that I did it.

Respond by asking them to prove that they brushed their teeth on the night of March 14th 2013.

From a technical perspective, this isn't possible unless you've explicitly set up directory auditing to log when files are deleted. Since I almost guarantee that you haven't done this: no, there is pretty much no way you can prove such a thing. Even with auditing, you may well have copied the data to a secondary place via other channels - even something as low-tech as a print screen or taking a photo of your monitor.


Should I use more than 2048 bits in my SSH-2 RSA Key? I've been asked to generate a public key with PuTTY key generator. The default is 2048 bits, should I add additional bits to the generated key? Or is it unnecessary?

There seems to be a convention of using power of 2 keysizes, it's not strictly required but it seems to be the norm.

The best known way to attack RSA is to factor the modulus to get p and q, once p and q are known it's trivial to reconstruct the rest of the private key. How difficult that factorisation is depends on the size of the modulus.

512 has been factored by hobbyists.
768 bit has been factored by researchers in a public challange.
1024 can probablly be factored now by well-funded orgnisations but noone has publically admitted doing it.
2048 is generally thought to be secure for the time being.
4096 is what the more paranoid go for, especially for long lived keys.

Personally I use 4096 for all newly generated keys.


How do I ensure a local Minecraft server (with admin wrapper) is inaccessible to the outside? I'm running a Minecraft server on my local network for myself and my roommates. I would like to simplify some of the admin tasks by using an admin wrapper.

Unlike most of the questions, tutorials, and other things I could find, I want to make sure the server is not accessible outside my local network.

If I were to run Minecraft using an admin wrapper, what tools/techniques could I use to verify that the server is not accessible outside the network beyond trying to connect from a client outside the network?

Other potentially relevant information:

Port-forwarding and related are turned off in the router's admin panel.
I am running the latest JRE.
I am using the latest official server JAR from Minecraft.net
The "server" is an older Win10 Pro machine re-purposed for this and running Kodi on the main TV, and has all the patches/updates.

Side note: I'm planning on using Minecraft Server Dashboard, though for those that use other admin wrappers I'd appreciate more general purpose answers.

If the server is running on a LAN address per RFC 1918 and you are not using NAT RFC 2663, this shouldn't even be an issue. NAT is what does the port forwarding.

To increase the security you can simply block all externally incoming connections.

If you would like to verify, you can use nmap to scan from the public network.


when to use encoding over hashing? If encoding is used for integrity someone can tamper it across the network because it is based on some publicly known scheme.

When do you use encoding and when do you use hashing for preserving the integrity?

my understanding is encoding is used to preserve integrity across heterogeneous system when confidentiality does not matter.
Why do people still use bases64 (Basic authentication)to send the username/password even though authentication information is confidential ?

Encoding is not a mean to ensure integrity. Encoding is here for representation. You encode a string into base64 because it is easier/safer to use the symbols in the internet environment, e.g. URLs where some characters are difficult to convey and interpret correctly afterwards. UTF-8 is used because we need a wide space to represent foreign language characters and other new symbols.

Hashing some content is a mean to verify integrity. If the content C has has D = H(C), you can by transmitting C and D verify that the received message C' verifies D' = H(C') = D = H(C). If it does not, then the message has lost integrity.


undocumented options for -inform / -outform for rsa / OpenSSL? According to http://pumka.net/2009/12/19/reading-writing-and-converting-rsa-keys-in-pem-der-publickeyblob-and-privatekeyblob-formats/ MSPRIVATEKEYBLOB and MSPUBLICKEYBLOB are acceptable parameters for -outform / -inform for rsa.

The official OpenSSL docs, however, make no mention of these parameters:

https://www.openssl.org/docs/man1.0.1/apps/rsa.html

This kinda makes me wonder..  what other undocumented parameters can -outform and -inform?

Unfortunately proper documentation is not one of the strength of OpenSSL (and it shares this weakness with many other software). The parsing of the options is done in apps/opt.c function opt_format. Not all of the possible options are implemented for rsa but looking at apps/rsa.c I see mention of PEM, DER, MSBLOB and PVK.