How to secure SSH such that multiple users can log in to one account? Consider a generic up-to-date Linux distro hosting a web server. I need three humans to occasionally SSH into the same user account to perform some action that can only be done by that particular user account.

The 'easy way' to do this would be to simply allow SSH by password and to give the username/password combo to all three humans. However, I prefer to disable password logins and to require RSA keys. Is there a way to configure SSH to accept the RSA keys from three different users? I don't want to distribute the same keys to those users as they do log into other servers as well.

Yes, you can have multiple keys that are allowed to log into an account. This is a common configuration among users who have multiple trusted machines and keep a separate private key on each one.

This is also a reasonable configuration for a service account that is only meant to access one application. In this situation it is usually combined with a restricted or special-purpose login shell that only allows access to that specific application. For example, gitosis is a gateway to the Git version control system, and handles user authentication by itself, sticking to a joint git account at the unix level. If multiple people can run arbitrary command through this account, you should really give them different unix accounts.

Get the users to send you a public key, and concatenate the public keys together to form the ~/.ssh/authorized_keys file, or equivalently append each public key starting from an empty file.

You can put restrictions on the keys themselves in the authorized_keys file. For example, ssh-rsa AAAA… alice@example.com declares a key with no restrictions, whereas a user who logs in with the following key is only allowed to log in from a specific IP subnet, may not forward ports, and may only run a specific command:

command="/usr/local/bin/restricted-app",from="192.0.2.0/24",no-agent-forwarding,no-port-forwarding,no-x11-forwarding ssh-rsa AAAA… bob@example.com

If you rely on command restrictions, be careful that the command doesn't allow any indirect way to obtain a shell or to edit files in the .ssh directory or any other sensitive location. You may make the account's home directory, the ~/.ssh directory and its contents owned by root and accessible for reading by the user, which would prevent privilege escalation in case the restricted application has a file overwrite vulnerability but no shell escape vulnerability.

Set LogLevel VERBOSE (one step up from the default level INFO) in the server configuration (sshd_config) to log which key was used to log into the account each time.


Getting reliable checksums Update: A version of transmission that contains malware has been distributed very recently. Quoting this ars technica article:

  It appears that somehow the Transmission website may have been compromised as it was served via HTTP rather than the primary HTTPS Transmission

Original question

I want to download the transmission bittorrent application for mac, from here. There is a sha1 checksum on that page if you mouseover the link to the .dmg file link, but as the page is not served over https, I cannot tell if this is authentic. My main concern is a man in the middle attack (to corrupt the data). The fact that https is not used seems silly, because another page on their domain can establish a secure connection with a signed certificate.

I wonder if I am missing something, though this Q&A seems to agree with me. I would also like to know if there is a method to still find out if a file is authentic in a scenario like this, or in my particular case.

Getting reliable checksums

The checksum itself is reliable for what it should be used. But your expectation is wrong.

The purpose of the given hash if not to check against attacks but for inadvertent file corruption (bit flips, missing ends...). It can not be used for authenticity since both the hash and the file are served by the same site and a hacker could simply replace both when hacking the site. For checking authenticity you would need a digital signature signed by the author and not a simple hash.


What is the difference between Anti - APT (Advanced Persistent Threat) and ATP (Advanced Threat Protection)? Like the question says, is it the naming difference only or are they entirely different?

Advanced Persistent Threats (APT) describes actual threats.  Depending on who you talk to and the context these are sophisticated and targeted attacks by advanced actors with lots of money like states or criminal organisations  - or simply anything which is more complex than what basic firewalls and antivirus products could detect (like in "it wasn't our fault since it was an APT attack" when you did not care enough to secure the network). Thus "Anti-APT" likely refers to defending against these specific advanced threats.

Advanced Threat Protection (ATP) describes protections against threats.
It is a marketing term like "Next Generation firewall" which should highlight the ability of an analysis system to be somehow better (i.e. "advanced") in detecting and preventing threats than "traditional" systems. Expectations are that it will not detect just the "average" attacks but "more". What exactly this "more" and "better" consists of is not clearly defined but it often involves some more buzzwords like using artificial intelligence to detect threats or cloud based threat intelligence.

The similarity in the abbreviation between APT und ATP might be accidental but the association it creates in the consumer is probably welcome by the marketing department of the vendor. But only few vendors explicitly claim that ATP is actually able to detect APT. But it is likely that if you want to actually detect ATP (i.e. "Anti-APT") that "traditional" network security like simple stateful firewalls and antivirus is not sufficient. Solutions claiming to be ATP are probably more useful but might not be sufficient too - depending on what these solutions actually do (instead of how they are marketed) and how you interpret the term APT for yourself.


Is certificate signature encoded to ASN.1 format? I'm working on a diagram to describe the process of issuing digital certificates, with the help of answers on my question here and some other research:

I just read in the IETF that:

The signatureValue field contains a digital signature computed upon
the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
tbsCertificate is used as the input to the signature function. This
signature value is encoded as a BIT STRING and included in the
signature field.

Because I'm somehow familiar with the process of "signing > encoding to ASN.1 format > encoding to base64" from the CSR step, it looks different here, so instead of this order it's: "encoding to ASN.1 format > signing > encoding to base64??"
but it doesn't make sense to me; shouldn't the three main fields of a certificate (tbsCertificate, signatureAlgorithm, signatureValue) encoded to ASN.1 format before encoding to Base64?
so the ASN.1 is used twice by the CA in issuing certificates?
So this is the correct flow: https://i.stack.imgur.com/bJd0o.png ?

also, I'd like to know how accurate is the diagram describing the digital certificate issuing process?

TLDR: Yes, everything in a CSR or a certificate is using ASN.1 notation, ASN.1 is a description of the data types.
There are a few things to unpack here but let's start with some definitions:
Data formats used in PKI:
ASN.1:
This is a syntax notation, or how to represent various data types (integer, string, bytes, etc...).
A programming language equivalent would be a data structure with defined types. eg:
struct Certificate {
  tbsCertificate       TBSCertificateType      // Another struct
  signatureAlgorithm   SignatureAlgorithmType  // Another struct
  signatureValue       []byte                  // An array of bytes
}

DER:
DER encoding is a way of serializing ASN.1 data. The output is an array of bytes that can be stored in a file, sent over the network, or as input to a signature algorithm.
PEM:
PEM is the base64 representation of DER data plus a header and footer. This results in ASCII data that can be easily sent over ASCII-only channels (eg: email doesn't do binary, it needs to be encoded).
I'm going to ignore PEM encoding because it's not strictly necessary here, it is only used to encapsulate binary data to pass around between parties.
How signatures work:
Signature algorithms in PKI have three parameters

the signature algorithm (and optional parameters), eg: PKCS #1 SHA-256 With RSA Encryption
the key: the private key of the signer
the input: raw bytes to sign

There is one output: the signature, which is a bit string.
note: under ASN.1, an octet string and a bit string are two different types. They are both binary data but the bit string can be any length whereas an octet string length in bits must be a multiple of 8.
Signing the input:
No matter what the input is (certificationRequestInfo for CSR, or tbsCertificate for Certificate), it must first be encoded into plain binary.
We need a standard for what that binary is. Luckily, we have one.

For a CSR, RFC 2986 tells us:: The value of the certificationRequestInfo component is DER encoded, yielding an octet string
For a Certificate, RFC 5280 tells us: The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate.

In both cases, the relevant data in ASN.1 format must be DER encoded, then fed into the signature algorithm. The output (the signature) is a bit string.
What happens to the output:
The output of the signature algorithm is stored in the signatureValue of field of the certificate with type bit string. Again, this is in ASN.1 notation.
Once all certificate fields have been set properly, the certificate is DER encoded.
If needed, the DER data is base64 encoded to yield the PEM data format. But this is not required.
A word of warning:
I think you're trying to accomplish too much. I would start with the basic components of the CSR/Certificate flow and worry about the finer details (such as data encoding) later.
Instead of a diagram that contains all the possible details, start at a high level, get a good handle on the process, then dig into the gritty details if you must.


Why is malwarebytes.org's SSL certificate from someone else? I tried downloading and updating malwarebytes from https://www.malwarebytes.org but their certificate seems to be incorrect. This is the warning:

  This is probably not the site you are looking for! You attempted to
  reach www.malwarebytes.org, but instead you actually reached a server
  identifying itself as gp1.wac.edgecastcdn.net. This may be caused by a
  misconfiguration on the server or by something more serious. An
  attacker on your network could be trying to get you to visit a fake
  (and potentially harmful) version of www.malwarebytes.org. You should
  not proceed, especially if you have never seen this warning before for
  this site.

Does anyone have an idea on this? Any history? Misconfiguration?

EDIT: If this is misconfiguration, aren't they open to MITM for their database updates? Either they aren't serving it over SSL or they are ignoring SSL errors during connection setup (inside their App)

It looks like a misconfiguration. www.malwarebytes.org is, at the DNS level, an alias for wac.1D00.edgecastcdn.net, which belongs to EdgeCast, a company that specializes in content hosting and delivery. The certificate is theirs. My guess is that Malwarebytes is a customer of EdgeCast, and someone at EdgeCast made a configuration mistake. This will probably be promptly fixed, at least if the people at Malwarebytes are made aware of the issue.

As for database updates, they might not use the same address and server as their Web site, as you see it. They may also use "direct trust": the client already knows the exact server public key, and simply ignores the certificate as sent by the server. Direct trust is not very flexible, but it is secure.


is it possible to evil twin a WPA 2 Wifi using one of EAP methods? the same as fluxion  but without the captive portal just like this video
Stealing 802.1x Credentials with Rogue AP & RADIUS server
he was able to get the username and the password of an EAP wifi without cracking just by launching  an rouge AP
if it's possible which inner type would it be !

This is possible whenever there's an authentication server involved and the client doesn't validate the authentication server's certificate (or the user manually accepts such a certificate).

However, this is not possible on pre-shared key WPA2-PSK networks, because in IEEE 802.11i four-way handshake both the AP and the client prove to each other knowing the key without disclosing it. The username and the password are not revealed during the WPA2 authentication, but during the 802.1x authentication.

Because WPA2-PSK has other problems (everyone who knows the PSK is able to decrypt traffic of all other users), WPA2-Enterprise with validation of the authentication server's certificate is recommended.


How to Encrypt Credit Card number for storing it in sql server database according to PCI DSS Requirement? According to PCI-DSS 3.4 Requirement:

Render PAN unreadable anywhere it is stored by using the below methods:

One-way hash
Truncation
Index tokens and pads
Strong cryptography with associated key-management processes and procedures

My question based on above requirement is:

So if need to encrypt the credit card details which one would be a better process?
If we are going to encrypt credit card number for storage, then we should have Data Encryption Key(DEK) for encrypting the credit card number.
So do we need to generate unique encryption key for encrypting each credit card number? or To generate unique encryption key for each user(each user may have two or more CC)? or To generate a single encryption key for encrypting all the credit card numbers?
Also provide any links regarding one time pads or please explain about it?

The first two options (one-way hash, truncation) don't leave you with a working number, so if you expect to use the card again in the future these won't work for you.  At the other end of the spectrum, strong cryptography will give you that ability, but it's harder, and involves setting up processes (such as key rotation and management).
Because of the key rotation requirements, solutions are usually geared around use of one key throughout its cryptoperiod, rather than pairing keys with users or cards.

You would generally use one DEK (call it DK1) for encryption of multiple cards, for the duration of the DEK's OUP (Originator Usage Period).  Let's say the OUP is 3 months.  After 3 months, you would generate a new DEK (DK2), and all new card encryptions will start using that number instead.  However, for all those cards you encrypted in the first three months, you may need to decrypt them, right?  So DK1 may continue to be used for decryption of those existing encrypted cards throughout its RUP (Recipient Usage Period) which is longer (let's say 12 months).

So at any given time, you'll have at least one DEK in use as an OUP and an RUP, and 3 other DEKs used solely as RUPs.  And as the oldest DEK nears the end of it's RUP, you need to re-encrypt all its cards with a newer DEK.

That's what PCI means by "with associated key-management processes and procedures".  The terminology above is from NIST 800-57, which PCI cites as an example of the sort of key management guidelines they look for in DSS 3.6.4.

You should also be protecting this stable of DEKs with a KEK (Key Encrypting Key).
Nope.  <OPINION>One-time pads are not a realistic solution; while cryptographically secure, they're not manageable on any usable scale.  Imagine what I said for #2, but with one DEK per card!</OPINION>


Accessing SQL database from Java Android app. How do I store the SQL database details so they are safe? So I am developing a Java app which is going to be free and would preferably not require a sign up process. I cannot seem to think of an idea to store the log in details safely.

I have thought of salting and hashing the password but it means that I won't be able to recover the password to use it for the database.
I have also thought of using encryption but that would mean that I would be storing the encryption key in the app which also doesn't seem safe.

What are the best practices for this issue? The data doesn't consist of any personal data but it would be nice to know how to protect the database.

Since I assume your database will be accessible to the Internet, definitely use an encrypted connection between your app and the database. MySQL has documentation on this here.

One approach is to wrap the database with a web service. This lets you store the database password in the web service, instead of the app. This also gives you more power in deciding what queries are run against the database.

Another approach is to dynamically generate a user in the database for the app when the app is installed. This will allow you to make sure that the user's database credentials are unique, so that any action done against the database can be traced to a single installation of the app.

However, this leads me to a bit of a tangent:

Consider role-based access control for your app.

If your app only reads data from the database, and if you are concerned with the integrity of data in your database, consider creating two user roles in your database. One user role will be able to create, modify, or delete data: this user is for your use as administrator of the app. The other user role can only read data: this is the role of user your app will use to log into the database.

MySQL has capabilities to perform this sort of role-based access control, albeit awkwardly - check out the MySQL documentation to learn more.


Transparently authenticating users or devices on mobile devices I have an interest in using EAP-TLS to authenticate both users and devices separately on mobile devices (phones, iPods, tablets, etc.).

My issue is how to delineate between user authentication and device authentication, since there is only one "account" on the devices, and multiple users per device.  We are able to make the assumption that the user of a device is a particular role, but that doesn't help us very much from an auditing perspective.

EAP-PEAP was a thought, but I want to keep user interaction to a minimum.

I was hoping that someone could point me to a technology that solves the problem of authenticating users on single-account mobile devices as transparently as possible.  Potentially some sort of biometrics (facial recognition that frontends EAP-TLS)?

EAP-TLS is "just" plain SSL/TLS forced into the EAP format. EAP is an "authentication framework": a generic protocol for exchanging messages between two parties, in a question-response dialogue (the parties are usually designated as "client" and "server", whether this maps to the corresponding network concepts or not). TLS is nominally performed over a bidirectional channel for arbitrary bytes, both parties being able to talk simultaneously; however, the TLS "handshake", in which the tricky crypto occurs, is synchronous: at any point, only one party (client or server) talks, and both know who is supposed to speak next. Therefore, it is possible to split the TLS records into big packets which will be wrapped into EAP messages; that's exactly what EAP-TLS is about.

EAP-TLS achieves client authentication "by itself" when TLS certificate-based client authentication is employed: the client owns an asymmetric private key, and the corresponding public key is wrapped in an X.509 certificate, which the client shows to the server when the server asks for it. This kind of authentication works only when the client indeed contains a private key and can use it, so that's for devices, not humans (even if considering smart cards, the authentication will convince the server that the smart card is at the other end, and the server merely infers the involvement of the human owner of the smart card, under the assumption that the smart card would not do anything without the PIN code that only the human owner knows -- but the server does not see that PIN code and cannot be sure that it even exists at all).

So no biometrics for plain EAP-TLS. However, there is another mode of EAP-TLS in which no client certificate is requested; but then, EAP-TLS is just a transport mechanism, for another authentication mechanism which will be played within the TLS tunnel. In that case, EAP-TLS is just an additional network layer (a good one, since it allows for safely sending plaintext passwords, but a layer nonetheless). Note that PEAP is just the reverse: EAP inside a TLS tunnel. EAP-TLS-for-transport and PEAP are functionally similar, but correspond to distinct contexts (PEAP is there to get EAP messages when the context is a bidirectional tunnel for bytes; EAP-TLS is there to get a bidirectional tunnel for bytes when the context is a transport mechanism for EAP messages).

Speaking of biometrics, one must remember that this is about measuring things on a human body, not about secret data. Your fingerprints are not secret; you leave them just about everywhere and they can be recovered by low-tech attackers. The value in fingerprints is that nobody can have the same as yours attached to their fingers. This provides authentication, but only insofar as there is some mechanism which ensures that a real finger is placed on a real scanner. Otherwise, an attacker could just send a synthetic data packet over the network, claiming to be from a scanner, and containing a picture of your finger. The same applies to face recognition. Simply put, biometrics work well only in the presence of an armed guard (the guard does not perform the authentication, but makes sure that only true biological fingers/faces/eyes are put in front of the detector).

So what does this mean for your situation ? Mostly that EAP-TLS, PEAP... are not the relevant point. What you want is to authenticate both human users and machines, and you will need two distinct authentication methods.

For humans, you will need to map on that which works on humans, mostly passwords and biometrics. As explained above, biometrics really work only in restrictive contexts (many people use them in other contexts, but all they get is a warm feeling of security, not actual security). So this brings us back to passwords. Or you could say that humans are actually devices, with the smart card arrangement, or something similar (like a car key with the "unlock" button): the authentication is really for a device, that is assumed to be under exclusive control of a specific human user.

For machines, authentication can use a "machine password" (it is like a normal password, except that a machine will have no problem remembering a 25-letter sequence of random characters, so that's substantially easier than passwords for humans). Or it can rely on asymmetric cryptography (private key and certificate, see above).

Either way, you will probably want to know sufficiently early whether the client is a human or a device, so that the appropriate authentication mechanism may be used. And there is something just for that in EAP: the initial message from the server will be of type Identity, and can be described as the question: "halt ! who goes there ?". It is then up to you to give "names" to both human users and devices, so that the server can quickly determine whether the client is a human or a device, e.g. based on the name format. The server, in EAP, is free to select the actual authentication method after having seen the Identity Response from the client.


Why is this version of OpenSSL (1.0.1e) not vulnerable to Heartbleed? I recently ran into a requirement that needed a web server set up with SSL, to show that its possible to extract the private key from a server with a vulnerable version of OpenSSL (Heartbleed). Hence, I downloaded a version of Debian I knew that shipped with the vulnerable version of OpenSSL from here.

However after configuring it, it wasn't leaking anything (as reported by Metasploit).

Below is the output from openssl version -a:

OpenSSL 1.0.1e 11 Feb 2013
built on: Sat Jun 13 10:26:40 UTC 2015
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

From what I know, versions between 1.0.1 through to 1.0.1f are vulnerable. I can see that it was built on a later date. My questions are:

Which compile option made it safe against Heartbleed? I don't see DOPENSSL_NO_HEARTBEATS flag option in the output above.
Where can I get a Debian version (7 or later) which actually ships with the vulnerable version of OpenSSL needed to demo Heartbleed.

As mentioned by @void_in, they backported the patch. Check your package version like so:

dpkg -l openssl

From 1.0.1e-2+deb7u5, the security patch has been included.:

  openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high

  Non-maintainer upload by the Security Team.
  Add
  CVE-2014-0160.patch patch.
  CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure.
  A missing bounds check in the handling of the TLS heartbeat extension
  can be used to reveal up to 64k of memory to a connected client or
  server.

The files relating to 1.0.1e-2+deb7u4 can be found here, and you should be able to revert back to a previous version of a package by adding entries in the /etc/apt/preferences file.


What are some examples of a block cipher's versatility over a stream cipher? I understand that a block cipher can be made to act like a stream cipher at the cost of "losing versatility" of the block cipher for the sake of performance.  I don't understand what I'd be losing.

For example, AES GCM mode is a block cipher that acts as a stream cipher, however I get

Integrity (the message can't be modified without me knowing)
Streaming (the whole object doesn't have to be loaded into RAM for encryption/decryption.)
other features ...

Question

What would I be losing when AES is in "block" mode vs "stream" mode?... (this question isn't supposed to be AES specific, but it's what I'm familiar with)
What are some real world examples of a block cipher being used where a stream cipher is less than ideal?

A block cipher is a key-indexed pseudo-random permutation on the space of blocks: for a given key K, AES maps 128-bit blocks to 128-bit blocks, such that no two distinct input block values are mapped to the same output block value. Knowledge of K allows efficient computation of the inverse permutation as well.

A block cipher can be used as a building element for various process, including (but not limited to):

symmetric encryption of arbitrary long messages, using various mode of operation;
hash functions, e.g. with Merkle–Damgård or some other constructions;
MAC algorithms, with (for instance) CBC-MAC;
generation of unique, pseudo-random, verifiable identifiers (my encrypting successive values of a counter in a given range).

A stream cipher is a specialized algorithm which covers only the "symmetric encryption of arbitrarily long messages" use case. The hope is that by restricting ourselves to that single usage, we may design a more efficient algorithm. The eSTREAM competition resulted in a portfolio of seemingly secure stream ciphers which indeed happen to be faster than AES-based encryption on a number of architectures (e.g. on a 2.4 GHz Core2 x86 CPU, I can do AES at 160 MBytes/s, while the Sosemanuk stream cipher reaches 700 MBytes/s on the same hardware).

Note, though, that "symmetric encryption only" is restrictive: in many situations where symmetric encryption is desirable, one should also add integrity checks, i.e. some sort of MAC. Stream ciphers don't do MAC, while there are authenticated encryption modes which allow to turn a block cipher into both encryption and a MAC, with relatively little overhead when compared to raw encryption (by the way, there is an ongoing competition for new AE modes, which received no less than 57 submissions, so we should have in the future some even better AE modes).

It has also been pointed out that there are encryption contexts where random access is desirable (e.g. hard disk encryption), and you get that with a block cipher in CTR mode, but not necessarily with a dedicated stream cipher.

To sum up, you should consider using a stream cipher in a new protocol only if you have a performance issue to solve, and the problem at hand happens to be within the limited scope of stream ciphers. This does not happen often. An example is when you need gigabytes of pseudo-random bytes (basically, when I need random bytes in huge quantities, I use Sosemanuk initialized with a key and IV from /dev/urandom).


How can DH provide a known secret to two parties over an unencrypted connection without it being intercepted via MITM? Without using Private and Public keypairs, i do not understand how Diffie-Hellman is able to generate a secret key between two parties on the internet without passing something between that could be sniffed. There is a term for this that comes from Generals sending messages through hostile territory. I do not understand the math or logic behind DH and just can not see how it is possible.  Someday i will spend another week or two going over the math, but until i can verify, i cannot trust.  Further why use it when public private key pairs can be used to establish a shared session key with much less risk?

On the other hand, the uneducated masses historically sling pitchforks into progress.  Explain it to me like i am 5, how can DH provide a known secret to two parties over an unencrypted connection without it being intercepted via MITM?

Changed title from: "When a public-private keypair is already in place, why is Diffie-Hellman used at all?"

Here's Diffie-Hellman for a student - a five year old does not understand logarithms ;-)

DH uses two ideas:

exponentation is fast (2 to the power 3 equals 8) but the reverse process (an exact logarithm) is very time-consuming to do. In reality we take large numbers, but for the sake of explanation small numbers here.
exponentation is commutative, i.e. 2 to the power 3 to the power 4 is the same as 2 to the power 4 to the power 3

Say that we want to communicate. We agree upon the base number A that we're going to raise to a certain power. And that doesn't have to be private. We just send A to each other.

Now I choose a big random number for my B. You choose, separately, your own big random number, which we'll call your B. And we both raise this agreed-upon number to that big power. Now, we send that intermediate result to each other. And now I take your intermediate result and raise that to my big power. You take my intermediate result and raise that to your big power. We both end up with the same answer.

A MITM sees A and both of our intermediate results going by, but he can't do the reverse process in reasonable time.

He can't figure out what our powers were that we made up. So we end up being able to choose random numbers, use those to raise a common value to that power, exchange those results, do it again, and we both end up with exactly the same value, which we can then use as a key.

In reality, there are some other requirements to A other than being big (e.g. it has to be prime).

Credit: Answer based on the transcipt of Security Now Episode 34


Should Encrypted Data Not be Obfuscated TLDR; Are there precedents saying not to obfuscate encrypted data?

If I'm using some standard, and a client is using the same standard, the only thing we pass back and forth is the key. This is how standard encryption works.

But is there any documentation for or against obfuscating the data further? Thus making it essentially worthless unless you have the key and ALSO know how to un-obfuscate the encrypted data?

Obfuscation is generally not useful as a security feature or enhancement of encryption.

That said, there are reasons to use obfuscation, but it's generally in regards to attribution rather than security.

A classic example would be using steganography to hide your encryption. The purpose is not to enhance security, but to hide the fact that you are communicating at all. Another example would be using obfuscations like "meek", and others, to hide the fact you are using Tor.

Depending upon your intent and environment, using obfuscation with encryption could range from pointless inconvenience to extremely important.


Are there tangible recommendations for USB drives to be disabled? I am currently discussing / considering the possibility to disable access to USB drives (USB storage) on Windows machines.

There are technical means to do this and I am trying to balance arguments in the threat scenario.

PRO removal of USB drives

ability to bring in malware (no malicious intent from user)
ability to bring in malware (malicious intent from user)
ability to offload data
loss of unencrypted drive → potential loss of data

CON removal of USB drives

none (from the perspective of security)
plenty (from the business perspective: exchange of data with customers, offloading of large files)
the attack can come from BadUsb (this is not a real "CON", rather the fact that USB drives do not cover the whole threat spectrum)

There are also counter-arguments for the PRO section:

the "ability" part is not limited to USB drives, the data/virus transfer can be done though virtual means (virtual disks, email, ...)
the "not encrypted" problem can be solved by requesting that connected drives are forcefully encrypted

My question: are there tangible recommendations for USB drives to be disabled?

Tangible here means either "standards based" (common sense optional), or "common sense".

Annex A.8.3 of ISO 27001 relates to the management of removable media. I can't find a link to the standard itself, but there are some online resources which refer to it:

http://iso27001guide.com/annex-a/asset-management/media-handling/iso-27001-management-removable-media-requirements/

  "ISO 27001 does not mandate that removable media cannot be used, it
  just recommends that media is used in a secure manner. By specifying
  the organisations stance and implementing controls to support this
  policy, the organisation can gain a level of control over removable
  media that may otherwise pose a very high risk"

and ...

  "organisations must be able to demonstrate that the risks posed by
  removable media to the organisation are controlled. ISO 27001
  describes this as implementing procedures in line with the
  classification scheme adopted by the organisation"

https://www.isms.online/iso-27001/annex-a-8-asset-management/

  "General use of removable media must be risk assessed and it may be
  necessary to carry out use-specific risk assessments beyond that too.
  Removable media should only be allowed if there is a justified
  business reason"


What do we have to keep in mind when opening up our data to a third party? We have a database with pictures (amongst other things). We have a few apps that can connect to this database via a php webservice (send https requests to a php file to retrieve stuff from the db and write new stuff to the db).

Now a third party wants to work together with us. They have their own web portal where their users have to log in. Their users can see some basic data, and the idea is that their users that are also our users can see the pictures from our database from within their portal.

We are not going to give this third party access to our database, but we do want to expose the pictures, given that the user is logged in. So we have been brainstorming a bit and came to the conclusion that whatever way we are going to do this, it's going to be a huge potential security issue if we don't do it perfect.

We thought about creating another database and sync it every hour or so with our live database. Then we want to create another webservice, so the third party can access the data in this second database. But now there is still no way for us to make sure the user is actually logged in, we don't have access to the third party's database either, so we can't verify this.

Can anybody explain what we have to keep in mind for a project like this? Did we skip something? Is it even possible to do this 100% safe?

There is a framework that exists specifically to enable this sort of scenario.  It is called OAuth 2.0.  What you want to do is to have an API that exposes the resource owners' (your users) resources (their pictures) for the client (the third party) to consume with the permission of the individual resource owners.

So, in this model, you become an OAuth 2.0 provider, and the third party implements an OAuth client.  Then, the users who are user of both servers can authorize the client to access their pictures, and the third party will be given an access token that will allow them to retrieve the pictures from your API for the users who have granted them said access.

I don't know that the second database serves any purpose.  Since you're going to be exposing access via a service rather than granting direct access to the database in any case, the second copy of the database simply sounds like unnecessary additional complexity to me.


What sort of attacks could be performed by an attacker who can set environment variables? If an attacker can set environment variables at will, what attacks can be performed using this advantage, and what degree of control can the attacker take?

What about LD_LIBRARY_PATH on Unix/Linux or PATH on Windows? If I manage to get a malicious notepad.exe into C:\windows\temp, I can add this path as first element in the PATH and the malicious file will be executed instead of the real one.


Does any DNS Recursive resolver accept a "DNSSEC-only" option under DNSCurve? I want to use DNSCurve (for privacy) to a trusted DNSSec resolver (for integrity), and want to ensure that I can tell a recursive resolver (like 8.8.8.8, or OpenDNS) that I only want DNSSec queries.

Logically this would be similar to issuing either of the following options:

Recurse
No Recurse

Question

Does such a technique exist, no matter if it is enforced by a DNS recursive resolver (mentioned above) or as a proposed RFC enhancement to the passive DNS client to Server protocol?

It appears that secure DNSSec recursive queries are not possible to enforce.

According to the notes in this IETF draft:

  DNSSEC is not an enforcement mechanism, it's a resource. When I see
  folks voice opinions that DNSSEC's recommended operation has to
  strictly followed, my gut reaction is that these folks have forgotten
  the purpose of all of our efforts. ~ Ed Lewis

DNSSEC is offered as a help and DNS servers can be configured to maintain the security of the recursion chain, or not. It also appears form Mr Lewis' comment, that there might not be a method to enforce secure recursion for some time.


Does validating a mime-type reduce or stop the need for virus scanning? I am building a small web app in php, that accepts .doc /.docx / .rtf and .txt files. I've validated them against their mime-types. But now I'm thinking about virus scanning. I know there are systems like siteLock that can scan your systems for malware/viruses. I also know there are http://en.wikipedia.org/wiki/Clam_AntiVirus that I believe can be used to scan the stream as it's uploaded.

Is it necessary to also try and use Clam as the stream is uploaded? Not really sure here what is the best way forward?

Thanks for any help. My first post on here.

What do you mean by validating it against it's MIME-type?  Mime typing is simply a way for an e-mail to make a claim as to the purpose and type of an attachment.  It doesn't include any built in validation.  MIME-type has nothing to do with viruses or virus scanning and a virus could still be sent through a Word document macro for example. So no, nothing to do with MIME type precludes the need to virus scan e-mail attachments.


PGP Key Servers Verification Mail? Why do existing PGP key servers not perform e-mail verification?
Wouldn't it help the problem of authenticating of public keys?

By e-mail verification/confirmation I mean a single e-mail sent to the public key e-mail address. The public key would only be published if the e-mail address owner confirms the key.

Some do. keyserver.pgp.com does for example and it's a useful precaution. However, it would not be sensible to rely on this or you'd be able to publish public keys - and undertake a spoofing attack or man in the middle attack - if you were to compromise someone's email account only and then submit a fake key!

The best way to ensure ownership is checking the fingerprint by word of mouth or some other, trusted, channel.


Writing file shredder I want to write a simple file shredder in c++, i.e. a program that deletes a file so that it is not recoverable. Would the following be a secure and correct way to do that?

(1) Open the file with

ofstream myfile;
myfile.open ("deleteme.txt", ios::out | ios::binary);

(2) Then run through 10 rounds of something like

unsigned int x = 0;
for (int i =0; i <= filesize -1; i++)
    {
    myfile.seekg (i, ios::beg);
    myfile << (char)x;
       [put new random character in x]
        }

(3) Then simply delete the file

  if( remove( "deleteme.txt" ) != 0 ) {
       cout << "Error deleting file";
       }
  else {cout << "File successfully deleted";
       }

(I guess one could simply also just delete the file in a console.)

Would it add extra security to rename the file before deletion?

Is there anything else that should be done to completely remove a file so that it cannot recovered or is this enough?

EDIT1: Just to clarify, the above code is sime-pseudo. My main concern is if overwriting a file byte by byte and the deleting the file will be a good way to make it irrecoverable.

EDIT2: I am just interested in the best way to do this by using software alone.

Edit3: Adding one more thing: I am mostly interested in a level of security that prevents recovery by methods of software.

Sounds like a fun project. I know you said "simple," but here are my thoughts anyway.

The data you're writing the file over with isn't random, and one pass will still leave traces of the original data. It depends on the storage medium. For example, with magnetic devices, there's magnetic force microscopy. Even after ten rounds of the same thing, I'm not sure you're adding any extra benefits.

Renaming and deleting files won't add robust protection because, on most file systems, it simply changes the pointer to the location on the disk where the data is. Deleting a file only removes the pointer, so the disk sees the blocks as "available" even though the file is actually there. (This is why recovery software works.)

Thorough, secure deletes have the following features (software-based, not considering hardware solutions):

PRNG (Pseudorandom number generator) which generates random values to write at every byte of the file's allocated space (also see the encryption feature below).
Multiple passes (careful here, depends on the medium)
A run with all 0s then all 1s couldn't hurt, either. It may help interrupt a predictable, yet subtle, pattern of randomness (because computers aren't truly random).
Some file systems are "Copy-on-write", which is like a type of "revision control." These try to avoid overwriting data already in place. That protection would have to be circumvented.
RAID devices mirror changes to a disk onto another disk.
Fragmented files may start at one sector and finish at an entirely other part of the disk. Alternatively, anti-fragmentation features may keep redundant copies of the data or relocate them in real time.
Solid-state drives manage the disk space differently than magnetic drives. Coupled with wear-leveling, there are technical reasons that make secure wiping a little tricky. (See Wikipedia link below)
Encrypting a file before wiping it will help fill it with "random" bits... but really the best answer to secure shredding is to encrypt it before it ever hits the disk.

Don't miss this great question which talks about wiping info on solid-state drives, particularly flash drives. Remember that SSDs wear out after being written enough times.

Look at this article on Wikipedia for some more detailed background info.

By the way...

I'd really like to see a shredder that grants some plausible deniability. It would securely erase the file, then plop remnants of a decoy file in its place, perhaps a file chosen by the user that exists elsewhere on the hard drive. It would appear to be the remnants of a copy of that file which at one time was pointed to by the file system, was deleted by the user, and, depending on the size, was potentially being gradually overwritten by regular use.

If a forensics agent were to examine the portion of a disk where a regular shredder was run, it's easy to tell that it was wiped with random data. But if a decoy file was put in its place, I imagine it would be harder to tell.


How to get the password from Windows Application? I have an application call Metatrader 5. I had logged in way before and now I lost my password. The login could be seen but the password is hidden. I want to know if there is a way to get the hidden password?

See the image:

I want to get my password. Do anyone have anything to say?

A not too technical solution is using an unmasking tool to unmask those asterisks in browsers and software.

These are 3rd-party unmasking utilites:

Bullets Pass View
Encrypted Reg View
Asterisk Password Spy (I have used)
Kernel Password Unmask

I don't know Metatrader 5 but there is a Windows built-in tool for this situation which usually used in organizations and enterprise companies.

Go to Control Panel\All Control Panel Items\Credential Manager then click on Windows Credentials, Then possibly you see your password there.


How to hide Kernel Symbols in Linux Kernel Image? Recompliation? Why hide kernel symbols?

Quote

  Anyone with basic knowledge of kernel exploitation knows how important information gathering is to reliable exploitation. This protection hides the kernel symbols from various places that an attacker could use during information gathering in pre-exploitation stage.
  ...
  This option also prevents leaking of kernel addresses through several /proc entries.

Bug Classes/Kernel pointer leak

Some places are obvious. /proc/kallsyms can be constrained through sysctl kernel.kptr_restrict=2. Access to folder /boot can be restricted through linux file permissions to root only and with apparmor even be hidden from root. AppArmor FullSystemPolicy (apparmor-profile-everything) Also other places such as /lib/modules, system.map, and the kernel source directory.

For the sake of asking a very specific question, please ignore other places where kernel symbols might leak. If want to enumerate them, please ask your own question, wait until I ask or add a comment.

My very specific question is around the following Quote:

  The kernel [...] is not precompiled by some distribution

This is because kernel symbols can be extracted from the kernel image. There are Open Source tools for that.

(That quote is about grsecurity but I am asking about non-grsecurity, i.e. the regular kernel from kernel.org here.)

Kernel images from public repositories such as packages.debian.org are well known by attackers. Attackers could simply hardcode the symbols addresses and thereby counter effort such as kernel.kptr_restrict=2.

To prevent kernel pointer leaks, the kernel image cannot be in a public known state. It needs to be unique, private as far as I understand. One needs to compile the kernel oneself.

Reproducible builds are an amazing effort of increasing the security for everyone. However, in this case reproducible builds would result in again ending up with a kernel with symbol addresses well predictable by attackers because the Debian linux kernel is already reproducible, mostly reproducible or in future fully reproducible (I didn't follow up where development is regarding that).

How to hide kernel symbols of the linux kernel image (vmlinux) from an attacker? How to make sure my kernel has unique kernel symbols? Is there a kernel boot parameter for that? Or is it possible to somehow supply the kernel with a random file so it can randomize its symbols? Or is there some way to recompile the kernel in a way it would have unique symbol addresses?

The layout of a distribution precompiled kernel is public. KASLR attempts to change the base offset of the kernel, changing all the addresses by a secret offset. Unfortunately, leaking even a single symbol will allow the rest to be calculated. Since KASLR is not nearly as secure as it is made out to be, this is a problem. The danger of KASLR bypass through infoleaks can be only slightly reduced by setting the sysctl kernel.dmesg_restrict=1 to mitigate leaks from printk(). Even still, KASLR is such a poor security feature that you can't use it to reliably hide this information from local attackers.

Compiling a kernel manually will ensure that you will be using unique symbol offsets. It is necessary to set the sysctl kernel.kptr_restrict=2 and restrict access to the kernel image itself as well as related files like the map and loadable modules. You can make attacks based on knowledge of kernel structure a bit harder if you use the RANDSTRUCT plugin from grsecurity, now in upstream.


Implementing key vault and key rotation for a non-cloud application I have a desktop application written in Python. The application is connects with an external SAP HANA service and pulls data. There are couple of configuration files where several connection string are stored unencrypted as of now.

I want to encrypt the config files which should get decrypted when user logs in. I checked few libraries like encrypted-config but my requirement doesn't fit here.

My plan is as below

The configuration file is encrypted using an encryption Key:CK
CK is stored on another server as encrypted with the user password HASH.
When user logs into the application, password Hash is calculated and it connects to the key server, decrypt CK, store it in cache, decrypt the config file
Pull data from SAP

I don't know how reliable is this approach but there are few challenges:

If CK is encrypted with user password Hash, I need to keep multiple copies of CK for each user.
I want to implement Key Rotation and in that case the problem 1 shared above will be even more tricky.

** Edited **
This Key Server is not specifically used for key management. I have just named another remote server as key server where the keys would either be stored encrypted in a database or a file.

Please advise.

The question is making incorrect assumptions on some of the details.  For example, it says to calculate a password hash, and it looks like it is assuming the hash is used as the cryptographic key to encrypt/decrypt the key on the key server.  But that's not normally how key servers operate.

Key servers have their own encryption mechanism and will encrypt all their keys with their own key (usually called something like the "master key" or "Key Encrypting Key (KEK)".)  When you connect to the key server with a password, the server will authenticate your username/password combination.  You will then request access to a specific key name or key identity, and if you're authorized it will grant your access.  Depending on the server's configuration and your request, it may export the key to you so you can use it to encrypt and decrypt, or it may provide encryption/decryption services to you.

The key server's job is to securely store the keys, and to perform key lifecycle management functions (key generation, key destruction, etc.)  A key server may provide key rotation functionality; but because there are no cryptographic standards for key rotation or key versioning, the implementations will be server dependent.


Received 2 "Delivery Status Notification (Failure)" Mails from postmaster@hotmail.com with messages I did not send. Is this an attack? about 1-2 hours ago, I received 2 emails from postmaster@hotmail.com on my personal email with title "Delivery Status Notification (Failure)" and a body as such:

  This is an automatically generated Delivery Status Notification.

  Delivery to the following recipients failed.

   (email I never heard of)

The emails have 2 attachments: details.txt containing the following content:

  Reporting-MTA: dns;SNT004-IMC1S8.hotmail.com Received-From-MTA:
  dns;SNT004-MC5F5.hotmail.com Arrival-Date: Fri, 2 Jun 2017 11:03:56
  -0700

  Final-Recipient: rfc822;(email I've never heard of) Action: failed Status: 5.5.0
  Diagnostic-Code: smtp;550 Requested action not taken: mailbox
  unavailable (-506263085:397:0)

and an Outlook item called "You've Got Postcard" with login credentials for My Postcard.

Is this a known scam or malware attack? I use Outlook, and unfortunately it showed both emails in a preview window, which from what I understand is equally bad as directly opening the email with regards to potential for infection.

Update: the website that the "You've got Postcard" mail links to is wintergate dot com slash controlsk dot php (escaped to avoid accidental visits). One of the credentials (in case it helps) is kkrasa, Domain msn, Top Level Domain com (escaped to avoid spam) with password "BIZ" + "K7", so both quoted terms concatenated in this order without double quotes.

If anyone is interested in the direct HTML of the Postcard mail, it can be found at https://pastebin.com/twSL5v4a. I have already deleted the original email, so I cannot provide anything beyond this (this was in my Notepad++ cache).

Its a very common type of phishing.  Most likely they have spoof your address as the sender (From: ) and might intentionally cause a bounce so you would get/open the emails.

You are correct in that it is as bad.  This is specially true if the email is html encoded and it could be executing something malicious and you wouldn't even know it.

Your are always much safer in running outlook in plain text mode only and probably only load html emails from trusted sources.  Your other option is since your using windows (most likely) cause its outlook, you could have your antivirus scan your emails to be safer.

Again though I would opt out to view emails in plain text just to be safe.


Motorola Human Authentication Pill/Vitamin Security? This appears to be hot news today, Motorola announced a form of pill that a user can swallow which is activated and powered by stomach acids and transmits a signal back which can be used to authenticate a system via "an 18-bit signal".

Is this some form of RFID? If it is, how is this any more secure than any other form of RFID authentication mechanism? Small RFID systems that i've previously investigated have notoriously poor security features so i can't imagine anything this small being particularly powerful.

The thought is probably that since it is inside you it can't be stolen, so obviously it would be more secure than a form of ID that could be stolen. I think it's pointless, and actually potentially hazardous to the user:

It would only last a few hours. It's powered by stomach acid, once it's out of the stomach it would stop working. What are going to do, take an authentication pill every day? Why not use other biometrics what rely on what you are, rather than what you have?
It's dangerous to the user. Nowdays if a thief wants money out of your bank account he/she will skim your card and capture your pin with a camera or a fake keypad. It's not a violent crime. With an intestine-based authentication system (or any biometric authentication system) the thieves will need the user physically in order to authenticate, opening the user up to kidnap, coercion, forced vomiting, or at worst having their guts cut out

It's an interesting experiment, however I wouldn't actually want to use it. If someone threatens me with a knife or a gun wanting my money, entry into a facility or whatever then I can give them my cards, my codes, my key fob, whatever. The trouble with a swallowed device is that I can't give it to them at will.


I am getting "Your connection is not private" error and it disappears when I use a VPN I use a Mac (running macOS Sierra). Yesterday I was watching a movie online from some not-so-trustworthy website and when I clicked the pause button, a tab appeared and suddenly disappeared.

From that moment onwards, whenever I open any https site, it throws an error named "Your connection is not private". It doesn't matter if I use Chrome, Safari or Mozilla Firefox, all of them throw the same error. A moment ago, when I opened google, it opened a tab with the url: Gstatic.com/generate_204 by itself!

The interesting thing is that if I use Tor or if I use a VPN and change my location to anywhere else, all websites start working!. Why does this happen?

Things I have tried:

1) Checked the date and time - They are all correct.

2) Deleted my cache and restarted my computer and browser.

3) Tried finding some unwanted installed applications or some extensions on my chrome that I didn't install - I couldn't find any.

Could someone PLEASE provide some help! I am scared to death that my mac has caught some virus and all my credit card information might be at risk!

This looks like a man in the middle attack but not  on your computer but instead on your network - otherwise the problem would likely not vanish if you use Tor or VPN.

This might be because you are using an insecure network (like an open WiFi hotspot) where somebody is doing an attack or because your private network is compromised. The latter could be for example because of an attacker in the local network or because your router was compromised - for example with something like DNSChanger.

In case of a compromised router doing a reboot or (if does not help) a firmware reset of the router might solve your problem temporarily. But you should better make sure that your router will not be attacked again by updating its firmware with a fixed version from the vendor (which hopefully exists).


Why does Google still use SHA-1 for securing API keys if its been compromised? If you read Google's best practices for use account you'd see them warning against using SHA-1. They have even purposefully cracked it in 2017.
If that's the case, then why when you restrict google cloud API keys for android apps, you use a SHA-1 fingerprint of your android app? Seeing as how its trivial to fake a package name (the other required detail to identify your app) you're only left with a security method thats been already cracked.
Why would Google secure such an important thing as an API key with a hashing algorithm that they warn against?
I have searched an answer for this on the web, and while there are some answers that deal with this topic, none specifically deals with the dissonance google has shown.

Im summary: SHA-1 has various use cases and while some are considered broken others are not.

You are mixing apples and oranges:

  ... them warning against using SHA-1.

They advice against SHA-1 to be used as hash in storing passwords. But this is not specific to SHA-1, it is even a bad idea to use SHA-2 for storing passwords. See also How to securely hash passwords?.

  They have even purposefully cracked it in 2017.

They have shown a collision attack. This is not "cracked" in the general sense but it shows a specific weakness and affects only use cases where collision attacks can be a problem.

  ... then why when you restrict google cloud API keys for android apps, you use a SHA-1 fingerprint of your android app?  Seeing as how its trivial to fake a package name (the other required detail to identify your app) you're only left with a security method thats been already cracked.

If you want to reuse an API key which belongs to the app of another party then you have to mount a pre-image attack and not a collision attack. Pre-image attacks against SHA-1 are not feasible so far.


Methods for analysing android app on runtime I want to analyse security of android app by monitoring its behaviour on runtime. I need to monitor variables modifications, accesses and api calls while android app is running on the device. I tried to do this by JPDA framework and wrote my custom debugger. I succeeded in doing above task upto some extent but I am not moving any further due to some limitations in JPDA. Is there any method/tool available to do above tasks where I can also write my own logic to check security using above basic building blocks ?

You can try Frida it is an amazing dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers. You can analyze the behavior of the application and run-time and you can easily perform run-time analysis using it.


Is SpiderOak truly “zero-knowledge”? I've recently changed SpiderOak password on computer A. Because I have SpiderOak installed on computer B as well, I thought I will have to update the password on it so the application can connect to the server.

I was quite surprised when I found out the password updated itself automagically.

So I sent a question to SpiderOak. Here is what they replied:

  I must point out that if you change your password, these updates will
  be detected across all of your machines because SpiderOak encrypts
  your password and the encrypted password is sent to the server then
  distributed to each device. Each device is able to decrypt the
  password and update to the new changes.

  By changing your password, you have created a new set of encryption
  keys. All keys are encrypted with 256 bit AES, using a key created
  from your password by the key derivation/strengthening algorithm
  PBKDF2 (using sha256), with a minimum of 16384 rounds, and 32 bytes of
  random data ("salt"). This approach prevents brute force and
  pre-computation or database attacks against the key.

I don't really understand. How is a device able to decrypt the newly created password?

Disclaimer: I have never tried using spider oak so I'm only by going what they claim they do, what they told you they do and what the end result looks like.

Given that they claim to be storing your data encrypted and never being able to access it, I would assume the only thing they ever have access to is really the encrypted version of your data. This would mean the application on the client performs all the encryption/decryption operations and only stores the resulting data (and possibly extra encrypted metadata on the server).

This data must be encrypted by something. Now going by their response to you, I would assume they have some hierarchy of keys. My guess would be at least 2 levels, but for simplicity let's just assume one.

This would mean the data is encrypted by some randomly generated key K1 (on your machine). This key is then encrypted by a key K2=PBKDF(32 byte salt,password,16384 rounds). By the preceding ugly description I mean they use the PBKDF2 (Password Based Key Derivation Function v2.) algorithm (using SHA-2) to generate an encryption key from your password. This key K2 would never be stored anywhere (except client memory). It would always be generated on the fly when you want to access your data.

The package that would then be sent to and stored on the Spider Oak servers would be EK1(data),EK2(K1). When you then want to retrieve the data you get the data sent over to you encrypted, and the key sent over to you also encrypted. When you enter your password, PBKDF2 is used to generate K2 which is used to decrypt K1, which is then used to decrypt your data.

So what happens when you change your password? Well the server sends your client all the packages EK2(K1)$ for any K1's it has for your data. Locally these get decrypted by the key generated from the old password, and reencrypted by the key generated from the new password, which gives a new K'2.

When you then come to a different device, fire up your client and try to retrieve your data, the encrypted data come accompanied by the key encrypted using you new password. You enter the password, PBKDF2 does it's magic, and voila you decrypt K1 and then decrypt your data.

edit: GAH how do I get TeX to work here in my posts?

Edit2.: Rereading the information you got from the representative it actually seems like all new K1's are also generated. This seems somewhat fishy in the sense that either they do encryption/decryption on their servers (thus it's not fully zero-knowledge) or they send all the data back to you when you change your password and your client reencrypts it. The first of these seems more likely to be honest, since the overhead for the client otherwise would be quite large. Ofcourse it's also possible the representative doesn't really know what he's saying. I've had that happen multiple times.


Key Management for PCI and Payment automation We're a bootstrapped startup looking to achieve PCI compliance, we've almost nailed all requirements but I recently came across this blog post which totally derails our plans and efforts : http://securology.blogspot.in/2008/12/stupidest-pci-requirement-ever.html

"Consider an automated e-commerce system. The notion of automation means it works on its own, without human interaction. If that e-commerce system needs to process or store credit card numbers, it will need to encrypt and decrypt them as transactions happen. In order to do those cryptographic functions, the software must have access to the encryption key. It makes no sense for the software to only have part of the key or to rely on a pair of humans to provide it a copy of the key. That defeats the point of automation."

.. so we can't process payments automatically on monthly billing date using the stored cardholder data? Do we both have to enter keys for EVERY transaction, thats just impossible right?

You CAN use stored keys and DO NOT have to enter keys manually, but you also must rotate (change) keys every quarter, and a separate key for each customer is a good idea, too.


What is the message called someone sends to verify a key? Suppose Alice wants to check if Bob has a certain keypair. Alice could send some random payload to Bob and let Bob sign that payload with his private key. Alice is now able to check if the signature matches because of the known public key.

What is this payload called?

While there may be other names, calling it a challenge seems appropriate. From the challenge-response Wikipedia page:

  In computer security, challenge-response authentication is a family of
  protocols in which one party presents a question ("challenge") and
  another party must provide a valid answer ("response") to be
  authenticated.

Later on the article goes on to describe the symmetric encryption version of the situation you mention:

  One way this is done involves using the password as the encryption key
  to transmit some randomly generated information as the challenge,
  whereupon the other end must return as its response a similarly
  encrypted value which is some predetermined function of the originally
  offered information, thus proving that it was able to decrypt the
  challenge. For instance, in Kerberos, the challenge is an encrypted
  integer N, while the response is the encrypted integer N + 1, proving
  that the other end was able to decrypt the integer N.


Why does the server generate a random challenge for SSH authentication? Wouldn't it be more efficient if the client initiated the connection by generating their own message, and encrypting it using their private key, then sending both messages to the server so it would decrypt and compare the messages?

This would essentially allow for a replay attack. Capture the messages, and replay at a later time. To avoid this the server would have to store all previously seen values, to ensure no reuse.
However, by making the server send the nonce, and making it sufficiently big, we can be fairly certain that someone in fact posesses the key if the can return a reply that matches the nonce.


DNS Spoofing Detection with JavaScript I've came across an interesting question today - how can a JavaScript detect  that a DNS Spoofing attack has been made against the client its running upon?

Scenario:

Edit: wrong scenario was presented. Please refer @Polynomial's excellent explanation. I will update this question with a detailed, more challenging scenario soon.

Thanks!

DNS spoofing doesn't change which domain a victim reaches, but rather which IP it thinks the domain points to. As an example, if I try to fetch the DNS A record for http://example.com, and an attacker performs DNS spoofing, they can falsify the DNS A record contents in the response and point me to an attacker-controlled IP address. My browser still shows http://example.com in the URL, but it connects to the attacker's IP rather than the correct IP. This is a common man-in-the-middle trick.

The solution for this is SSL/TLS. Your browser goes to visit https://example.com and the attacker performs DNS spoofing, but since the attacker cannot own a valid CA-signed certificate for that domain the certificate will show up as invalid and the browser will not connect. This only work if your web page directly points to the HTTPS version of the site, though. If you point to HTTP and the server redirects you to HTTPS, an attacker can still man-in-the-middle the initial HTTP connection and proxy that rather than forwarding you to HTTPS.

By X-Allow-Origin I assume you mean Access-Control-Allow-Origin (ACAO), which is part of Cross-Origin Resource Sharing (CORS). CORS tells the browser which other domains can access data on your server from using Ajax, for example xyz.com can set an ACAO header that allows scripts on bbb.com to access data on its site. This does not prevent DNS spoofing attacks. As I described above, your browser still thinks you're visiting the original domain name, it's just that the IP address for that domain is illegitimate.

Frames are controlled by X-Frame-Options, which specifies a policy of which domains (if any) can load your webpage inside a frame. This is mostly a protection against clickjacking and UI redressing. The X-Frame-Options header is now deprecated in favour of the frame-ancestors Content Security Policy (CSP) directive, which has more granular control over frames than X-Frame-Options does. Again, this operates on domains not IPs, so it doesn't prevent DNS spoofing.

In both cases (frame options and CORS) they rely upon your browser being able to tell that it is visiting a legitimate server, hence the need for HTTPS.

Luckily, you've got some weapons in this fight. The first is HTTP Strict Transport Security (HSTS). By setting this header you can tell a browser that all subsequent visits to the site must be over HTTPS, and if it sees a HTTP URL it should automatically use a HTTPS one instead. This means that all visits except the first are protected against man-in-the-middle attacks. HSTS also (usually) prevents the browser from allowing the user to skip past the certificate error. Since you're using TLS, an attacker can't do a man-in-the-middle attack regardless of what type of spoofing they use (DNS, ARP, etc.)

The next trick is to explicitly use https:// for the third party domain in the ACAO header, i.e. https://bbb.com rather than http://bbb.com or bbb.com. This means that if a user visits the third party site over plain HTTP, their browser will refuse to communicate with your site because of a CORS policy violation. This protects you against cases where an attacker does a man-in-the-middle attack against the 3rd party rather than your site.

Thirdly you can use X-Frame-Options and CSP's frame-ancestors directive to restrict which other domains can load your page in an iframe. Again you can specify https://bbb.com explicitly to ensure that the 3rd party can only load your page in an iframe when the user has visited it over HTTPS.

If the request fails due to CSP, it may be possible to detect that directly in JavaScript, but this StackOverflow question suggests not - it just appears as an error state like any other. However, what you can do is configure CSP reporting, which causes the user's browser to send a report to a URL of your choice containing details about the event whenever something is blocked by CSP. You can implement CSP report logging on your own server, but if you're looking for a quick and easy (and potentially free!) solution I would suggest considering signing up to report-uri.com to handle this for you.


How does an email provider verify my custom domain name? I'm new to this and I've read a tutorial on this page: http://www.melyssagriffin.com/use-gmail-custom-domain/

The author of the tutorial wrote about her experiences of setting up a custom domain name in her e-mail address for her webpage so something like office@mywebsite.com. Now, what I don't understand is how the confirmation process works i.e. how the email provider verifies that I really own the domain. And this seemed weird to me - Gmail only requires that the owner of the website puts some unique HTML code on their website as a confirmation. What surprised me is that there was no third-party involved. Nobody contacted for example the company who registered the domain (e.g. GoDaddy) or anyone else. It seems to me that a Gmail bot just scanned the webpage, saw the pasted HTML code and basically said "ok, you're good to go".

So what does prevent me from becoming a new email provider and setting up an email with an already taken domain like mymail@google.com or mymail@reddit.com?

In short: You cannot simply set up a rogue Google or Reddit e-mail server, because DNS.

E-mail clients and servers rely upon DNS in very much the same way most web browsers and websites do. When a node has a package that requires delivery to an address at domain.tld, that node will first query their DNS servers to retrieve the MX record for that domain. The MX record, in turn, points to the registered IPs or hostnamefor the e-mail servers for that domain.

Even if you set up your e-mail server, and configured it to accept mail for domain.tld, it would never receive mail for that domain unless the person in control of the domain's DNS included your server in their MX records. Of course, there are ways that DNS could be spoofed or a system could be pointed to a rogue DNS server. But those are beyond the scope of this discussion.

Aside from making sure you're not trying to set up a spoof mail server, the dependency upon DNS is another reason Google and similar services require this type of verification for custom domains. The verification process requires that you post a unique string in a location which requires a DNS lookup to reach. If the service provider can verify that you have posted the string there, then they know that you at least have control of the DNS records for that domain.

(Whether control of those records was legitimately obtained is, to a certain degree, not their concern. It's largely up to the DNS provider to make sure unauthorized users cannot modify the records.)

If you don't have control of the DNS records, then no e-mail provider will be able to service your custom domain. Thus, why would they go through the trouble, and expend the resources, to set up a server that won't provide the functionality their customer expects?


Are there any Layer 2 Wifi RFC proposals that isolate each connection from each other? (like a switch) It's my understanding that everyone on the same Wifi protocol has full access to each other host that it is connected to.

Is there any Wifi technology that allows for partitioning and isolation of each individual client... at Layer 2?

Ideally this will work even when everyone knows what the shared secret is.

I'm thinking that once a "normal" wifi session is set up, a tunnel of some sort would be enabled on the Wifi router itself to the client.  Perhaps the key exchange used in HTTPS could be ported to Wifi to allow this tunnel to be created.

You might be interested in this talk that was given at DEFCON a few years back.

Summary: if you are using WPA2, a separate key is used to encrypt broadcast traffic vs. unicast traffic. So in that sense, connections are isolated from each other. HOWEVER, you're still vulnerable to an insider attack; a malicious client could spoof ARP and intercept traffic from another client.

But that's why you get an access point that allows you to enable client isolation (if you care about that threat enough).


Should we enable TLS on backend connection after reverse proxy? I have a reverse proxy (e.g. nginx, nghttpx, haproxy) that proxies connection to a service running on the same physical server. I think the most common way to configure this setup is to enable TSL only on the frontend and leave the backend connection unsecured. In other words, the reverse proxy is the TLS termination point.

Why is there no security concern on leaving the backend unsecured?

If a malicious client happens to know the address/port of a backend service, can't they connect to it directly without having a valid cert and isn't this a huge security risk?

Connections to the backend server should be rejected when the originate from an external address, that is from some other machine outside the secure machine/subnet. This is accomplished by configuring the backend server and/or operating system. If this isn't set up properly then yes, it could lead to a major security breach.

Generally secure connections don't require a client certificate though. Usually the certificate proves the authenticity of the server rather than the client (but there are some exceptions). Some other mechanism (e.g. basic authentication, cookie, OAuth) is required to authenticate the client.


In what sense is a VPN not safe? I recently came across this answer here https://security.stackexchange.com/a/17860 and was surprised that VPN traffic could apparently be monitored.

I am new to this subject and am trying to better understand how it all works. I have zero interest in doing anything illegal, but I am highly paranoid and don't like the idea of being monitored (I grew up with enough of that already).

So I became interested in security, but I don't understand it very well. Conventional wisdom suggests a VPN is the answer, but then answers like the one above confuse me. It seems like traffic coming from you is encrypted, but not the traffic coming back?

Is a VPN really enough? If I log into Gmail from my normal IP address, but then log into that same account with a VPN, is this considered a security hazard? Is the only way to use a VPN safely is to basically be a completely different person from your non-VPN self? Different accounts, different mannerisms, different everything? What information is accessible by someone monitoring my traffic (either a malicious person or the building that owns the routers / local network or the ISP, etc)? Is it wise to use a VPN and then activate a Tor browser? Can we really assume the VPN is not logging you? Does it matter if you use PayPal? Does it matter what email address you use to sign up? Does it matter if you use a credit card associated with your real name?

I am operating on the fundamental assumption here that it is never fully possible to achieve 100% security, anonymity, and privacy, because at some point security through obscurity is part of the equation, and at some point we have no choice but to trust something or assume we're being logged and monitored, and so on. But I'd still like to do all that I can.

When is a VPN not safe? What are the best practices for using one?

A VPN just moves the point of entry of your unencrypted data to a different network provider. It's great if you don't trust the network provider you're actually connected to, maybe because it's a public wifi network or because you think your government might be monitoring it, but you have to trust the VPN provider's network instead. If you don't want to trust any network provider, you have to use encrypted connections only and just give up on browsing websites that don't support TLS and on other unencrypted protocols.


How can I verify ownership of a domain I'm working on a web service. I need a way to verify a user owns a domain they attempt to use in the service.

How can I verify when a user attempts to add a domain to the service that they own the domain?

I have a few ideas, but I'm not sure how secure they would be:

Have them add a DNS record to the domain. Possibly a TXT record my service generates.
Send an email to an account on that domain they specify with a validation link.

Any other ideas?

Letsencrypt gives you a file containing a string that the user then uploads onto the website of the domain you wish to verify. This verifies that your user has control of the domain.  DNS records are possible if there is no website, but this is cumbersome, and potentially very slow if the DNS has a long ttl.
The other real alternative is to send an e-mail to root@domain or postmaster@domain. No one who doesn't control the domain are going to be able to recieve these email addresses.
Of these DNS records are the most inconvenient I'm my opinion.


Cookie + CSRF Token vs OAuth Token for Native Mobile Apps We have an existing single-page web application powered by ASP.NET WebApi endpoints.  These endpoints leverage SimpleMembership and Forms Authentication to handle authorization and authentication:

    [System.Web.Http.HttpPost]
    [Route("api/login")]
    [System.Web.Http.AllowAnonymous]
    public HttpResponseMessage LogIn(LoginModel model) {
        if (!WebSecurity.UserExists(model.Username))
            return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Success = false, Error = "Email or Password is incorrect." });
        if (_userService.LoginWork(model.Username) && WebSecurity.Login(model.Username, model.Password, persistCookie: true)) {
            return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Data = true });
        }
        LogOut();
        return Request.CreateResponse(HttpStatusCode.OK, new ApiResponseDto() { Success = false, Error = "Login Failed" });
    }

We are now developing a native iOS app and would like to reuse these API endpoints in the name of simplicity.  To do this, we're using CSRF tokens as well as cookies to handle auth from both native and web apps.

I like the idea of keeping things simple and not rewriting ~100 API endpoints just to support mobile, but not if I have to compromise around security.  Is this solution "as secure" as the standard implementation of say a pure OAuth2 token-based implementation?  If not, why?

Sure, why wouldn't it be? You just lose (a lot of) the flexibility that is included in the many use cases of OAuth, which I assume you do not need. In particular, if you only care about your own app, and not about delegating access to others and/or allowing users to login with other identity providers, then you are just fine with this set-up. That said, if you are going to upgrade in the future, upgrade to OpenID Connect, instead of 'pure OAuth'.

A couple of remarks:

You will likely need to store the authentication token (which you normally include in a cookie) in some local storage of the device, as cookies do not exist in native apps. So you might need some kind of 'translator' in your app which catches the 'set-cookie' command and stores its value in the local device storage. Likewise for the other way around.
CSRF attacks do not exist in real native apps. However, if you use the same endpoints for both browser and app, you'll likely need to keep using them.
Use HTTPS (and possibly HSTS and HPKP) to secure your tokens during transport.


Signing a code and application I want to send my application to different servers/terminals with content integrity and confidentiality.
So, I need to some process to sign my code and application before sending it to servers and to ensure that the software comes from a trusted source and has not been altered.
What do you suggest? What are the most common practices?

For example, use a symmetric key to encrypt the code and a public key to protect the symmetric key and hash of package?

That is the basic idea, but you probably don't want to implement a custom solution. Depending on your operating system there is probably already a mechanism, for example Debian's SecureApt which leverages GPG.

https://wiki.debian.org/SecureApt


Privacy implications of static IP addresses (for home connections) All the other questions I have seen here focus on the security implications of IP addresses. I'm interested about the privacy implications.
In my opinion, static IP addresses for home connections (where you usually don't need to host any services) should be avoided, because they will make you easily recognizable on the internet. A static IP will uniquely identify you. A dynamic IP, on the other hand, will not identify you, although the address will probably only vary within a range. To me the impact on privacy of a static IP address is huge, but some other people don't seem to care at all (and love static IPs because they want to host stuff at home).
So the question is:

What are the privacy implications of having a home connection with a static IP address?
Should we prefer home connections with dynamic IPs if possible?
Would a VPN be a solution to mitigate the loss of privacy caused by a static IP address, or not? What other solutions would be effective?

As an example, in GDPR, an IP address is considered PII. It can identify a person during a sequence of interactions.
A static IP simply extends the impact of that. Anyone who can correlate activity with IP could correlate a larger set of interactions to a particular household.
Should you prefer dynamic IPs? You need to run your risk analysis on that issue.
Anything that would break up an IP would solve the static IP problem, by definition. But only within the scope of the problems of having a static IP.


Why are passphrases protecting GPG / SSH private keys needed? SSH and GPG each ask for passphrases during key generation. GPG also (at least from my experience) displays warnings if one is not provided and asks for confirmation that no security is indeed desirable.

Thus, it would seem, it is important to provide such passphrases.

However, assuming full disk encryption, I can't really get why?

My (likely flawed) thinking is as follows. These are threats to private keys:

Device theft; but if someone steals a device that is powered off then FDE already protects me from this (at least until the thief is determined enough to apply rubberhose decryption on me);
Momentary physical access; but in this case I'm hosed either way;
My PC is compromised, someone managed to install malware on my device; but in this case, again, I'm hosed either way because I have a keylogger installed that steals my passphrase. And that's even if the attacker wasn't able to root my PC!

Thus, the only scenario I can think of when the passphrase can be any good is theft of a powered on device; then indeed the passphrase might save me; but I find such a scenario not very likely. On the other hand, having to reenter the passphrase each time I make a git commit or send e-mail is annoying.

What are the uses of passphrases protecting SSH / GPG private keys I'm not aware of?

An encryption key is kept in memory for as long as it is being used. For disk encryption, the key is necessarily present in memory for the time the encrypted partition is mounted (for FDE, this is the entire uptime of the computer). Encrypting private keys ensures that the sensitive key material will only be available for very brief periods. The chances that a passive physical attack (one where integrity is not violated) will occur within the brief period that a private key encryption key is in memory is very small.
An arbitrary disk read vulnerability or DAC bypass may allow a malicious local process to read disk contents, potentially including SSH or GPG keys. Full disk encryption does not mitigate this, but key encryption does.
A malicious program that passively reads from your disk and does not set up a keylogger would be able to bypass FDE, but could not decrypt private keys if they are encrypted. In some cases, it won't set up a keylogger because it simply can't, for example if it does not have access to the X11 cookie.


Spike in TCP port 5904 activity - what for? There is an 'Internet Weather Report' on the Threat!Traq video blog by AT&T security researchers. In the March 14th broadcast, at around 31 minutes in, they mention an increase of scanning activity on port 5904/TCP. The researchers mention they do not know what is being scanned for.

Does anyone know what vulnerability (or use) the attacker(or benign user?) may be searching for?

I don't know what vulnerability they might be looking for, but VNC uses that port. http://www.cyberciti.biz/faq/linux-iptables-open-vncserver-port-6000-5800-5900/

Maybe one of the vulnerabilities listed here that applies to VNC servers. http://web.nvd.nist.gov/view/vuln/search-results?query=vnc


Is leaving a web server port open on my router a security compromise? I was wondering if I were to open port 80 on my router and forwards it to port 80 on my Apache web server would create a security compromise to the rest of my network. I was reading that open ports are not compromising until there is a service running on the port(such as Apache). However my question remains,can a hacker do much with a web server. Can the web server be hacked and create other security flaws in my network?

Forwarding external connections to some service inside the internal network is not a security compromise by itself but it could result in one. While the port forwarding will only give access to the specific service from outside it is not uncommon that the a web application (which is now available from outside) can be hacked and that the attacker thus gets access to the system where the application is running on. And sometimes its not even a problem of the web application but that the web server itself allows remote code execution already.

If the attacker has compromised the system of the web server this way it can now do even worse: Since this compromised system is on the internal network the attacker can use it as starting point to compromise the rest of the network.

Thus if you want to expose servers to the internet you should never forward external connections to the inside but instead put the server into a DMZ, i.e. a separate network which has limited visibility from the internet but can not access the internal network. This way the web server itself might still be compromised but it gets much harder to extend a successful attack into the internal network.


Does SHA-512 become suitable to store a password if we use salting and iteration with it? Today I have read this discussion about SHA-256 and SHA-512 and that we should not use any of them to store a password securely. And I have read here  that instead we can use the PBKDF2 hashing function, because we can use salt and specify the number of iterations. That is great, but what about if I use a salt and iterating with SHA-512?
For example, consider this simple implementation:

string Password= "admin";
for(int I= 0; I<numberOfIterations, I++)
{
   Password = sha512(Password+salt);
}
store(Password);

So is it possible to apply something like this?

Today I have read this discussion about wheels and that we should not simply strap ourselves to a wheel to travel on a multilane highway. And I have read here that instead we can take the bus, because it has safety features. That is great, but what about if I use a seatbelt with my wheel?

Salting is good. Iterations are good. SHA-512 is a good general-purpose hashing algorithm. But you can't just take a bunch of good things and strap them together and expect to have something safe to use. Like a commercial bus, PBKDF2 (or bcrypt, or scrypt, or Argon2) has lots of advantages over a homemade solution, primarily:

It has been tested extensively by experts.
There are multiple implementations, so your user database can be copied to a new platform with minimal fuss.
It has protections against problems you don't know are even problems (i.e. it was built by experts).


Self-signed certificate for SSTP VPN server I'm developing a custom VPN solution that needs to support SSTP for Windows clients. For this, my server needs to authenticate itself using a certificate during the SSL handshake. As usual, Windows will then look through its local set of trusted certificates and decide whether to accept or reject the connection.

Since this project currently doesn't have the budget to pay for an official certificate (from Verisign or whoever), I would like to use a self-signed one for now. Unfortunately, this means I will need to ask my users to install this certificate so that Windows can successfully authenticate my server.

I have two specific questions about this scenario:

If I ask users to install this self-signed certificate into their "Trusted Root Certification Authorities" store, does this pose a security risk (of ANY kind!) for them? For example, if someone were to get a hold of the private key of my certificate, could they use it to impersonate any other entity (like Google or Facebook or a bank) by simply signing their own certificate for those names and having it point to my root certificate, or could they only impersonate my server?
If so, is there a way to tell Windows to only use my certificate to authenticate my SSTP server, but not to authenticate any other https or other connections? Preferably, this would be an action that the users can easily take or verify rather than just some setting inside the certificate.

Unless you include your private key or something as part of the certificate package for a trusted root CA cert that you deploy to the Windows hosts; the private key would probably compromised in some other fashion.

With that said, if it is a signing intermediate or internal CA based cert; someone who captures a signing cert could use it and perform a man-in-the-middle to do 'trusted' ssl decryption on the victim network or create 'trusted' spoofed phishing sites or other malicious browser friendly content for your users.

If your self signed cert is purely a public cert for trust authentication only; in general you should be fine as long as an attacker decides not to take it and spoof your web server.

In either scenario, if this is happening in a test/dev environment for a proof of concept-- you probably have bigger problems to worry about regarding your cyber security.

If you're really paranoid about alternative authentication; you could add requirements for the clients to have a client-side certificate that your server knows about (mutual authentication) via TLS. There's also compensating controls where maybe your network security infrastructure only allows SSTP over SSL/TLS traffic to be accessed on a specific VLAN or static IP/MAC pairing.