Does SMIME differ from TLS, PGP, DMARC signature, or a Portal Encrypted email message in terms of legal non-repudiation? I'm interested in protecting email messages from NSA-style snooping, but don't want to incur additional legal risk in doing so.

In other words, does SMIME encryption and/or signing cause a given email message to have more legal "power" than a message sent over TLS, PGP, DMARC, or similar technology such as an encrypted email portal?

For example, perhaps that a SMIME certificate  has Low | Medium | High Assurance attribute embedded in the certificate; would that lower or raise the legal risk accordingly?

Q: Are there any precedents, or thought leaders that define when an email can be used in legal matters, and when not? In particular a "signed" message?

I found this post that might mean there is nothing to worry about, since non-repudiation in the computer-sciences sense is much different than a legal sense

  There is a definitional distinction between the legal use of the term
  "non-repudiation" and its crypto-technical use. In the legal sense an
  alleged signatory to a document is always able to repudiate a
  signature that has been attributed to him or her [4]. The basis for a
  repudiation of a traditional signature may include:

  The signature is a forgery;
  The signature is not a forgery, but was
  obtained via:

  Unconscionable conduct by a party to a transaction
  Fraud instigated by a third party
  Undue influence exerted by a third party

So if the

If you are afraid of "snooping" then why would you use signatures ? A "snooper" is a passive eavesdropper, who wants to see the data but certainly not to make you aware that your emails are inspected. They won't alter emails, or send fake emails, which are the kind of things that signatures can help against.

If you want to defeat such sniffing, then you need to use end-to-end encryption. This will indirectly involved signatures, but on the certificates, not on the emails themselves. To prevent a man in the middle attack, you want to make sure that when you encrypt an email, you are using the true public key of the intended recipient -- that is where certificates and, crucially, signatures from CA, enter the mix. But these signatures predate the actual email; none of them makes any guarantee as to the email contents.

Now if you want to defeat active attackers, then indeed signatures become relevant. You will want to sign your emails so that the recipient may reliably detect whether your emails were altered in transit (this works, of course, only if the recipient expects your emails to be signed, and will suspect foul play if he receives an unsigned email allegedly sent by you).

At the legal level (though it depends a lot on the jurisdiction), all the "non-repudiation" thing is about shifting the burden of proof. An email, like any piece of data, can be used as proof during litigation; whether it is acceptable in that role depends on the context, and arguments which are then produced by both claimants. Basically, one party (let's call it A) will claim that the email really originates from the other party (B) and thus its contents "bind" B in some way (e.g. contractually); the other party (B) claims that the email is fake and was forged (by A or some other miscreant). Arguments include analysis of headers and log files on all involved machines (B's desktop system, email servers...) and possibly other elements (such as eye witnesses who saw B type the email, or other things like that).

What the legal framework that some countries are trying to build are ways to define the default interpretation: namely, is the email reputed genuine by default (and then B has to find good arguments showing the forgery), or is the email reputed unreliable by default (in which case A must do all the proof work) ? Digital signatures, in a cryptographic sense, can be a part of a system (both technical and legal) which, in some countries, will put the burden of proof on the forgery claimant ("B" in my example).

(As an illustration, in Hollywood, a handshake is considered a binding "signature" for a contract, without involving any computer or even any piece of paper with some ink on it. Eye witnesses are used if a dispute arises.)

Thus, signing emails incurs a "legal risk" only if you intend to renege on the email contents, and that legal risk is increased (with regards to an unsigned email) only within a context where you feel confident that you could successfully deny having sent an unsigned email. In practice, emails leave traces in many places when they hop from server to server, so reneging on some email is already "risky", regardless of whether the email was signed or not.

SSL/TLS, in the context of emails, is used mostly opportunistically. You may have it when sending the email to your outgoing SMTP server; recipient may use it when reading his mailbox (e.g. IMAPS, or some SSL-powered Webmail); SMTP servers may try to use SSL when talking to another SMTP server. Though SSL includes signatures, these are computed over technical "challenges" related to the SSL mechanisms, and do not cover the exchanged data. In that sense, SSL-level signatures cannot "technically" be used as proof about the data contents (this is authentication, not signature).

However, legal matters do not reduce to mere technical elements. The context rules. Some may argue, for instance, that generalized use of SSL for server-to-server connections makes it more difficult for outsiders to actually intercept the emails and alter them. So one may argue (specifically, may argue in court) that SSL tends to make forgeries harder. In any case, all this SSL happens for data transit only; intervening servers still see the email "as is" and maintain their log files, which appear to be sufficient to convince judges in practice.

The best defence strategy of a claimant who wants to renege on his emails might be to assert that his own computer is under control of some malware, which sent the email without his consent or even awareness. One may note that this defence "works" regardless of whether the email is signed or not, since the malware can use your private key to sign such forged emails.

To sum up: only an analysis of the complete situation can tell you whether your "legal risk" is impacted, in which direction and to what extent, by your signing your outgoing emails with S/MIME. However, one may surmise that, usually, S/MIME signatures don't change things much for the sender. For the recipient, signatures may lower the risk substantially in the following sense: if the recipient expects millions of incoming emails (e.g. the emails are actually registration contracts for some service), then he will realistically expect hundreds or even thousands of attempts at reneging emails. Generalized use of digital signatures may be expected to streamline the litigation process, thus lowering the involved costs.

If your enemy is the NSA, then all these legal talks are completely irrelevant: legal proofs are good only when you can show them to a judge. When you wake up, tied on an interrogation chair in the basement of some secret facility in South Dakota, there is no judge to talk to...


List of upgradable softwares vulnerable to MitM attacks I was wondering, a lot of software nowadays automatically connect to a server at launch to check for updates, even basic software, and, to my knowledge, this is a new trend. Before you had to download it all again from the website.

My guess is that some of them weren't designed with security in mind and simply check an FTP or non-SSL HTTP, thus allowing a pen-tester that succeeded his MitM to easily take control over the computers, assuming the user launched the software and accepted the update.

My question, thus, is: Is there someone out there that publicly keeps a list of those vulnerable softwares?

With a little work, it could be implemented into Metasploit in the same fashion as the Browser Autopwn was for an easy, fool-proof exploitation :

redirect the query for an update
check version of software
create corrupted but working executable with higher software version
Delivery

I know that the probability of success isn't great if you only have 1 rogue update server for a tiny program nobody uses, but if you have 1 rogue update server for all of them, that could be interesting.

Second question: is there a public tool that does the 4 points described above? (i know you would have to know how to communicate with each program, and that might be time consuming, but still).

Yes, there is a public list:

CVE is searchable. Here is a search for "MITM" over the last 3 years

As to your second question, I don't see the value - think of it as an effort vs goal calculation. If I was going to go to the effort of compromising an update server or changing a route, on the off chance that an update would be required, why would I not just attack the outdated server anyway?


Should we block all plaintext authentication and require authentication over an encrypted channel? Should we configure our servers to require the authentication happen over an encrypted channel and block all methods of unencrypted, plaintext authentication over?

I recently configured my servers to disable all forms of plaintext authentication and require users to authenticate over a SSL-encrypted channel.
For example:

I disabled POP3 plaintext authentication - now users can authenticate only only over SSL (IMAPS)
I disabled SMTP plaintext authentication - now users must authenticate via SMTPS (ESMPTSA)
I disabled Exchange RPC  - now users must authenticate via SSL (HTTPS)
I disabled HTTP plaintext authentication - now users must authenticate via SSL (HTTPS), including for my website's backend, webmail and other web apps.  Users who attempt to connect via HTTP receive a 301-redirect over to HTTPS.
I disabled FTP plaintext authentication - now users must authenticate via SSL (FTPS only)
I disabled API access from external websites (payment gateways etc)

I implemented this either through server changes (e.g., the mod_security module), by blocking access to certain ports (e.g., blocking the imap port and leaving the imaps port open), or by building my own reverse proxy to enforce these requirements.

Is this a good idea?  Should everyone be disabling all forms of cleartext authentication (where credentials are sent unencrypted)?  I noticed that some hosting companies still allow plaintext authentication; why do they do that?  Should they disabling cleartext authentication, too?

The vulnerability is not in allowing plaintext authentication, but in using plaintext authentication. For instance, an open telnet service on a Unix system does not make the Unix system weak -- the people who actually use that service do make it weak.

Human nature being what it is, when a service it available, people will use it, so this is a good reason to close unprotected gates on a general basis. However, on my servers where all users are competent and trustworthy (because there is only one user, me, and I trust all my personalities), I occasionally find it worth to leave open some weak gates, because they could be useful in some situations where urgency bypasses the security safeguards: for instance, I could log in through an unprotected telnet because I trust myself for doing so only in somewhat safe situations (e.g. from a direct ethernet link) and to apply mitigation measures (such as changing my password immediately afterwards -- not a perfect measure, I know, but emergencies are emergencies).

(Your question tends to assume that the problem comes from WiFi, which is a dubious statement: believing cables to be safe, and, even more, the Internet to be free of eavesdropping beyond the WiFi access points, looks like an overoptimistic fantasy to me.)


How esignature verification process work? I have a web application in which the users will be signing an html report. I know how the digital signature authentication works. But here the user will literally be signing the document (So, Should i digitally sign the document as well?).
How to verify whether the document is signed by a valid user.

I also want to know in general how the eSignature verification process happen?

An electronic signature (in the cryptographic sense, which I'm assuming is the meaning here) is a method of attesting that the holder of a particular private key has signed the document in it's current state.  The verification of the private key needs to be handled as a separate step.  This can either be by a third party certificate authority or by some procedure to establish the validity of the public key by you.

If it needs to be legally binding, there may be additional requirements in your area and you should consult a lawyer for details about that.


Encrypting folders with flash drive key? Is there any way to have a flash drive encrypted and it will only open with one computer that has the key in it?

Install a program like PGP, and save your public and private keys to your hard drive - specifically in your own login account. Encrypt the drive. When you try to decrypt it, it will require your private key. Don't copy the keys to any other source. Many dual-key encryption methods are good for this purpose.

For the PGP example, there are whole disk versions of PHP that use key and passphrase.

More info on that topic can be found here:

"PGP Whole Disk Encryption can encrypt the thumb drive so that it is only usable on computers with the proper keys." http://symantec.com/connect/blogs/doing-more-pgp-whole-disk-encryption


MAC Spoofing - Keep victim out I have successfully done a MAC Spoofing Attack on my open (ad-hoc) network using the macchanger tool (OS: Kali linux).

I would like to know what are the common techniques to keep the connection alive (so, the way to keep the machine with the real mac out of the network) because, when I try to reconnect using the victim's machine (Windows 10), the Windows machine obviously kicks out my Kali host from the network.

MacChanger just changes the MAC. It is not meant to kick off another device on the network. The effect of having the same MAC as another device means that the 2 devices interfere with each other.

The simple way to ensure that the attacking device always "wins" the fight is to send an ARP broadcast at a faster interval than the legitimate device (e.g. every second). This way, when the legitimate device sends its ARP broadcast, the attacker quickly overrides it. Seeing these fast broadcasts is the primary way of detecting an ARP spoof attack.

To do this, you need one of the many tools available that perform MAC spoofing.


What CPUs does the Spoiler attack affect? I see on different websites different information about the Spoiler Attack. Some websites say all Intel CPUs are vulnerable and other websites say only Intel Core CPUs are vulnerable.

Are Intel Xeon CPUs vulnerable?

Their whitepaper says "The leakage can be exploited by a
limited set of instructions, which is visible in all Intel generations starting from the 1
st generation of Intel Core processors,
independent of the OS and also works from within virtual machines and sandboxed environments"

In a table of results they show a Xeon CPU being vulnerable specifically Intel Xeon E5-2670v2 and Intel Xeon E5-2640v3


How many passwords per second can a typical computer check? I wanna know how many passwords per second my computer can check this is for brute force attacks. I looked everywhere and on this website and the computer listed on here are nothing similar to the one I have. I have a i7 6500u @2.50GHz processor 16GB ram and a AMD radeon graphics card 2GB.

You can run hashcat on your computer. This is a password recovery tool, and it has a benchmark option that you can run like so:

$ ./hashcat64.bin -b


Is it safe to send an encrypted blob as a URL parameter? The context is a password reset functionality.  The user has requested a password reset, either via the web, or via a call to the help desk.
The proposed solution is, behind the scenes:

If Self-Service via the web - require the user to prove that they are the account owner by making them answer their security question
Set the password to a temporary, randomly generated password
On the server, generate an email that contains a link
The user clicks the link and is prompted to enter a new password
As long as the new password meets complexity requirements, the new password is set.

The question is, there are two options on the table for the link that is sent to the user.
Option 1: a lookup table of random tokens mapped to usernames, with an expiration.
Option 2: Encapsulate the username, temporary password, and expiration time into an encrypted blob, and send that in the email, and avoid the database
I'm concerned that option 2 is less secure.  The data may be logged or cached in proxy servers.  And even though the blob is encrypted, the fact that it is out there, potentially multiple times, increases the sample set of data available for potentially reverse-engineering the encryption key.
Am I overly concerned?  Is it safe to send an encrypted blob of data in a URL like that?  Or is that a bad practice?  If it is a bad practice, what are the compelling arguments against it?

I don't discuss the security of the password link since I see the problem with your approach even before this link is generated. Your first step after some unauthorized user requested a password reset is to:

Set the password to a temporary, randomly generated password

The problem with this approach is, that a reset of the password of a user can simply be requested by anybody. Based on your description the users password then gets immediately  set to some random value, which would immediately deny  access to the real user. The user only gets access back if it follows the sent password reset link or triggers their own password reset.
In the mean time an additional step was added to address my concerns:

If Self-Service via the web - require the user to prove that they are the account owner by making them answer their security question

This does not actually prove that they are the account owner. The actual prove for this would be entering the password, which the user no longer has. Answers to security questions instead tend to be easily solvable for others since they a) tend to be simple and b) tend to contain information which can be found on the internet (i.e. Facebook page of user etc). Also, the attacker only needs to know the answer to the security question once in order to reset the password again and again, meaning an effective DoS to the real user.
Also, there is no actual need to reset the password immediately, since the password itself is not known to an attacker. This kind of procedure was only added to make the link simpler, i.e. for technical but not security reasons. But the link can simply contain a username and expiration, signed together with a server side secret. This way the link functions as a time limited request for password change, authorized by the server. The actual changing of the password should only happen once the link was clicked and a new password set by the user.
For more recommendations on this kind of functionality see How to implement “forgot password” functionality?.


Push button in Security key used for 2FA/MFA I have come across many security keys from different manufacturers such as solokeys, yubico etc.., for the purposes of 2FA/MFA. Products vary basically w.r.t features such as USB-A, USB-C, Apple connector or NFC. But, I could not still figure out the reason for having a push button in couple of products whereas the nano products do not have that push button. So, does the push button offer extra security in any manner? or if the push button is not available, is the key open to security risks?

YubiKey Nano and Somu (the small variant of a Solokey) use a capacitive way to detect that a user touches the device. There is a small area of metal that protrudes out of the plastic casing that nearly vanishes in the USB socket.
The user presence detection is part of FIDO U2F.

In summary, the user will have to touch a button to register, and may also be warned by thebrowser. The relying party can put up screens which will walk the user through these steps.Registration is a very high value operation - it gives an origin a capability to very stronglyverify a user and it needs to be taken very seriously. During authentication (or moregenerally, whenever the online service or website needs to strongly verify the user byrequesting a signature), the user needs to activate the device to demonstrate user presencebefore the signature can happen. From version 1.2 onwards, it is possible to ask a devicefor a signature without user presence. The signature clearly indicates it was made withoutuser presence and will have to treated by the online service or website accordingly

http://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.pdf Chapter 5
Other ways exist that work by unlocking the hardware token through the Operating System by entering a PIN or by verification of biometric criteria such as fingerprints.


MySQL AES_ENCRYPT string key length In MySQL there are builtin AES_ENCRYPT() and AES_DECRYPT() functions which take the form of:

AES_ENCRYPT(str, key_str)

What length is required for the key_str argument? Can it be variable? What is the minimum and maximum string key lengths?

MySQL's AES_ENCRYPT function is insecure by default, as it uses ECB mode unless configured otherwise. The documentation provides an example of how to use CBC mode with a 256 bit key (though their example of a key is terrible):

mysql> SET block_encryption_mode = 'aes-256-cbc';
mysql> SET @key_str = SHA2('My secret passphrase',512);
mysql> SET @init_vector = RANDOM_BYTES(16);
mysql> SET @crypt_str = AES_ENCRYPT('text',@key_str,@init_vector);
mysql> SELECT AES_DECRYPT(@crypt_str,@key_str,@init_vector);

What key length you want to use depends on what block_encryption_mode you configure. Supported key lengths are 128, 192, and 256 (which also happen to be the only key lengths allowed by AES).

It can be seen here that if the provided key is too small it will be null-padded (due to the memset), and if it is too large it will xor the extra bytes with the first key_size bytes (e.g. if the key size is 4 bytes and the provided key is 12345678, it will xor 5678 with 1234 and use the result as the key). For best security you should use a random key of the size you configure AES to use. For AES-128 you want a 128 bit random key, or 32 hex characters:

SELECT AES_ENCRYPT('text', UNHEX('6133C3D40B2BF9267E85ED0C2FDDC686'), @init_vector);

For AES-256 you want a 256 bit random key, which is 64 hex characters:

SELECT AES_ENCRYPT('text', UNHEX('08672D4D2424CFE10E5221BF2EB8409C57431B30B55D6AE2D167E5F9682EF711'), @init_vector);

The MySQL documentation fails to note that the IV (initialization vector) must not be reused for multiple encryptions, and of course the IV must be stored to allow for decryption.

It should also be noted that none of the encryption modes that MySQL
supports provide authenticity, and of the supported modes, ECB is terrible and CBC, CFB, and OFB are all malleable.


SELinux vs. Antivirus I am working with an enterprise network with sensitive data nad am not sure if I should use SELinux or an Antivirus for the Servers, POS Terminals, and Desktop Machines.

I need to know what the difference between SELinux and antivirus is, the functionality in selinux that is better than antivirus, embedded features, and if it can replace an antivirus program

Should you use SELinux or an antivirus?  Yes.  SELinux and an antivirus perform complementary tasks, so using both is better than using one or the other.

An antivirus is a tool to find known threats.  It can look at a file and say "this is a virus", but it can't look at it and say "this is not a virus" -- the file might contain a previously unknown threat.

SELinux is a fine-grained permission system.  It can do things like enforce a rule of "the web sever cannot write to directories outside its dedicated storage area" -- this greatly limits the damage an attack can do, but does nothing to prevent you from running an infected program in the first place.

The two work together: the antivirus stops known threats, but can't deal with unknown threats, while SELinux limits what an unknown threat can do, but wouldn't recognize a threat if one bit it.


List of New Metasploit Modules I would think that this would be an easy thing to find, but it there a running list that someone maintains that shows new Metasploit modules as they are released?  One thing that I do is keep an eye on the Metasploit Framework page on GitHub, which is useful, but not exactly what I am looking for.

is there a running list that someone maintains that shows new Metasploit modules as they are released?

For that i think you want something like https://www.exploit-db.com/,

This will have a very up-to-date view of exploits recently made public, sorted by type.

New Metasploit modules will be in there as well, but that's just a small part of the exploits that are publicly released. Also using these will make the step from using just msfconsole to finding security holes yourself easier.

As mentioned, https://www.rapid7.com/db/modules/ Will have a comprehensive list of all previously released modules.


Is it ok from the viewpoint of PCI DSS to send credit card info to my own server which then directly sends it to PayPal? Currently I'm developing an iOS application which has an option to pay an order (clothes cleaning) via scanning credit card info using device camera. I can't use Apple In-App Purchases (IAP) for this, because it is a physical good not a virtual one:

  11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected

These payments are future payments in the PayPal terminology, so I can't charge user's card immediately. Unfortunately, current version of the PayPal Mobile SDK doesn't have an option to use a credit card for this:

  When you integrate your mobile app with PayPal Mobile SDK 2.0, your customers can give permission to be billed multiple times in the future without logging into their PayPal account. PayPal payments (not credit cards) are supported.

So I implemented next approach: an app scans user's card and then I send scanned PAN/ccv/owner's name/expiration date via HTTPS (SSL) to my server, which,in turn, sends them directly to PayPal to obtain an OAuth token for future payment. I don't store this info anywhere.
In the 4.1 and 4.2 paragraphs of the PCI DSS spec I saw:

  " Never send unprotected PANs by
  end-user messaging technologies"

But in my scenario it is not an end-user messaging technology. PCI DSS says that if the browser uses SSL it is ok to send data through it:

  Requirement 4: Encrypt transmission of cardholder data across open, public networks

As I understood there is no difference what client i'm using: browser or mobile app if I encrypt my data, right?
 My question is this process a valid one or my app violates some rules of PCI DSS?

Your PAN data is encrypted in HTTPS and meets the requirement as long as your API is sending via HTTPS and using TLS. SSL is no longer supported as of PCI 3.1. In June 2016, TLSv1.0 (and possibly TLSv1.1) will no longer be supported either. That being said, your server is the area of concern for most PCI auditors. The server has the ability to read and decrypt the data for processing. You will need to review the large list of requirements for systems where cardholder data is stored. One of the areas you will definitely need to address is the following:

Technical Guidelines for Protecting Stored Payment Card Data At a
minimum, PCI DSS requires PAN to be rendered unreadable anywhere it is
stored – including portable digital media, backup media, and in logs.
Software solutions for this requirement may include one of the
following:

One-way hash functions based on strong cryptography –
also called hashed index, which displays only index data that point to
records in the database where sensitive data actually reside.
Truncation – removing a data segment, such as showing only the last
four digits.
Index tokens and securely stored pads – encryption
algorithm that combines sensitive plain text data with a random key or
“pad” that works only once.
Strong cryptography – with associated
key management processes and procedures. Refer to the PCI DSS and
PA-DSS Glossary of Terms, Abbreviations and Acronyms for the
definition of “strong cryptography.”

See: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf


How to properly configure OSSEC for Web Application Security ? I would like to implement OSSEC as HIDS on my server, but by default OSSIC monitors a number of folders. I am going to deploy a web application on my server. So what should be my default OSSEC configuration for web application security  i.e. folders,logs to monitor for intrusion detection?

You might want to include folders which contains your application. Should an attacker be able to exploit your server chances are they will write a file to your web root.


Can you cut up frames/packets and combine them anonymously? Is it possible to somehow cut up a packet and send it from multiple IPs into parts and send them to one IP address to reconstruct a semi-anonymous packet/frame?
Can frames have their source faked?
Does this somehow relate to the Tor network?

Yes, you can mask the source IP

Nothing stops you from writing a false source IP address, just like nothing stops you from changing the "From" field on a letter. In fact, IP packets and letters are remarkably similar.

  What happens if I change the source address?

The answer is quite simple: You will not get a response. The IP address in the source address will get a response. This technique is used in some DDoS attacks to mask the origin of the attack, or to cause the server to reply to the server you actually want to attack.

  Can this be stopped?

Yes, in a remarkably simple way. Imagine you live in New York and go to a local post office, wishing to send a letter to France. As the sender's address, you state "The White House, Washington DC". It's very likely that an attentive postal worker will reject your package (and possibly notify authorities, but that's beside the point).

How could the postal worker know it was fake? Because the postal worker knows which "Source Addresses" are legitimate - namely those from New York. Any source address outside of that will be rejected. Network Ingress Filtering is a technique that works the same way.

ISPs know the range of addresses they hand out (e.g. 203.0.113.0/24, so 203.0.113.1 to 203.0.113.254), so any IP packet coming from that network with a source address in this range will be accepted, and the rest rejected.

About the other questions

  Can you chop up an IP packet and send it from multiple IP addresses?

Yes, this is actually done regularly by routers all over the world. It's how the internet is designed to work. It also doesn't give you any kind of anonymity, because the Internet Protocol wasn't designed to be anonymous.

For further reading, Wikipedia has an excellent article describing IP Fragmentation.

  Does this somehow relate to the Tor network?

No.


How can crackers reconstruct 200k salted password hashes so fast? I'm researching for a small talk about websecurity and I found one article about the formspring hack, which made me curious. They claim to have used SHA-256 + salt

  We were able to immediately fix the hole and upgraded our hashing mechanisms from sha-256 with random salts to bcrypt to fortify security (July 10th, 2012)

… nevertheless the attackers claimed they have found ~200k passwords within the 400k published datasets (They have 11m users, it's IMHO likely that most of them have been copied).

  About half of the 400,000 hashes have already been reconstructed by password crackers. (July 11th, 2012)

This looks suspicious to me. I know that without using PKCS#5 or similar techniques, the security of SHA-256 is limited, but how much calculation power would they need to find so many passwords so quick?

My guess is that formspring was lying about the hashing. Has someone some insights on that?

None of the existing answers cover the critical part of this question to my satisfaction: what about the salts?

If just the password hash values were posted, other crackers can't possibly know:

The actual per-password (supposedly random, per the source) salt value.
How the salt is mixed with the password in the code.

All they have is the final, resulting hash!

There are lots of ways the password and salt can be combined to form the hash:

sha256(pass + salt)
sha256(salt + pass)
sha256(sha256(pass) + sha256(salt))
sha256(pass + sha256(salt))
sha256(sha256(...(salt + pass + salt)...))

But if the salt is the recommended 8 characters of pure randomness …

sha256("monkey1" + "w&yu2P2@")
sha256("w&yu2P2@" + "monkey1")

… this means a "typical" 7 or 8 character password becomes extremely difficult to brute force, because it is effectively 15 or more characters! Furthermore, to crack password hashes that you know are salted, unless you also have the salt, you have no other choice except brute force!

Based on research I did using GPU cracking, I achieved 8213.6 M c/s using two high end ATI cards brute force cracking MD5 password hashes. In my benchmarking this meant I could try:

all 6 character password MD5s   47 seconds
all 7 character password MD5s   1 hour, 14 minutes
all 8 character password MD5s   ~465 days
all 9 character password MD5s   fuggedaboudit

Note that SHA-256 is 13% of the speed of MD5 on GPUs using Hashcat. So multiply these numbers by about 8 to see how much longer that would take.

If the salts were not known, that means you're essentially brute forcing the equivalent of 12+ character passwords. That is far beyond the realm of any known computational power.

Now if you want to argue that …

The original crackers also obtained the salts, but chose not to post them.
The original crackers also have the source code (or it's open source) so they know how the passwords are salted, but chose not to post that information.
Formspring is lying and their passwords were not salted or salted improperly such that the salts had no effect.

… then yes, cracking 200k of 400k password hashes in a few days is easily possible.


Is docker for desktop secure for non-admins? I manage a multi-user workstation (Windows) server for a small student organisation. One of the students asked me to install docker, as it would simplify his workflow. As this is on a shared workstation, I'm concerned about security. On linux, if you have access to docker, you effectively have root permissions. I am aware that docker on windows has two backends; WSL2 and Hyper-V. I am considering the latter as the OS is Windows Server 2019 (no WSL2) and we have already several VMs. I will probably upgrade to 2021 in a few months after it is available.
I have read, that docker for desktop is by defult for admins only, but I could not find a reason why that is. I intend to create a docker group and allow only specific non-admin users. I assume that any program breaking out of docker inside the VM has no access to the host OS itself. My next assuption is that Windows permissions are enforced when mounting/sharing a folder to a docker container.
Is it secure/good idea to allow docker in this environment?

Allowing unrestricted Docker commands on a host from (relatively) untrusted users is likely to be a cause of problems, as it allows for access to the underlying host OS.
One example is file mounts. Using Hyper-V Windows containers, the user on the host used to check for permissions is LocalSystem , so any directory that user has access to can be mounted inside a container (more info. on windows container permissions here
It's also possible to get access to hardware from Docker in Windows, based on the docs here.
One option might be (assuming your users want to run Linux containers) to create a Linux VM for the user manually on your Windows host, and then provide them with access to Docker running in that VM, either by given them SSH access to the VM, or by putting the Docker client on the host machine and connecting over SSH


Can one trace downloads in storage unit? Does My Passport WD keep a history of downloads, transfers etc? In other words can user A detect user B's activity? Or can it just see the content of the storage unit?

It depends on the type of device

First and foremost, the kind of information you can recover depends on what kind of device and how that device is used. For instance, a USB attached drive has very different information than a NAS solution.

USB Attached Devices

USB Attached devices are treated as a typical disk. The forensic information you could recover from the disk could include access or write times, but a detailed log indicating who did what probably does not exist.

Network Attached Devices

If the device attaches over the network over WiFi or Ethernet, it may be using a webserver to serve the files. In the case of a webserver, there may be logging information that indicates if someone logged in and what files were downloaded. Whether or not you can get access to those logs (if they even exist) will depend on the device.

Some devices use SMB to share over the network. They also may log authentication details, but you may have to rely on filesystem forensics for information about when and what data was read.

If you can perform a packet capture against the network device, this will likely tell you what files were downloaded and by whom (assuming they have to log in or you can determine who a user is based on IP). However this is a step that has to be taken ahead of time.


Any practical Single Sign-On (SSO) protocol/traffic analysis tool/method/analyzer? I want to analyze the SSO protocol/traffic that is deployed in real environment, such as commercial website. The challenge is that most of them are black-box.

Scenario 1. I read several papers about SSO analysis. Most of them developed own SSO traffic analyzer, which can turn SSO-related HTTP traffic into human readable format. But they normally do not explain technical details and publish their tools.

Scenario 2. Another method someone advised me here is to analyze through web browser debugger. But the challenge is that: 1. the HTTP traffic shown in debugger is not human readable; 2. too many HTTP traffic to focus SSO related only.

Scenario 3. I tried several browser add-on, such as SAML Tracer (chrome) and SSO Tracer (firefox). It was useful to trace SSO traffic in demo website only, but failed in commercial websites, such as Google/Facebook/Yahoo-login enabled websites (SSO service providers for openid/saml IDP).

My questions are:

What is the reason for scenario 3?
Please suggest practical methodology to analyze SSO traffic.

Here is the presentation on SSO theory -- [PDF] https://www.compass-security.com/fileadmin/Datein/Research/Praesentationen/area41_2016_saml.pdf [PDF] -- that introduced the SAMLRaider BApp for Burp Suite -- http://www.toolswatch.org/2015/12/new-tool-saml-raider-v1-1-1-saml2-burp-extension/

Another great BApp for Burp Suite, SAMLReQuest, is detailed here -- https://www.insinuator.net/2016/06/samlrequest-burpsuite-extention/

This author went into detail for an XXE security bug found in a SAML app -- https://seanmelia.wordpress.com/2016/01/09/xxe-via-saml/ -- but I really enjoyed this post from the SendSafely and Gotham Digital Science teams -- https://blog.sendsafely.com/web-based-single-sign-on-and-the-dangers-of-saml-xml-parsing


How does session timeout work? I am using Ticket based session resumption. I need to set Lifetime of Session Ticket. So, that i am using OpenSSL API to set the timeout to session.

SSL_CTX_set_timeout(ctx,500);

after 500 seconds, established sessions will close the connection ?
or
After 500 seconds, session is not reused ?

Please help me out.

I think the documentation answers your question clearly. To cite:

  ... If the actual time is later than creation time plus timeout, the session is not reused.

Thus, it is only about reusing the session and does not have any impact on a currently running session.


openssl - difference between passphrase (-k) and key (-K)? I'm using openssl for a project and came across two options: -k passphrase and -K raw_key (hex). What's the difference between the two options? I've been attempting to port something from openssl to Python, and the openssl command I'm using for my basis uses -k [32-bytes_of_hex_data], which yields an entirely different key is I use the -p switch to see the key being used.

A quick look at either the enc man page or the enc wiki page tells you the answer:

-k password
The password to derive the key from. This is for compatibility with previous versions of OpenSSL. Superseded by the
-pass argument.
-K key
The actual key to use: this must be represented as a string comprised only of hex digits. If only the key is specified, the IV
must additionally specified using the -iv option. When both a key and
a password are specified, the key given with the -K option will be
used and the IV generated from the password will be taken. It does not
make much sense to specify both key and password.

The key is the raw key used for encryption and should be combined with the -iv flag to specify the IV as well.
On the other hand, a password is used to derive the key and IV. How it does so can also be configured through various flags (see -iter, -pbkdf2, -salt). You should also read the Notes section of the man page for more details and recommendations.
The default digest used to generate the key is sha256 as of openssl 1.1.0 (see history section of the man page) but used to be md5.


Can I simply search-replace ? I'm running a comment system, and I want to accept regular, un-formatted text.

I don't want anything too complicated, so I thought of just searching and replacing all < to space (through regex or a simple for loop), so <script src="http://malicioussite.com"> would just appear as script src="http://malicioussite.com".

Is there any reason not to do this?

Can a hacker still get away with a XSS?

Replacing < and > characters isn't enough in all cases. Sure, it will prevent any user to open a HTML tag, but that won't prevent him/her to inject HTML attributes in a HTML tag.

For example, let's take a parser which transforms [img=XXX] into , only replacing < and >.

A malicious user could enter [img=X" onerror="alert(1)] and the parser would return:

And the alert will prompt, meaning that a XSS attack is possible.


Charge only in Android In older versions of Android, when connected via USB the default behaviour was "Charge Only". This allowed the device to charge via USB without exposing its file system to the device providing power, often a computer.

In newer versions, this security feature seems to be missing, introducing a vulnerability whereby the file system is now exposed to the powering device.

Is there a way to re-implement this "Charge Only" security feature so that the Android's file system remains hidden or encrypted even when connected to a computer via USB for power?

I have found the answer to my own question on another stack question:

https://stackoverflow.com/questions/11698979/how-to-change-android-usb-connect-mode-to-charge-only

The Solution

Go to Settings
Select Storage under Device
Select "USB computer connection" from the drop down menu
Disable MTP and PTP


Firewall Packet Filter Query I was reading about firewalls and I have this query.

Is each firewall a packet filter? Why or why not?

I know that the first generation of firewall's were essentially packet filters, but how does it work now?

Thanks

A firewall is just some device or software which filters the network traffic. This can be done at the packet level (usually called packet filter firewall (PFL) or layer 3,4 firewall) but also at the application level (usually called application level firewall (ALG), secure web/mail gateway (SG, SWG...) or similar). You'll often find both PFL and ALG technologies in modern firewalls, i.e. some filtering is done at the packet level and some at the application level.

With a packet filter the filtering is done based on properties of the packet at layer 4,3 or even 2 (i.e. Port, IP, Mac). With application level firewalls filtering is done on the content of the application layer, i.e. URL, type of the content etc. For example pure packet filters cannot block malware by its content while application level filters can do it. But pure packet filters can block download of the malware if the IP address (not hostname!) is known to propagate malware and thus communication with this IP address can be simply denied.


Hashing length for storing password Does larger hash size improve the security? Is it overkill to use 512 bit hash?

If I stored only 256 bits of the PBKDF2-SHA512 derived key, is it less, equal or more safe than 256 bits of PBKDF2-SHA256?

Edit:

Is the hash size only used to avoid hash collision, or does it improve security?

Is it secure if I only stored part of the hash (say the first 128-bits) of SHA-256 or SHA-512?

A larger output length makes it stronger, up to a certain point which is already reached, by a large margin, when you have a 128-bit output. Enlarging it any further does not change security.

Details: barring any structural weakness, the security of a hash function depends on its resistance to generic attacks (aka "luck": attacker tries random inputs until a match is found), and that resistance depends on the hash output size. For a hash function with an output of n bits, it takes effort 2n for the attacker to find a preimage (i.e. some password, not necessarily the "real" one, which matches the output). Efforts beyond about 280 are too far away into the technologically infeasible to be envisioned by an attacker. At 128 bits, you already have a 248 margin, i.e. a factor of almost 300 thousands of billions over that which was already overly expensive. It would be like boasting about reimbursing the US national debt while not having more than 0.01$ in cash.

Larger output size also help against collisions; there again, the generic luck-based attacks have cost 2n/2 (and there you see why SHA-1 has a 160-bit output: to make the collision cost of 280 unreachable). However, collisions are not an issue for password hashing. The ability to compute collisions does not give any advantage to the attacker. It so happens that collisions are also infeasible with usual hash functions, but if they were feasible it would not be that much a problem.

The real weakness in password hashing is not the hashing; it is the password. Or, more accurately, the human mind behind the password. Successful attacks on hashed password are attacks which try potential passwords, not attacks which work on the hash function structural weaknesses, if any. Mitigations include slow hashing and salting, which is what PBKDF2 does.

You can store only 80 bits or so of PBKDF2 output (and the salt); things will still be safe. (For purely aesthetic reasons, make it 128 bits: these computer people, they just love powers of two.)


Centralized brute force login detection using netflow data Is brute force login detection feasible with netflow data?
With the netflow data one could check the number of incoming packets to a specific destination port (for each flow). If the number is below a service-specific (SSH, FTP etc.) threshold value, there probably was an port scan or failed login from that source IP address.

Does anyone have experience with this or is there an alternative to establish a centralized brute force detection. It's about protecting a few hundred Linux hosts running different services accessible from the internet (SSH, FTP, HTTP, SMTP, IMAP, POP3).

Fail2ban is already in use but a centralized solution should also be installed.

This sounds like a very inefficient method, mostly because in netflow data you're lacking a lot of information. You only have source and destination IP's, protocols and (if relevant) port numbers, so there's no real way to distinguish valid requests from invalid requests, you're missing the payload for that, which is not available in netflow.

What you're describing are just assumptions on ways to detect attacks on some characteristics, which will most likely lead to a lot of false positives and missed attacks.

You need the payload to see what exactly the request was an IP address was doing. And since that often will be TLS, you need to look at end points where TLS is terminated.

If you don't have it, look into aggregating your fail2ban logs and deploying bans for IP addresses from identified attackers from those logs to all your machines.


Why are cryptographic algorithms implemented in the data-link layer in wireless networks? Could someone please tell me why cryptographic algorithms are placed in the data-link layer for wireless networks?

Though the OSI model is more often a source of confusion than enlightenment, it is here reasonably informative. The WiFi encryption occurs in layer 2 ("data link") because it strives to embody a security feature which is inherently related to the data link.

Namely, WiFi was designed to be the over-the-air equivalent of wired Ethernet. In Ethernet networks, there is a physical isolation between systems which are physically connected to one of the wires, and those who are not. This can be viewed from a security point of view: if you can prevent physical access to the wired, e.g. by keeping the wires inside a building and locking the doors, then you can keep out intruders from your local network. Since WiFi is radio-based and radio waves tend to propagate freely (that's their point), something was needed in order to provide something equivalent security-wise, and that something is encryption (whether it was done properly is another question).

Since the security feature (keeping the local network out of reach of attackers) is bound to the local network (hence "layer 2"), it made sense to use encryption in the layer 2 as well. This has the additional benefit of being immediately compatible with whatever protocols are used for layers above it; in plain words, as long as the WiFi card driver is aware of the encryption, nothing else in the host operating system, in particular its TCP/IP stack, needs be modified in any way.

(This is not entirely true because the connection management system has to happen somewhere -- the user must enter the WiFi password at least once -- but this again can be contained. The first WiFi cards and drivers for Windows did all the job without the Windows ever becoming aware that such a thing as WiFi ever existed.)

Putting the crypto at some upper layer would be possible, but that's another model. This basically means forfeiting the link-level security, using it as if it was some hostile playground, and adding crypto algorithm (e.g. IPsec) to the TCP/IP layer in order to restore some sort of security. That's exactly what happens when someone connects to an open WiFi in a restaurant or hotel, and then fires up his VPN to connect to his office network, or simply uses only HTTPS Web sites.


Concerned with Tails vulnerabilities Regarding this: http://www.forbes.com/sites/thomasbrewster/2014/07/21/exploit-dealer-snowdens-favourite-os-tails-has-zero-day-vulnerabilities-lurking-inside/

Apparently, even the version of Tails released yesterday contains critical 0day vulnerabilities potentially compromising anyone's anonymity, which are sold by Exodus Intelligence.

I am no security expert, only just now starting to take my online privacy seriously, so my main question is: Is using Tails any less secure than carefully building my own privacy-focused stack to boot from USB or use in a VirtualBox, or is a combo of software I choose myself just as likely to contain such vulnerabilities?

Furthermore - is my stack any more secure if I throw in a VPN?

Thanks!

First, a word on security: Security does not exist in a vacuum; it is completely dependent on the circumstance.

Defending against an unrealized threat is wasteful. Not defending against a trivial attack renders your system useless. As such, blindly adding security measures is an exercise in futility. One must have a well-defined set of goals for a system, also known as a threat model.

If you intend on achieving "online privacy," you should define your own threat model. Some questions to ask yourself:

Who is your adversary? (Are you defending against script kiddies? The NSA?)
What behavior do you intend on keeping confidential?

What about the system you would use to address this model?

What compromises are you willing to make to keep your behavior confidential?
What are the constraints on your solution? (e.g. time, budget, hardware, etc.)

Now that you have defined the boundaries of your problem and those of your solution, you need to determine what portion of this you can fulfill and at what cost. Here is where your question comes in:

  Is using Tails any less secure than carefully building my own privacy-focused stack...?

This is ultimately about the tradeoff between threat coverage and cost (your development time). Essentially: What security do you gain from cobbling together a secure live OS that you wouldn't have with a product like Tails (and vice versa)? Your proposition is that a system you design will either 1. Have fewer bugs/exploits and/or 2. Have fewer known bugs/exploits.

First, it is entirely possible (albeit unlikely) that, at any one point in time, a system you have built with publicly available "blocks" will have fewer bugs than an open-source system already in use. The benefit of FOSS is that many eyes on the code means a higher likelihood that a bug will get discovered AND will get patched. Code that you write will inevitably have bugs which you will be much less likely to catch unless you spend your days reviewing source (even then there may be some issues even you cannot spot).

Addressing the issue of known bugs, "rolling your own" system is essentially security through obscurity (or, perhaps more accurately, security through minority), that is, relying on an attacker's unfamiliarity with a system to ensure its security. In general, this does not represent a marked increase in security, certainly not if you use FOSS building blocks.

The Tails project itself is actually quite similar to the "combo of software" you describe. Quoting directly from Tails' Contribute page:

  ...We try not to reinvent the wheel, and we flee the Not invented here syndrome like the plague. Very little code is actually written specifically for Tails...We glue existing pieces together.

This underscores the inherent tradeoff in developing a security system: Each line of code and each new design decision increases the likelihood of a bug being introduced.

While it may be tempting to read about these 0day revelations and say "I could do this better," it is important to realize the benefits that accompany widely available, open-source tools. If you aren't willing to put in the time and effort required to develop and maintain an entire secure OS (a daunting task for a large team let alone a single developer), then you might consider adding another set of eyes (read: yours) to an existing project. But that's just my 2¢.


My college is forcing me to install their SSL certificate. How to protect my privacy? My college administration is forcing us to install Cyberoam Firewall SSL certificate so that they can view all the encrypted traffic to "improve our security". If I don't install the certificate than I won't be able to use their network.

What are the ways I can protect my privacy in such a situation?
Will using a VPN be enough to hide all my traffic or there are other ways?

Don't install their certificate on any device/OS installation which you ever want to use for private activity. Once you do, your traffic is subject to MITM attacks even if you are not using your college's network. Such an attack requires having the private key for the certificate you installed, but in practice this is quite easy because these "security products" are so badly designed, and often use either very weak key generation or use a fixed private key that's the same for all deployments and available to any of their customers. In a comment that's since been moved to chat, TOOGAM wrote:

  Specific problem known about this specific vendor's certificate  "It is therefore possible to intercept traffic from any victim of a Cyberoam device with any other Cyberoam device - or to extract the key from the device and import it into other DPI devices"

If you don't need resources on their network, just use wifi tethering on your phone or get a dedicated 3G USB dongle or similar for use when you're on campus. Alternatively, if non-HTTP traffic is not subject to the MITM, you may be able to use a VPN without installing the certificate. In this case, just get a cheap VPN provider or VPN to your home network if you have one.

If you do need access to resources that are only available from the campus network, install another OS in a virtual machine with the MITM CA installed only in the VM, and use the browser in the VM for accessing these resources.


Protocol(s) for Keyless Remote Encrypted Storage? Given the following assumptions:

A server's availability is implicitly trusted, but it is not trusted to keep data private (for reasons such as having questionable security or being suspect to government warrants).
The client software is implicitly trusted (for instance, due to being open source software, possibly developed by a third party).
The communication between the client and server is trusted to be private (for instance, due to being encrypted by TLS).

Are there any security primitives that allow a client to supply a password instead of an encryption key in order to appropriately secure encrypted data that's stored on a remote server?  Is it secure for the client software to XOR a data encryption key with a hash of the user's password for the server, then to store the result on the server in order to later regenerate the original encryption key?  If this (either in general or though the outlined process) is inherently insecure, what makes it insecure?

Since the server is not trusted to keep data private the data have to be encrypted and decrypted locally at the client and the server should never have access to the key used for encryption. And since only already encrypted data are exchanged with the server this way it would not even matter much if the transport is secure or not.

Methods to derive a key from a password exist and called key derivation functions. The functionality of locally encrypting and decrypting data exists already in a variety of application and many of them open source too. Examples are GPG and Veracrypt.


How does HTTP Basic Auth persist across pageviews? I am familiar with the basic workings of HTTP Auth, but how does it keep track of authentication between page views? I see there is no cookie created when the initial authentication takes place.

To quote the Wikipedia article on this:

  Because the BA header has to be sent with each HTTP request, the web browser needs to cache credentials for a reasonable period of time to avoid constantly prompting the user for their username and password.

So it seems your browser takes care of this for you.


Is encrypting and subsequently sending a known clearext string after a Diffie-Hellman bad design? I'm writing a small protocol that relies on a DH handshake, generation of a shared secret, and subsequent AES encryption/decryption using that generated secret. I want to add a built-in test message after the handshake to ensure both clients are able to communicate properly (in addition to a CRC). Is building a small "TEST123" -encrypt-> ciphertext -decrypt-> "TEST123" into the protocol a security vulnerability, since someone now knows the ciphertext for some given plaintext?

Designing your own protocol for something secure is generally a bad idea.  Don't roll your own.

It's probably not a significant weakness.  It does expose yourself to a known-plaintext attack, but luckily AES is secure against known-plaintext attacks.

Granted, using a CRC to test that communication is working properly is not a good idea (unless this is only done at a network layer on the sent ciphertext), as CRCs aren't cryptographically secure.  You really should use a keyed-MAC to prevent tampering (and sequence numbers/timestamps to prevent replay attacks).


Risks of using GET param for Auth I am currently developing a tiny web app. Since username/password would be too much of a overhead I am thinking of a GET param for authorization and authentication.

Example: funnydomain.rocks/lol?secret=some_random_hash

Just to be sure, I am not asking if this is secure, since it is not. I am asking for the risk of using it. How big is the chance that someone else will use this to "login". I am fine with recovering my database once a year and changing the hash for each user. Much less effort than using username/password, especially with my kind of users...

Assumptions:

limited amount of users (no more than ten)
each user receive its own hash
SSL is used
URL and secret will be bookmarked in several browsers (and saved in some cloud services)
d̶a̶t̶a̶ ̶i̶s̶ ̶n̶o̶t̶ ̶w̶o̶r̶t̶h̶ ̶p̶r̶o̶t̶e̶c̶t̶i̶n̶g̶  data is not critical

If you're using HTTPS/SSL and you trust your endpoints, this is fairly secure for your purposes, because the get parameter will be encrypted as part of the query string, so traffic capture is not a problem.

The "secret" hashes will most likely end up in the web server logs of the web server which servers your web application, but if you control these logs, then for your level of desired security that's probably a non-issue.

You'll obviously  also have to trust all the services which store these URLs (browser bookmarks, cloud services etc, but you seeem to be fine with that). I'd think the greatest risk was here (e.g. one of your users logs in using a public computer, and the next user of that public computer looks at the browser history, clicks the link and has access to your protected data).

If you're using unencrypted HTTP, your secret hashes will also end up in proxy server logs and basically anyone who can eavesdrop on your connection will have tons of chances to capture the secrets.

However, I'd only do direct GET param authentication if I really didn't care much about the secrecy and integrity of the data the secret hashes are supposed to protect (basically if I wanted to keep the hordes of stupid vandals at bay, but didn't think any determined person might be interested enough in my data to try to access it, and didn't have a problem if it turned out I was wrong).

A very simple way to considerably improve the security of your authentication scheme would be to have the secret tokens expire, or even better yet, to treat them as one-time-passwords. Give each user a list of tokens, to be used one after the other. This doesn't require much code on the server side and solves the problem of one of your users accidentally leaving/publishing his secret token somewhere.


BitLocker Drive Encryption NOT secure from drive mapping on network I have a USB drive encrypted with BitLocker Drive Encryption. Each time I insert the drive in my USB port it works as expected, requires me to enter the password.

Maybe I have the BitLocker Drive Encryption configured wrong or something not sure but, after inserting the USB drive and entering my password I can go to a completely different PC with a different network ID etc on the same network I'm able to see everything on my thumb drive. Not only can I see everything from other PCs I can write to it delete etc.  I thought it would have required me to enter my password when I mapped to it from a different PC.

Can anyone explain why other PCs can map to my encrypted drive and have full access to everything?

You’re misunderstanding what BitLocker is supposed to protect against. The goal of BitLocker is to protect your data from cold boot attacks (as explained in a Technet blog entry).

When you unlock a volume protected by BitLocker, the system gains access to the keys necessary to decrypt the drive and behaves as if it was a regular drive.

That is necessary to make the system compatible with any and all applications (and drivers) without requiring them to know about BitLocker. (That’s why it’s called transparent disk encryption: applications and drivers don’t see it.)

This means you’re free to share the volume over the network and, if you carelessly apply no kind of ACL restriction on who can access the data, then everyone can access it freely.


Forward secrecy for kids In the Scouts, it is popular to use secret codes to write messages (which are simple ciphers).

I want to introduce Forward secrecy to the kids so they can use it with these ciphers. So, if the competing team found a ciphered message and decoded it successfully they can't decode old messages too.

My question, how can I do any of these simple ciphers with forward secrecy?

What you describe is not forward secrecy.

Forward secrecy relates to the following property: a secured communication took place between entities A and B at some time T; the attacker recorded all the messages; at some later time T' the attacker obtains a copy of all the secret keys known to A and B; and yet, the attacker cannot recover the contents of the communication which occurred at time T. To achieve forward secrecy, then the following must hold:

Each communication (say, each individual message in a mail context) uses a specific encryption key that sender and recipient do not keep around. This necessarily entails some generation mechanism, with randomness.
It does not support stateless one-way emailing. Indeed, if the complete communication between two scouts is a single message from scout A to scout B, then this means that B "knows enough" to process the message and recover the contents. Unless B forces himself to forget what he once knew (i.e. is not stateless), B could do this feat again; and so can the attacker if he obtained all of B's secrets.

If two-way communications are possible (e.g. as with a SSL connection, with the initial handshake), then a key exchange algorithm like Diffie-Hellman can be used to produce a communication-specific session key, used only for the duration of the connection, and discarded afterwards. Any long-term secret known to both scouts will be used only for mutual authentication.

Since scout messages are one-way, and the average scout won't compute a 1024-bit DH key exchange anyway (he could: all these youngsters nowadays have smartphones, which are entirely up to the task; but I understand that is not the pedagogical point), this kind of solution cannot be used.

Instead, the solution is to make the scouts stateful. The model, here, is that of the One-Time Pad: make it so that sender and receiver share a long sequence of secrets, which they store on some physical medium such as a booklet. When they use a key (say a booklet page) for sending or receiving a message, they destroy it. Therefore, an enemy seizing the booklet after the fact will not obtain the key, and thus won't be able to decrypt a past message.

This is the historically correct solution; in the pre-computer era, field agents used OTP. Scouts can only be thrilled by using the exact same method as real spies and armies used for decades. Extra points for making the booklet in an edible material, so that destruction after usage is fun, easy and safe (the average scout would also find it quite fun to simply burn down the paper, but that might create environmental hazards). Further extra points for walking the scouts through cryptanalysis when OTP was badly used, i.e. the pad has been reused.

Forward secrecy is about what happens when a field agent is seized by the enemy, and forced to reveal his secrets. The scenario you envision is different: no secret forcibly revealed, but a passive decryption which occurred in an unspecified way (e.g. a lot of guesswork from a partially known plaintext). The property you describe (decrypting one message does not reveal other messages) only means that the encryption method is robust against known-plaintext attacks: even knowing some cleartext and the corresponding ciphertext is not enough to enable decryption of other ciphertext, and, in particular, is not enough to rebuild any keying component which is reused for other messages.

Pen-and-paper ciphers are usually weak, although some can be quite strong when the attacker only has a pen and paper too. See this question for suggestion and links.

One-Time Pad is the exception: it is computable with very low computing power, and yet is ultimately robust against known-plaintext attacks, because no employed keying component is reused for another message or message part.

Summary: use OTP. It provides the property you want; it also provides forward secrecy. It is pedagogical, and amenable to enlightening historical reconstruction.


ikev2 handshake : 4 or 8 packets? I open wireshark to inspect the ikev2 handhsake and noticed it is 8 packets instead of 4. Two groups of 4 packets, one originating from the first peer and the other from the second peer. Is it normal ? Shouldn't it be one 4-packet exchange only ? (note : i am using tunnel mode esp)

To quote cisco.com,

[Unlike IKEv1] the IKEv2 exchange is variable. At best, it can exchange as few as
four packets. At worst, this can increase to as many as 30 packets (if
not more), depending on the complexity of authentication, the number
of Extensible Authentication Protocol (EAP) attributes used, as well
as the number of SAs formed.

So, eight packets is within acceptable range for an IKEv2 negotiation.


How to not reveal that you are using PHP? I'm bulding a website but some webtools and browser plugins allows anyone to get information on which technologies the website has been built. Is there any Alternative to not reveal that we are working on server that process php ?

Don't provide any information to anyone unless its absolutely necessary.

You should set expose_php=off in your PHP.ini.  This tells PHP not to expose the "x-powered-by" HTTP header as well as the strange quarks that can be used to identify it.  You should also set display_errors=Off which could be used to identify PHP as well as error-based vulnerabilities like SQL Injection.  These two configurations should be used on all production systems. You can go a step further and remove or change the .php extension with mod_rewrite.

This is along the same lines as "banner information disclosure",  which is revealing version information via service banners.  You should be able to configure your HTTPD to suppress this information. In an Apache production environment set ServerTokens ProductOnly (thanks tftd).  But this will just remove the version number, if you want to remove the word "apache"  you have to use mod_security.

You could also lie >:).  You can use mod_header to set any header,  including a fake x-powered-by, and just adopt .aspx file extensions using mod_rewrite.


Preventive security action in Android App Currently, I'm developing a bank related android app. I would share my knowledge and also maybe you guys are more expert than me so you can add your ideas to the list.

Bank is a very special client. They really concern about security stuff. However, in the same time, they want to have very flexibility and great feature to comfort their users. I really think both security and convenience do not relate to each other.

So what have I done are:

Use SSL to communicate from app and web API.
Using token authentication to ensure if the request to API is from official app. Most likely, I will use a shared token key that is updated every month. The token will be based on agreed random string, android id and the application id.
To prevent reversed engineering, I use proguard for obfuscate the app itself. I am not really sure how secure are proguard but Java Class are very easily reversible. Hopefully, with proguard it may makes it harder.
I also use MCSSID from simcard and Android ID to validate each user login and when application launched. Once, the SIMcard is changed, user need to re-register all information (such as CC number, mobile phone and OTP from bank). Also, the server will check once the android ID is not match. The server will flag the transaction with higher risk. Bank may call them to verify about their transaction.
The app will not be able to run on Rooted devices. If the devices is rooted, it will not allow to continue and finish the running activity after alert.
Also, in the future, I'm planning to regularly check user behavior login (such as, Time, Location based) to ensure if any unusual activity will be flag as high Risk

From steps taken above, is there anything preventive action that I can push more in the security sides?

Thanks

Obfuscation is a delaying tactic, not a solution. You have to work on the assumption that the application and phone will be compromised. Treat it like you would a browser, use the app to send and display information only:

Do not store any sensitive data locally
Handle all processing on the bank's servers
Do not cache any passwords, account details, or transaction data

Encourage the bank to perform a risk analysis on the functionality they want the app to have, and evaluate whether the functionality should be included. Do your own analysis and warn them about anything you aren't confident you can protect.

There's no point in blocking use on rooted phones, many people root their phones for legitimate reasons and you don't want to deny service on that basis. If you design your app right it won't matter, which is the whole point.


Recycled phone numbers I just wanted to ask because I am in a situation now, where I have been locked out of my Instagram due to my mobile phone provider deactivating my Simcard. I have contacted Instagram support sending the images of my face to match my account but they have not replied after 2 weeks.

I was hoping that after my phone number is recycled I could contact the new owner and get them to help me. But from what you guys are discussing it seems people would stereotype me as a hacker. What next steps could I take to declare that I am a normal person or still get access to my inactive sim SMS whilst it is in the recycled mobile phone number pool?

Is there a way to buy back the phone number before it gets allocated to someone else?

Thanks

I would recommend that you DO NOT contact the new owner of your previous phone number.

He/she would have no obligation to complete your task, in fact, you will be letting him know that he possesses a huge foothold to your account. You will be relying on how he/she responds, hopefully in good faith, as Instagram allows users to send a login link using their, Email, Phone, or Username. When a username is entered, the link is sent through your email. The screenshot below is taken from instagram.com

Recover your account with Facebook,

Open your Instagram App > "Sign in" > "Forgot Password" on the login screen
There will be a "Reset Using Facebook" option
Sign in with your Facebook account if need be, and if you are already logged into Facebook you will just see a short loading screen.
There will be a "Reset" button after the loading screen. From there on, you will be able to reset your password.

Prerequisites of resetting through Facebook would be that you linked your Instagram account with Facebook prior to this.

  Is there a way to buy back the phone number before it gets allocated to someone else?

You might have to loop in your telecom company on this, different telecom handles this differently. Who knows, they might be able to let you use your number to complete the recovery process, but I'm not sure how are you going to let them know that the Instagram account is yours before allowing you to do so.


how to store and retrieve nonce in practice As nonce is supposed to be random and used only one time, when receiving a nonce, I need to check it with all past nonce records. That means I need a database to store every nonce I had before. Of course I can reduce the database size by limiting the life circle for nonces. But I am curious about how people handle this issue in practice. Is there any efficient way to store and verify a nonce?  Thanks.

First of all, As nonce is supposed to be random is not, strictly speaking, true. Nonce in general is only required to be unique.

It is, however, often convenient to generate nonce as (pseudo-)random bytes. In this case and if the nonce is sufficiently big (say, 12+ bytes) there is no need to check against previous nonces as you will never encounter a repeat in your life.


SSH - request public key instead of fingerprint? When initiating a connection by SSH to a server not known in the hosts file, it's common to get a message such as the following:

The authenticity of host '[IP address]' can't be established.
RSA key fingerprint is [checksum].
Are you sure you want to continue connecting (yes/no)?

Is there a way to request the server to present the whole public key instead of the fingerprint?

You can use ssh-keyscan to get the information you want.  It's primarily designed for gathering public keys over an initial trusted network connection and automatically adding them into the known_hosts file.


Key-agreement protocol in a REST API I have a C# REST API which exposes some methods over the HTTP protocol. The API is intended to be used my my Android applocation (Java) which is currently in the makings.

Since the app is in an early development stage, and hasn't been released yet, I access the API methods using http://example.com/resources/item17 without any additional security. However, as soon as the app is released, I don't want anyone but my app users to access the API.

My idea is to generate some kind of unique key in my C# + Android code. A simplified version to give you the idea:

int key = DateTime.Now.Minute * Math.PI * 5;

This would make the request look something like:

`http://example.com/resources/item17?key=1234567`

The C# API would verify this before sending a response.

The only way to figure out how the key is generated would be to reverse my Android code (which will be obfuscated at that point).

Does this sound like a good solution, or do you have any other suggestions?

Your solution relies on the assumption that reverse-engineering of an obfuscated app is hard. However, this assumption does not match experience. Therefore, one cannot really tell that your solution is good.

However, maybe your solution is the best that can be done (not the same thing as "good"). The alternative is user authentication. Namely, each app instance would get its own authentication key; then, it is up to the server to accept a key or reject it. This gives you the ability to revoke a key which appears to have been reverse-engineered; it may also give you legal leverage to prosecute offenders.

If you do pursue the concept of generating a time-based key in the app, then at least do it with the proper cryptographic tools. In this case, use HMAC: encode the current time into some bytes, then compute HMAC/SHA-1 (or HMAC/SHA-256, whichever is easiest for you) on these bytes, using a hardcoded key. The hardcoded key is the target for reverse-engineering. Using HMAC will at least protect you from key reconstruction by analysis of the output: the attacker will really have to do some actual code disassembly. You will also need the app to send its notion of "current time" as an extra parameter, because you cannot rely on the client device being well synchronized.

(None of this being exclusive with running the whole thing in HTTPS, which is usually a good idea when security matters, but is really another subject here.)


What exactly is 'single' mode in John the Ripper doing? I'm testing out John the Ripper (1.7.9 Jumbo 7) on a file containing MD5 hashes without any usernames. I've been experimenting with different rules and configurations – I am currently using a wordlist and I am applying the --rules=single command. As a result of running this command, I'm getting very good results with it, however, I can't seem to understand what is happening under the hood because of the following paragraph I found on Openwall's website:

  'Single Crack' Mode: This is the mode you should start cracking with. It will use the login names, "GECOS" / "Full Name" fields, and users' home directory names as candidate passwords, also with a large set of mangling rules applied. Since the information is only used against passwords for the accounts it was taken from (and against password hashes which happened to be assigned the same salt), "single crack" mode is much faster than wordlist mode. This permits for the use of a much larger set of word mangling rules with "single crack", and their use is always enabled with this mode. Successfully guessed passwords are also tried against all loaded password hashes just in case more users have the same password.

  Note that running this mode on many password files simultaneously may sometimes get more passwords cracked than it would if you ran it on the individual password files separately.

I'm confused by the statement "single crack" mode is much faster than wordlist mode. How come single mode is is faster than a simple dictionary attack if word mangling rules are being applied?

Any insight into what goes on in single mode cracking would be appreciated, since I can't seem to find much documentation other than that paragraph.

The paragraph from JtR online documentation that you're adding to your question actually explains it pretty well.

Think of it as a dictionary mode (or WordList Mode), but one that builds the list of all words found in GECOS fields, making this dictionary rather small and uses a complete set of mangling rules JtR supports.

In contrast, the WordList Mode will have a much larger set of dictionary words to run through, but using a reduced set of mangling rules designed to finish very quickly on each dictionary entry. This limits the number of guesses on each candidate word.

So in short, Simple Mode will run a complete set of mangling rules on a short but highly relevant dictionary, where Wordlist Mode will use much longer dictionary, but reduce the mangling ruleset to complete faster.

This relevance (where the word list is compiled from), on top of bigger number of mangling runs per each candidate word, is the most likely candidate for your better results using the Single Mode.


Can I tell which applications embed Internet Explorer at a command prompt? A recently discovered vulnerability affects Internet Explorer versions up to version 9, running on Windows XP, Vista, and Windows 7.

This arstechnica article quotes HD Moore as saying,

  Just keep in mind that even if you don't use IE for day-to-day
  browsing, a lot of tools you use do embed IE and those are vulnerable.

Assuming that I can't deploy Microsoft's Enhanced Mitigation Experience Toolkit (EMET) through a group policy, I might have to visit every machine. Each one has probably dozens of applications installed. The EMET has per-executable mitigations. For example, the mitigation for excel.exe is potentially different from the mitigation for word.exe, and so on. So I need to consider mitigation for at least one executable in every application. (Some apps have a lot more than one executable.)

To make the most effective use of time to mitigate this particular IE risk, I'd like to know which installed applications actually embed Internet Explorer. If I know which ones have IE embedded, I'd assume those were the riskiest, and I could define mitigations for those first.

At a command prompt, is there any way to tell which applications have embedded Internet Explorer? I have a fairly complete toolbox of command line tools; I can even boot a Linux live CD if I need to. But I haven't the first clue what to look for.

There are lots of libraries that relate to the Internet Explorer functionality, and it's probably the case that anything making use of it uses others that I don't know.

Two that are signs, though, are definitely shdocvw.dll and mshtml.dll. If you see an application loading either of those libraries, you can feel pretty comfortable that it's making use of IE. Take a look at MSDN's About the Browser article.


Non-standard OIDC flow: How safe is this? I have been made aware of an application, at a client, that claims to use OIDC to authenticate users. This is however done via a non-standard flow that I find hard to assess from a security standpoint.

It starts with a frontend SPA initiating an OAuth2 Implicit grant with the openid scope. Important to note is that this is not an OIDC Implicit grant as only an access_token is returned. The token is then used in communications to the backend API, which uses the token to request attributes from the userinfo endpoint. The user is considered authenticated as the user returned from userinfo.

My first assessment is that this should be fine, as long as the TLS certificate on the userinfo endpoint is validated. However, I am not comfortable stating this to the customer since the flow seems to lack some of the key parts of OIDC, and I have never seen this flow promoted anywhere by anyone.

I can't see a vulnerability in the described flow. However, a lot of much smarter and competent people work on standards, such as OIDC. And there is probably a reason why they designed it the way they did. So I would argue using a non-standard flow is dangerous, even if the problem is not immediately obvious to us.


Could you recover data from a fully encrypted disk if it's damaged? I red the cold boot paper and how they manage to recover the original private key even if it's partially corrupted and it got me thinking.

Suppose you have a fully encrypted disk via, say, truecrypt , if you damage this drive (toss it around or put it on a microwave or drill through it etc).

Can you still decrypt part of the data even if you don't have all of it ? Supposing you have the private key.

If so, how ?

Generally, for full-disk encryption, data is encrypted at the block layer (if the entire filesystem was encrypted as one big blob, you'd have to load the whole thing into memory and decrypt it before you could access anything; if you changed just one bit you'd have to re-encrypt and write the entire disk!). This way, if part of the disk goes bad, you don't lose all of your data.

So yes, if part of the disk was intentionally destroyed but the key was available, the remaining data could be decrypted. Without the filesystem table, though, it would just be a bunch of binary data that would have to be parsed into files, but there is software to help with this task.


Pentest Results: Questionable CSRF Attack We've recently had one of our webapps pentested. All went well, except for a CSRF vulnerability, and it is this finding I have a bone to pick with.

Some background: we're using ASP.NET MVC and, among other things, we do use the CSRF protection functionality built into it. The way it works is strictly in accordance with what OWASP recommends: by including so-called "synchronizer tokens", one in a HTTP cookie, and another in a hidden input named __RequestVerificationToken:

<form action="/Home/Test" method="post">
  <input name="__RequestVerificationToken" type="hidden"
    value="6fGBtLZmVBZ59oUad1Fr33BuPxANKY9q3Srr5y[...]" />
  <input type="submit" value="Submit" />
</form>

We also do regular Acunetix scans, and said scans never found any CSRF-unprotected forms.

Now, what the pentesters claim is that they were able to "breach" our CSRF protection with the following code:

<html>
  <body>
    <form action="https://our.site/support/discussions/new" method="POST">
      <input type="hidden" name="subject" value="Subject" />
      <input type="hidden" name="content" value="Content" />

      <input type="hidden" name="__RequestVerificationToken"
        value="_e-upIZFx7i0YyzrVd[...]" />

      <input type="submit" value="Submit Request" />
    </form>
  </body>
</html>

The inclusion of the __RequestVerificationToken field is what bothers me the most: to me, it is akin to claiming that an attacker has transferred gazillion dollars from my bank account because I voluntarily gave him my iPhone to fiddle with, and he saw the one-time password that my bank sent in an SMS.

I imagine that the only way this attack could potentially work is if we were not using HTTPS, were vulnerable to XSS, were using non-HTTP-only cookies and were negligent with a Same Origin Policy. None of which is true, since none of these vulnerabilities were reported by either pentesters or Acunetix.

So the question is: am I wrong and this is a legit CSRF vulnerability or is it not?

This does not seem to be a CSRF vulnerability.

If an attacker needs to know a CSRF Token, then it's not an attack. And your approach to CSRf does seem to be correct.

Issues which leak the CSRF Token can indeed result in a CSRF attack, but then the problem isn't incorrect CSRF protection, but those issues (XSS, encryption, CSRF Token in URL, and so on).

Still, I would ask the tester for clarification. Who knows, maybe the attack always works with that specific token, because it is hardcoded somewhere, or because the special characters are causing some sort of problem for your application. Or maybe it is possible to use a token from a different user, or maybe the token check just doesn't work at all and it accepts arbitrary tokens. The report should have contained more details, so I would check back with the tester about this.


Can I show Credit Card Data to final customers and be PCI Compliant? I work with reservation management syatems. In the hospitality industry there is the concept of credit card as guarantee. By it when making any kind of reservation you are asked for your credit card info in order to secure the reservation, however you may only be charged, depending on the booking conditions, in the case of a no-show or other concepts that may only occur after the booking process.

For example I may book in January a safari tour happening in October.

So basically for as long as the reservation is valid, you must hold onto the credit card data.

Once day of the booking occurs and there is a no show for example. The hotel personnel (my customers) can query the user's credit card data and charge it.

So if I were to store credit card data in a PCI compliant way, can I then show the credit card data from user's to authorized hotel personnel (customers) that must use it to charge the user?

Once again I clarify, My customers are Hotel Personnel, Tour Operators, Travel Agencies. And the Users of the systems are the people booking through it and giving their credit card numbers.

Ultimately, I think you're going to have to figure this out with your PCI auditor, which I am not.  I think you're going to have a hard time figuring out how to do this is a way that is a) not overly burdensome to you and the ultimate users of the card data, and b) leaves you with a system that is still PCI compliant and that your auditor will give a stamp of approval, but I also don't think PCI DSS v3 makes it impossible.

This is the most significant issue:

Once card data enters a PCI compliant system, it cannot be extracted and delivered via non-compliant means.   This means that you can't get the card data out, and email it to a hotel, for instance, or give to someone over the phone.  It must at all times be encrypted, access logged, and unprotected PANs only displayed to those with a legitimate business need.

Now, given that the hotel personnel do in fact have a legitimate business need (they need to be able to charge the card) if access is appropriately restricted and audit logged, you may be able to successfully argue this.  It still elevates the level of risk, however, and any given auditor may refuse to buy this line of reasoning.

You would be far better off if you could send the data directly to the hotel or tour operators own PCI-compliant processing systems and let them worry about it from there, instead of having to work through human intermediaries.


Firefox & Chrome Strong Ciphers Of the following ciphers for RSA authentication, Firefox and Chrome do not use stronger than ECDHE-RSA-AES128-SHA256.

ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256

Why is this?

Isn't ECDHE-RSA-AES128-SHA256 the weakest of those listed above and ECDHE-RSA-AES256-GCM-SHA384 the strongest?

I tested Chrome and Firefox, both mobile on ssllabs.com:

Chrome

Cipher Suites (in order of preference)

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)   Forward Secrecy    256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)   Forward Secrecy  256
OLD_TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc14)   Forward Secrecy    256
OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcc13)   Forward Secrecy  256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   Forward Secrecy  128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   Forward Secrecy    128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   Forward Secrecy 256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   Forward Secrecy   256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   Forward Secrecy   128
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)  128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)

Signature algorithms

SHA512/RSA, SHA512/ECDSA,   SHA384/RSA, SHA384/ECDSA,   SHA256/RSA, SHA256/ECDSA, SHA224/RSA,   SHA224/ECDSA,   SHA1/RSA,   SHA1/ECDSA

Firefox

Cipher Suites (in order of preference)

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)   Forward Secrecy  128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)   Forward Secrecy    128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)   Forward Secrecy     256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)   Forward Secrecy     128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   Forward Secrecy   128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   Forward Secrecy   256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)   Forward Secrecy   128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)   Forward Secrecy   256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)     128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)     256
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)

Signature algorithms

SHA256/RSA,SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA

SHA384 is seemingly unpopular. Have not seen it in the wild. Firefox (NSS) and Chrome (WebCrypto) have some problems implementing those strong ciphers.

Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=923089

Chrome: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/ufzO8NhttaA


3G, 4G How does my provider know i am using facebook? I have a mobile subscription with 1 GB of data every month. But my provider has a promotion where facebook and twitter traffic is free, so I can use facebook and twitter and not use up my 1 gb of data.

I just wonder how they know when I am using facebook? And if they are scanning for facebook usage what else can they scan and how can I prevent them to know I use a facebook (or any other site).

Without going into deep detail about how Internet Protocol routing and the Domain Name System work, it's actually quite easy for your ISP (and in this case, your provider is your ISP) to know what domains you visit.

To answer your question, the provider maintains a list of all the IP addresses registered to Facebook. When your phone requests Internet data via its cellular connection, it addresses the request to a specific IP address. That request gets routed through the Internet gateway at your provider. The gateway (or other hardware between it and the tower) can record this usage, and check the source and destination addresses. If the destination address (for a request) or source address (for a response or push notification) is from an IP address registered to Facebook, your provider simply doesn't count that usage against your plan's data limit.

They can't necessarily read the traffic - even using Deep Packet Inspection (DPI) they won't be able to read encrypted traffic - but they can see how big it is, where it comes from, and where it goes. Be aware that mobile operators often do use DPI, though; it lets them detect people doing things like using tethered data without (or in excess of) their tethering limit. Also, while the traffic between your phone and the tower is encrypted (with not-very-good crypto on older-generation protocols, though I don't think 4g is broken yet), the operator obviously needs to be able to decrypt that layer of traffic so they can route the data. The data could be encrypted at a higher level as well, using things like SSL/TLS, but anything above the Internet Protocol level will reveal the sender and recipient of each packet.

Any ISP can do this monitoring of your connections for anything that accesses the Internet through them, by the way. This kind of "metadata" is one of the things the NSA and similar agencies around the world is so intent on slurping up. China's "Great Firewall" places filters on IP addresses that it doesn't want you to reach, though I think it also uses DPI to block specific content on otherwise-permitted sites. This kind of thing is one of the reasons anonymizing proxy servers and anonymous networks (such as TOR) exist; your ISP can tell you are connecting to a proxy / TOR entry node, but can't tell where your request goes after that unless they control the node. By bouncing the request a few times to random machines, it's possible to be pretty sure that anybody trying to track the path of the request has lost it. The actual final destination is encrypted within the data sent to the proxy, so it's never visible to a network attacker.