How much protection does sandbox software provide against malicious .exe?

The simple answer is "it depends on the sandbox". Sandboxing is not a binary state. Every bit of code that isn't running in supervisor (ring 0) (or hypervisor/ring -1, where relevant) on the processor could be described as at least a little "sandboxed". User-mode admin code is a little sandboxed, user-mode non-admin code moreso, user-mode code running with specifically restricted permissions is what is most often meant by "sandboxed", but you can definitely get more restrictive still.

Lots of apps are distributed with sandboxes (for example, stuff from the Windows or Apple app stores are generally more sandboxed than apps simply downloaded from the web, although not necessarily very tightly sandboxed). If you want to be able to run arbitrary code, though, that obviously won't work. You could in theory package your games up in app-style sandboxes based on what capabilities you expect the processes to need - very little write access, some more read access, maybe certain network privileges, etc. - but this is a hassle and you risk the games not working because you failed to give them access to something they legitimately need. Also, app sandboxes aren't the most fine-grained things out there (most of them allow all network traffic, network client traffic only, or no network traffic, for example; if you want to block specific ports or something you'll need to use a different sandboxing system or just configure your firewall).

Your best bet is probably a fairly strict container, a VM, or a throw-away system. VMs are quite secure (at least, if you don't turn on "integration" features), but are harder to get data out of and also make it harder to run a lot of games (restricted access to the hardware). The hardware issue can be fixed by using a computer with nothing you care about on it - a throw-away setup - but those are more hassle to "reset" between tests (VMs can be simply rolled back). Containers (on supported platforms) can be made quite strict, though they're less inherently secure (they still talk to the same kernel as unsandboxed processes, so local EoP vulns can be used for sandbox escapes).

With all that said, in theory a properly-designed sandbox will provide adequate protection against anything a malicious program might do. "Properly designed" is doing a lot of work there, though; speaking as somebody who has found sandbox escapes both professionally and as a hobby, they're really hard to get right. Also, most sandboxes are going to struggle at least somewhat against really novel attacks. A large part of why Meltdown and Spectre were such a big deal is because they broke a lot of sandboxes (VMs, low-privilege processes, Javascript sandboxes, etc.).

It can also be a delicate balancing act to trade off security with functionality. A sandbox will sometimes limit the compute resources (CPU time, RAM, etc.) that a process can access, to prevent it from consuming all the computer's resources and effectively attacking every other process on the machine, but this is obviously incompatible with properly testing a game that really demands everything your machine has and will perform badly if it has to share compute resources.


Is it possible to intercept https traffic and see the links?

If the Man-in-the-Middle attack succeeds, then, by definition, the attacker sees everything: success here being that the attacker impersonates both the client and the server, so the client talks to the attacker, the server talks to the attacker, the attacker decrypts on one side and reencrypts on the other. With a successful MitM, the attacker can see the links, the page contents, the passwords...

But, of course, SSL has been designed to defeat MitM attacks. The main protection is the server's certificate. To succeed at MitM, the attacker must create a fake certificate with the server's name, but containing a public key that the attacker controls. The whole point of trusted root CA and certificate validation is so that the client does not get fooled by a fake server certificate.

(If the human users sees the scary warning from his browser "this server uses an untrusted certificate" and still clicks on the "I don't care, connect anyway !" button, then the MitM succeeds. Security against MitM in SSL relies on the idea that the human user does not do anything stupid such as disregarding that kind of warning.)

Edit: as for what can be inferred from passive sniffing, then this does not include the requested URL per se; however, a few things can be inferred:

The intended server name (the "host name" part of the URL) will be known to the attacker. Modern browsers show it in cleartext as part of the Server Name Indication extension. The name also appears in the server's certificate, which is sent as cleartext as well.
Encryption hides data contents, but not data length. The attacker can then infer the length of the URL, especially if he gets to observe several encrypted requests.
Since lengths leak, the attacker can more or less see how many elements are downloaded by the client and their respective lengths, e.g. linked pictures. Depending on the site structure and whether the attacker can also browse the same site (as, e.g., another user), then he may figure out with great precision what the target user is actually browsing.


Does Hardware TPM have TAB/RM component？

No, the TAB/RM is a software component.

The TPM is a really constraint device with little memory (e.g. few key slots). To solve that problem, there is a TPM Access Broker/Resource Manager (TAB/RM) which automatically saves excess TPM data (encrypted) on your hard disk and loads it into the TPM if needed.

When you're on a linux machine, you might have noticed that there is a /dev/tpm0 and a /dev/tpmrm0. The tpm0 provides direct access while the tpmrm0 uses the TAB/RM (which is part of the linux kernel) to simplify your life. The interface is the same, btw, that is talking to the TAB/RM is like talking to a TPM with infinite resources :)

The TCTI, SAPI, ESAPI and FAPI layers are indeed libraries. They are all provided by this open source implementation.

For completeness sake: there is not only a in-kernel TAB/RM, but also a user space TAB/RM implementation doing the same thing. You can install it e.g. if your kernel is really old.


Is there any decompiled source code for the "Flame"/"Skywiper" malware?

I can't find any (decompiled) source code of it, but I did find a rather thorough CrySys (Laboratory of Cryptography and System Security, Budapest) technical report (pdf). It covers pretty much all aspects of it, from how Skywiper works to how it propagates and infects. A short digest of it can be found in this blog (among many) and a few more links to other anti-virus labs' blogs here. I realize I didn't answer your question, though. I guess it's still too early for any of these labs to share their newly found lab pet and its thoroughly dissected innards with the rest of us. Their eyes probably roll not unlike the fruit slots machines do on a jackpot roll, and I wouldn't keep my hopes up that they'll release more on it until their eyes finally settle on banana. ;)

UPDATE: Found some downloadable samples but you'll have to ask for password, and another repository that requires registration. No reverse-engineered code yet...


Why are drives overwritten three times when being disposed of?

Overwriting the data is either insufficient or useless, depending on how things are done internally by the device itself. Flash memory has a limited life, expressed in terms of read/write cycles. To sum it up, you can have one block of data full of zeros; bits can be changed from zero to one individually, but the reset to zero can be done only for a complete block at a time, and if you do it more than 10000 times or so, then the block fails down. Blocks have a size of a few dozens of kilobytes.

Thus, if Flash-based drives simply used a direct mapping from the logical sectors (as seen from the computer) to the Flash blocks, they would be slow and unreliable: each write of a sector over a previous value which is not all-zeros would entail reading the whole block, clearing it, then writing it back with the new sector value. Instead, Flash drives use wear levelling methods in which the writes get spread throughout the device blocks, so as to both minimize the number of required block clearings, and avoid having some blocks more used than others. Moreover, Flash drives often have more physical blocks than their nominal size, both to give some breathing room to the wear levelling algorithms, and to allow for remapping a few failed blocks, thus augmenting the drive lifetime when blocks begin to break down.

A consequence is that you cannot be sure, when you overwrite the whole disk, that you really wiped out all the data on the physical medium. In fact, if wear levelling is applied by the drive, then it is pretty much guaranteed that a single overwrite will not overwrite all traces of the data at the physical level, because there are more physical blocks than the logical total drive size.

Using three successive overwrites is an attempt at ensuring a more complete coverage. But it relies on some assumptions on how the wear levelling works, which may be unwarranted since there is no standard. Since the wear levelling is entirely handled by the drive itself, in its firmware, there is no reason for such algorithms to be standardized or even documented; one may even be so bold as to point out that wear levelling algorithms are part of the trade secrets of drive vendors, so they are unlikely to be all documented. Whether three overwrites are more than need, or, to the contrary, insufficient to ensure data destruction, is simply not known.

Moreover, if the drive remaps fails block transparently, then a failed block still contains mostly intact data, and since the firmware will thereafter avoid using that block, that data will remain in place until the end of times, regardless of how many overwrites you perform. That failed block is permanently out of reach of the host computer. (Note that this argument also applies to magnetic disks, but remapping of failed sectors is a rare event for classic disks, whereas it is very common in Flash drives.)

So the main benefit of the three overwrites is psychological. It is a very visible procedure that helps convince managers and auditors that security is happening, thereby justifying the corresponding budget line. If you want to really wipe out an old drive, burn it.


Could encoding messages into huge random-data balloons help frustrate/corrupt nosy intelligence/government activity?

Sniffing all data as you envision they will do in a dragnet does not mean that there is a way to decrypt all data or that decrypting data is even needed to get useful information.

First, meta data already provide valuable information without the need to do decryption. Such meta data are for example who is the sender, who is the recipient, how many data get exchanged, how long do these party communicate, at which time, from which location, is the data encrypted etc. Connecting such meta data can for example be used to provide social graphs which are then used to find the most valuable targets who can then be attacked in a more targeted way.

Second, today's encryption algorithms can be considered fairly solid. It is currently expected that even secret services do not have the resources to decrypt properly encrypted data. This does not mean that this would be fully impossible in all cases but it just gets to expensive and even governments have limited time and money. It is far cheaper to compromise sender or recipient and thus gets direct access to the plain data. This might be done by exploiting some software bugs or even by silently breaking into the home and directly manipulating the hardware of the target or adding tiny cameras and microphones to listen and watch any communication.

Your proposal will not offer better protection against the attacks I've just described. It might in theory offer a better protection against some attacks which are kind of impossible already if existing encryption is properly used.


Simple way to encrypt files on Linux and decrypt on Windows?

GnuPG is indeed the way to go. A Windows build exists at Gpg4win.

Using asymmetric keys means that whatever encrypts the data (the backup system) needs not know any private data element, thus its compromise does not allow an attacker to decrypt past backups. Also, you can encrypt the archive relatively to several public keys (this will not enlarge the data by much), thus allowing you to potentially "revoke" people (if you decide that one of your three persons should no longer be able to decrypt backups, you just stop encrypting the backups with regards to his public key, without having to change anything for the other two).


Scam caller claimed to have elderly friend's "Windows unique identifier"

These scammers often scare people by disguising harmless elements (such as event log entries, firewall rules, etc) into evidence of compromise and malware. For example they could tell you to execute some commands or find in advanced system properties what looks like a random number but is actually an reference to some system component common on all systems, like a CLSID. While searching for a Wikipedia page for "clsid" I stumbled upon this blog entry which describes exactly what I just said.

To the average non tech-savvy user, seeing what looks like a cryptic and random number and have the person on the phone tell you that exact number would be pretty convincing, but really, anyone (even if still a scammer) who could really get ahold of genuine confidential information from a data breach or similar would at the very least be more experienced in social engineering and talk about something that actually exists like a product key, product ID or even MAC address rather than the "Windows UUID" nonsense they put up.

If you have their number I suggest you call them back and let them remote into a virtual machine, you'll be able to see exactly what they would've done to your friend if he believed, but usually their tactics are the same, they claim they're Microsoft or "Windows technical center", that your computer sent them some kind of distress signal and you should let them remote in (via TeamViewer or alternatives), then they scare you by showing you errors in the event viewer or by copy/pasting the tree command followed by a scary message like computer infected (which will display only after the tree command has ended, so they can pretend the tree command was actually an antivirus scan and it detected malware), and finally making you pay (either on a genuine payment provider or just their own scam page which steals your card number) for a rogue (fake) antivirus.


What is considered an acceptable, secure method of remotely connecting to a Linux system?

NoMachine is more-or-less X11 over SSH with improvements in performance.  So the two benefits there are that SSH is managed for you and that you don't have the ghastly performance of X11 over a network.  (ISTR that SSH is not the default, but it's essentially a dropdown option, not a setup saga).

VNC also provides better performance than X11, and can be secured either over SSH or using one of the various hardened variants (like UltraVNC or RealVNC Enterprise or Personal).  However, the hodgepodge of variants and manual nature of SSH integration (e.g., TightVNC basically says "do it yourself") it's not the most coherent of solutions.

X11Forwarding ranges from bad to abysmal across the network.  It's essentially unusable across the WAN.  And that's not because of SSH, it's because of the way latency impacts the X11 protocol.  I wouldn't bother with it for that reason.

My personal advice is to look at NoMachine.  It's a much more coherent, solid product than *VNC, and having the SSH bit work is easy and integrated.


How can RFID/NFC tags not be cloned when they are passive technology?

Because the cards contain a chip which are powered by a coil.
The coil is not really a antenna, but half of a transformer.

Think your regular mobile charger. This contains a transformer, that will transform the voltage from 230V or 120V AC to 5V DC. This is done by having a coil magnetize some iron, and this iron magnetizes the "receiving coil". If you draw current from the receiving coil, the primary coil will also draw more current.

Now, let's go to the "passive" card again.

The reader is one half of a transformer, and the card is one half of a transformer, but this transformer does create a magnetic field in the air instead of magnetizing iron.
When you put the card close to the reader, the reader and card becomes a full transformer, and thus the card can be powered, like it was connected to a battery.

For the reader to transmit information to the card, the reader only needs to vary the frequency or amplitude of the AC voltage that powers the primary coil. The card can sense this and act on this information.
For the card to send information back to the reader, the card simply short-circuits its own antenna via a transistor and a resistor. This will, like the mobile charger, cause the primary coil, i.e. the coil in the reader, to consume more current, and the reader can sense this (by having the primary reader coil via a resistor and then measure the voltage over the resistor) and read the data the chip sends to the reader.

This means that half-duplex bidirectional communication is possible with RFID, thus the chip can do anything, and work like a contact smart-card.
And as you know, a contact smart card with a security chip, that can securely store a key, and only perform operations with the key, is impossible to "clone" or "copy" as the key cannot be extracted. That's the security of smart cards, they cannot be cloned, and that's why they are preferred over magnetic strip cards.

Thus, the same applies to wireless/contactless RFID card.


Can JavaScript break anonimity provided by Tor?

tl;dr: Yes, JavaScript can break anonymity provided by Tor if there's a browser vulnerability involved, if you enable features that weren't designed anonymity in mind (like WebRTC or Geolocation API), or through giving out more information for browser fingerprinting.

This particular site (https://pearsonpte.com/) uses the Geolocation API on line 31: navigator.geolocation.getCurrentPosition(). This doesn't use geolocation data for your IP address, but a location provider like GPS chip on your device. Usually the browser prompts you for a permission per site, but this can be allowed or denied globally. Allowing geolocation globally would be dangerous as it reveals your location in much more detail than your IP address.

Configuring your browser to prevent everything that could reveal your identity takes a lot of effort and is likely to fail. Even if you have all the knowledge to disable everything necessary, the more you customize your settings the more unique fingerprint your browser will have (Am I Unique?). Tor Browser is a standalone bundle with a pre-configured Mozilla Firefox with NoScript and HTTPS Everywhere, but the default settings enables JavaScript on the site itself and warns about external scripts. Being extra careful you might want to tighten the settings by removing some of these:

Tor Browser is not perfect against the browser fingerprinting, but it helps a lot with other mistakes you could make. Am I Unique? test results first with default settings compared to the results with JavaScript disabled also suggests that disabling JavaScript might be a good idea:

  But only 12 browsers out of the 992892 observed browsers (0.00 %) have
  exactly the same fingerprint as yours.

  But only 1796 browsers out of the 992968 observed browsers (0.18 %)
  have exactly the same fingerprint as yours.

Even using the Tor Browser you could screw up in several ways including:

You forget (or neglect) to update the browser. Outdated versions can be quite dangerous: there has been vulnerabilities in e.g. handling file:// URLs and bypassing NoScript.
The site ask your permission to use HTML5 features like canvas image data. Tor Browser lets you allow it on your own risk, but you have been warned.

You could allow scripts globally or trust a site you shouldn't (assuming you disabled scripts).
NoScript detects potential Cross-Site Scripting attack, but you can allow requests to external sites.
Tor Browser is pre-configured with e.g. geo.enabled & geo.provider.ms-windows-location set to false, but it doesn't lock any of the settings in about:config.


Meterpreter is closing connection - connection died

The issue was resolved - the handler i have used was incorrect (the bad habit of copy paste)
Please verify that you are using the corresponding handler
use exploit/multi/handler
set PAYLOAD php/meterpreter_reverse_tcp


Smartcard - main differences between .NET and Java smartcard?

I'm rather rusty on my Smartcard stuff but I'll have a crack at an answer anyway.

Smartcards are small embedded computers in their own right and so they do indeed use a very simplified OS. The 2 you mention are the standard ones.

They all have some standard capabilities that are not especially dependent on the OS. The ability to present a certificate, encrypt/decrypt some data, request a PIN, etc are all part of the smartcard specification. These features are accessed from a host computer via a standard interface library, generally PCSC.

In addition though, most if not all smartcards of the last decade are able to act as very simple general purpose computers and that is where the differences come. Java smartcards run an embedded version of a Oracle Java as an OS and use Java as the programming language, .NET cards use an embedded version of Microsoft .NET in a similar way. Originally, there were only "dumb" smartcards and Java based "smart" smartcards. Now I believe that the .NET ones are much more common.

Hope this helps.


Least insecure way to encrypt a field in the database so that it can still be included in queries

Given what you've told us, I would still use a hash function: that's exactly what they have been designed for.

You cannot salt your hash value, unfortunately, since you want to be able to find a specific record based only on the cleartext value but you can still used a HMAC algorythm to protect against direct attacks: an attacker will need to have access to the key used in the HMAC computation in order to derive a hash from a given cleartext: assuming you're storing your keys properly (probably the most critical issue in such an application), your SenderID will remain hidden but you'll be able to find it at any time by a simple lookup.

Using a HMAC will also help you if your SenderID has low entropy (although it will not solve THAT issue completely).

Please note that anyone who has (or can gain) access to the key used in your HMAC calculation will be able to try to match given cleartext with your data but that is something that cannot be helped, I think.

Be aware, though, that, while you can (and should) have a different key on each installation, you will NOT be able to change that key afterward or you will lose the ability to find your records. One way around this is to add an encrpyted version of the SenderID within your record: in you need to re-key everything, you can use it to recompute a new hash.

I would, however, suggest that you use a strong, modern hash function for your HMAC. (SHA-3, for instance, even if the final specs haven't been published yet)


Is a government entity capable of establishing a secure virtual currency system?

Consider what happens today with paper currencies - governments spend huge amounts of money evolving their currencies to prevent misuse. It's a never-ending battle to "secure" their currencies.

Most currencies are virtual to a certain extent, the time has long passed that they were backed by anything. For every dollar that is printed and in circulation there is more that exists only in bits and bytes. If you have a bank account the currency in it doesn't exist in a physical way, it's database entries in a system. Banks have an evolved infrastructure to move this money around, and they spend a great deal of time, effort, and money to secure these transactions. Governments are involved with banks already to secure these mostly virtual currencies in the form of regulators like the FFEIC, MAS, FCA.

Currency cannot be fully secured whether they are cowrie shells or crypto-currencies because they have to be able to be used. Any that has inputs and outputs will have vulnerabilities, and so cannot be fully secured.

So can a government maintain the security of a virtual currency? No. Can they make it secure enough to use on a day to day basis? They already have.


Should a logout request be authenticated?

There is  no need to protect logout resource.

If a session is present with the logout request; it gets invalidated. Otherwise it gets directly redirected to logout page.


Is it possible to hack an Android App or an Android device without being root?

Yes.

Much of android malware applications simply abuse the api and claim to do one thing (eg an innocent game) but then do malicious activities (subscribe to premium sms, without root).

Any application that makes use of WebViews and allow for javascript execution open themselves up to standard javascript attacks(XSS). In fact recently a vulnerability was disclosed in the old browser application somewhat related to this. This was also without root.

Man in the middle attacks can be done simply by connecting to an insecure wifi hotspot, without root(from the victim's perspective).

Applications that don't authenticate with their back end APIs and servers can be subject to a number of sniffing/spoofing related attacks, without root.

So yes, root is not needed in all malicious attacks on android.


Does using TLS, SSH and SSL in a connection makes it more secure?

In general I would say No.

For almost all cryptographic purposes on the internet, TLS 1.2 by itself is more than good enough. (if someone could demonstrate that it wasn't, then it would be considered broken and it would be retired). Your question is sortof similar to asking "Will I cross the street faster if I push the crosswalk button three times instead of once?"

Moreover, I suspect that if I can break your TLS (for example by hacking into your server and stealing the server's private key) then I can probably do the same for whatever other protocols you're layering.

Unless you have a specific reason why you believe TLS to be insecure in your environment, or you have some exceptionally high national military type security needs (and have hired a team of crack cryptographers to engineer something better than TLS, the state of the art in cryptography), then you won't get any practical benefit out of layering. Even then, you'd might as well just replace TLS with a single stronger protocol rather than layering.


What are security concerns of the predefined user in Web Application?

You should insert this user into your database uniquely for each installation, instead of hard-coding the account, or at least give the ability to disable the account as well as reset the account's password.

You cannot predict how this backdoor admin account you are creating could be abused in the future. Maybe your company's sensitive files are breached including all your installation passwords and now you need to quickly disable the account. Maybe an attacker uncovers a vulnerability in your hard-coded admin account logic and suddenly you have no way to remove it.

It's better to give yourself options in the case of a breach like:

ability to delete account
ability to disable account
ability to rename account
ability to reset password


Capturing and decrypting my own SSL traffic

Tools such as this SSL MITM proxy from Stanford can automatically generate certificates and provide an SSL-to-SSL cutover. You'll need to set the key used by the proxy to be trusted by your browser, but that will provide you with the ability to see the cleartext traffic that is leaving from your machine.

While you can try to rewrite any HTTPS redirect requests to have HTTP, many website that provide HTTPS support will only provide content over the encrypted channel; the unencrypted channel provides nothing but redirects.

Moxie Marlinspike's SSL Strip will probably also fulfill your goal by transiting the HTTPS traffic, but only speaking with your client using HTTP and rewriting redirects.


Is it safe to store a password in compiled code?

No, it's not secure.

Any compiled application can be disassembled and examined. The CIL bytecode generated by your C# compiler can be traced instruction by instruction just like any other programming language. When you hardcode your cryptographic key, it will appear somewhere in the assembly. (the same applies to machine code generated by "real" compilers, by the way). It's not if someone will find your key, the question is when.

You could encode your key, but the encoding algorithm must also be part of your assembly, so it can be found and used by the attacker.

You could use some code obfuscator which makes the assembly less readable, but that usually affects performance negatively and is also just an additional obstacle which will cost the attacker more time but will not prevent them from finding it when they are diligent enough.


How secure is it to keep the salt with the password hash?

Salt doesn't have to be secret. However, it MUST be unique for each password.
Consider this : if all your passwords are hashed with the same salt, then an attacker who gets access to your database "only" has to compute H(pwd+salt) for each possible pwd value and he gets all your passwords. If the salt is unique however, the same operation will only get him ONE password, the one associated with the salt he just tried.


Is the MIT implementation of Kerberos protocol as vulnerable as the one used by Microsoft?

What exactly is vulnerable in Active Directory? Without a clear baseline its impossible to compare x and y. This is an incredibly broad question and it's difficult to answer fully.
The pass-the-ticket/golden-ticket attacks are not themselves a vulnerability per se. The potential vulnerability is in the protection of the keys used to encrypt the tickets. Once you have the keys anything you do against the different parties is valid. At that point you're not attacking the protocol itself.
Active Directory protects these secrets in the directory database by encrypting them to a key protected by the machine. If you can get access to these secrets then you have full access to the database, which means you have access to the keys and can perform this attack. This is an infrastructure issue. If you don't do your own due-diligence protecting your critical infrastructure it's not reeeeeeally AD's fault. I say this because...
MIT supports multiple ways of storing directory data, and each one is equally at risk if you don't protect the infrastructure properly either. It supports LDAP and SQL and what not. Each of those has a database and protects their secrets fundamentally the same way. If you can attack that infrastructure you can get the keys and perform the attacks.
Now compare the protocol implementations. They're both RFC 4120 and they're both interoperable. They both support the same key types and extensions. This means any weaknesses of the protocol are applicable to both. Any pass-the-ticket/golden-ticket/etc. attack against AD is identical to MIT or Heimdal or whatever implementation is out there.
Where things differ is the support infrastructure. DC Sync for instance. Windows supports syncing directory databases between DCs using the MS-DRSR protocol, which when granted enough privileges allows you to request any secret you wish. This requires a critical privilege that isn't handed out freely and goes back to that protecting your infrastructure thing. MIT doesn't have a directory sync because it's not a directory. It's just an implementation of Kerberos. The LDAP directory you use to back MIT will however have a sync engine of some sort and will therefore have similar APIs and be equally attackable, if you get yourself into a privileged position.
that's the crux of this: if you can get into a privileged position you can attack the services. You could call it a vulnerability, but the meat of it is missing because you've magically crossed the security boundary without saying how. How you cross the security boundary is more appropriately the vulnerability.
All of that said, the reason Active Directory is the problem child here is because it's the most common and its makes it incredibly easy to automate equally good and bad behavior. It's the one everyone knows and it's had its share of bad press for good reasons at the time. There are some pretty obnoxious vulnerabilities like the print spooler bug or the netlogon vulnerability that pop up from time to time that take a long time to patch in the field too.


Is taking CC info in plain HTML elements, but using a library like Stripe to tokenize PCI compliant?

By making use of Stripe or Square you reduce your PCI burden since you are “outsourcing” handling of credit card information (CHD). This could make you eligible for filling in for example only a SAQ-A that has only a few mandatory controls to meet your PCI obligations.

The moment your site does ANY processing, storage or transmission of CHD, your PCI obligations increase. You might now have to fill in a SAQ-D for example. SAQ-D has a lot more mandatory controls that has to be adhered to.

If your site grows big enough and you have a QSA or Aquirer review it, you will have a hard time convincing anyone that your site does not store, process or transmit sensitive CHD. If you want to persist in creating your own site, review the various SAQ options to see what controls you will need to consider in your design.


No, data sent by fax is not encrypted. A fax is essentially a series of pixels sent as tones over a phone line. If the phone line is secure, the data being sent is exactly as secure as a phone conversation - with exactly the same risks of being overheard, but a slightly different requirement for receiving it. If an attacker can intercept the message, they can get the same output as your intended recipient.


userWorkstations attribute in AD preventing users from logging into WebApp

If you add a domain controller in the list of Logon Workstations for a user account, you are saying that the specific account is not restricted, from the account level, from logging onto that DC. However, this does not bypass other security such as Allow logon locally or Allow log on through Remote Desktop Services. So, for example, if user jsmith's account has dc1 in Logon Workstations, this doesn't automatically mean that jsmith really can log onto dc1. It just means that the settings on the account does not prevent it.

One drawback of this scenario is that it is confusing: If an administrator looks at jsmith's list of Logon Workstations and sees a domain controller, he or she may wonder why this attribute is set on this account (particularly if the account is not noticeable as some kind of administrative account). Good system documentation can mitigate this confusion.


Most often, these break-ins occur through the application itself. If your encryption is transparent to the app, or to the part of the app through which the break-in occurs (i.e. encryption happens in a function called for any input/output data), then it is not adding any security.

At the same time if your encryption functions are only used explicitly in a few pages, then, say, SQL injection in another form will get the attacker only encrypted data.

In sum, limit the accessibility of unencrypted data throughout your app and check the remaining few places for at least SQL injection (use prepared statements). No need to encrypt the PHP itself - it is not going to help much against a determined attacker.


How is HTTPS/SSL able to hide destination website that one is connecting to?

Don't mistake security with privacy.

The task of SSL/TLS is security, not privacy.
This means the data itself are encrypted but meta data like source and destination IP, hostname (with SNI as used by all modern browsers), payload size and timing etc are not. And all these can be used to make a browsing profile of you which includes the sites you visit and sometimes even which pages you visit on the site (based on timing and payload size). But SSL/TLS makes sure that the non-public content (like cookies, form data etc) is protected against sniffing and manipulation.

If you want better privacy you need to combine SSL/TLS with something like Tor, but even this can not guarantee full privacy.


DSA Generates different signatures with the same data

Traditional implementations of DSA choose a random nonce for each signature operation. This leads to a different signature, even when signing the same data. The problem is not that the signature is different each time, it's your wrong expectation that it should be the same.

Check Wikipedia on DSA for details:

  Signing

  Generate a random per-message k
  Calculate r from k
  Calculate s from r and the private key
  The signature is (r,s)

Since k differs for each message, the signature is different as well. This random k is essential to the security of DSA.

A nice alternative to a random $k$ is deriving it from the private key and the message hash via hashing. This behaves like a random value from an attacker's point of view, but prevents catastrophic failure when generating a signature using a weak PRNG. This approach will result in the same signature when signing the same data. RFC6979 - Deterministic Usage of the Digital Signature Algorithm (DSA) and
           Elliptic Curve Digital Signature Algorithm (ECDSA) specifies a way for doing this.

You shouldn't try to verify a DSA signature by signing again and comparing. You should use the specialized verification operation using the public key. Signatures are useful because you don't need the private key in order to verify a signature.

If you can use the same key for signing and verification, you should consider using a MAC instead of a signature. HMAC-SHA-2 is the one I recommend.


Doesn't adding requirements to a password, such as must contain 2 digits, decrease the strength?

I think you may have missed a subtle part of the policy:

You must have a minimum length.
You must have a minimum number of letters.
You must have a minimum number of numbers.

From a purely statistical perspective, let's look at the possible reduction in keyspace. My apologies if it's a bit hard to follow, but you'll understand my reasons for it as you get towards the end.

First, we'll look at the possible lengths for a password. In theory, your possible lengths fit into the set ℤ+, i.e. all positive integers. This set is uncountable, i.e. infinite in length. As such, any set with bounds {n→∞} is always uncountable, as long as n<∞. So for any non-infinite length password your length requirement will not change the number of possible lengths. Let's define a function ƒL that gives us the length of any arbitrary password, for further use.

Next, let's look at the numbers of letters and numbers. Since the domain of our function ƒL is at most {1→∞}, and at least {n→∞} for n<∞, we know that it is uncountable. Computing the number of permutations for a character set C and a length L requires us to compute CL, i.e. C raised to the power of L - let's call this ƒS. We do this commonly for determining the number of possible values storable in an n-bit binary string, by computing 2n, so it should be a familiar task. Unfortunately, L in our case is not a defined number; it's a function. So we're really trying to compute C raised to the power of ƒL, which is rather meaningless since the output of ƒL could be any positive integer. However, we can observe the behaviour of this operation - since the outputs of ƒL are an uncountable set, any value of C would always cause produce an uncountable set too. As such, for any value of C, ƒS always produces an uncountable set, and therefore the keyspace remains infinite regardless of the character set, as long as the possible lengths of the password fit into the set ℤ+.

Now, all of the previous was purely theoretical, and largely nonsensical in any applicable way. In practice you couldn't allow a 2×10100 character password, so you do actually have a limit. As such, the set ƒL becomes countable, and therefore the set ƒS becomes countable too, and by definition is now dependant on the value of C. But to what extent does this matter?

The answer is not based in mathematics, and this is precisely why I've taken you on a circuitous and verbose route to this point. It's not about the numbers, it's about the people. We've seen, time and time again, the bad password practices employed by the masses. The password dumps leaked after breaches of major sites like LinkedIn, Sony and Gamigo have demonstrated how horribly common poor passwords (like "letmein" and "dragon") are. The holy grail of password policy is one that makes users pick passwords that are resistant to manual guessing and bruteforce attempts, yet remain memorable enough that the user doesn't have to re-use passwords. The holy grail does not exist. You cannot possibly make every single user adhere to perfect password policies.

Providing a password policy that brings some absolute minimum requirements (one letter, one number, minimum 7 characters) is enough to bring 100% of the offenders over to a non-dictionary password, 80% of them over to a non-common password, and kill off 90% of common passwords. That means you've successfully reduced your attack surface for low-hanging-fruit attacks by at least 80%, which is a big win. Furthermore, you've not dented your conversion rates on signup, since basic password policies are standard practice to most users.

So, whilst you may be theoretically reducing your character space, it's a poor measure of password security and a complete tangent to the real goal of increasing security. Password policies are about people, not numbers, and as such must be studied as a psychological mechanism, not a mathematical one.


how do we encrypt 100bits of plain text to get 100bits cypher text using DES?

DES is a block cipher, which means that it processes blocks of a fixed size. When you want to encrypt a message, i.e. a sequence of bits whose length is not necessarily that of a single block, you need to apply a mode of operation that applies the block cipher "properly" to encrypt and decrypt a message.

The Wikipedia page has nice schematics. Each mode of operation has its own requirements on the input length; for instance, the CBC mode requires that the input length is an exact multiple of the block size. Thus, CBC requires some padding and invariably results in a ciphertext that is larger than the plaintext. Some other modes can do an exact bit-to-bit encryption (encrypt k bits into exactly k bits, for all k), notably OFB, CFB and CTR. CBC can also be made padding-less with CTS ("ciphertext stealing") as long as the input size is at least as long as a block.

Note, though, that almost all modes of operations need an Initialization Vector, which must be chosen by who encrypts and conveyed to who decrypts; if the IV cannot be inferred from the context, then it must be transmitted, which increases the network requirements. IV selection is crucial for security; some modes need a fully random, unpredictable IV, while some others can achieve security with a non-repeating IV, but a fixed, hardcoded IV will usually be no good at all.

An IV-less mode that turns 100 bits of plaintext into 100 bits of ciphertext would need to be deterministic (this is a mathematical necessity); thus, such a mode would necessarily reveal if two encrypted messages are identical. This may or may not be a problem, depending on usage context. A secure IV-less mode is an IV-less mode that leaks exactly that information but no more. To my knowledge, there is no standard for a secure IV-less mode, but there are some known academic constructions (this one can be made practical; that one is theoretically "better" but a lot less practical).

There are still some remarks to be made. First and foremost, DES is obsolete and weak, precisely because of its key length: the 56-bit key is within reach of an exhaustive search (substantial effort, but achievable, even by amateurs with a moderate budget). 3DES is much stronger, but also three times slower (while DES was already quite slow in "normal" software). Both DES and 3DES use 64-bit blocks, which are a bit too narrow (this can raise security issues when encrypting lots of data with a single key). 3DES is also deprecated; modern protocols should use AES, whose blocks are larger (128 bits), avoiding these security issues. AES is also substantially faster than 3DES.

Also, encryption need to be applied in contexts where there is a need for confidentiality against eavesdroppers. In most such contexts, the attackers can also be active, i.e. alter data in transit. Alterations can be reliably detected through the use of a MAC, but this necessarily increases the message size (again because of the pigeons). Combining encryption and MAC is not easy at all, and successive messages must be somehow "linked" together to defeat replay attacks and other alterations at the packet level. All of this is supposed to be handled by defining a secure protocol: a protocol is an assembly of elementary cryptographic algorithms (e.g. AES) to provide some well-defined security properties. An example of a protocol is TLS. Designing a secure protocol is even harder than designing a secure algorithm; even implementing an already defined protocol is hard to do properly (i.e. without leaking secret information).


Is VLC on Linux vulnerable to an attack from .wmv files designed to install viruses?

Video files by themselves can not contain a "virus" in the classical sense but they can be used to exploits bugs in the media players (or sometimes even the OS) when handling the file formats and codecs. By using these exploits they can then execute code.

Like most video players vlc also has/had lots of bugs which could be exploited, including in the handling of WMV files. But it is unlikely that antivirus will find such exploits because they usually don't know much about codecs and don't even scan video files. Since such exploits are usually OS specific and most care only about Windows because of the market share you are probably safe nevertheless with Linux unless you got specifically targeted.


How do I deal with a compromised server?

Originally from serverfault. Thanks to Robert Moir (RobM)

It's hard to give specific advice from what you've posted here but I do have some generic advice based on a post I wrote ages ago back when I could still be bothered to blog.

Don't Panic

First things first, there are no "quick fixes" other than restoring your system from a backup taken prior to the intrusion, and this has at least two problems.

It's difficult to pinpoint when the intrusion happened.
It doesn't help you close the "hole" that allowed them to break in last time, nor deal with the consequences of any "data theft" that may also have taken place.

This question keeps being asked repeatedly by the victims of hackers breaking into their web server. The answers very rarely change, but people keep asking the question. I'm not sure why. Perhaps people just don't like the answers they've seen when searching for help, or they can't find someone they trust to give them advice. Or perhaps people read an answer to this question and focus too much on the 5% of why their case is special and different from the answers they can find online and miss the 95% of the question and answer where their case is near enough the same as the one they read online.

That brings me to the first important nugget of information. I really do appreciate that you are a special unique snowflake. I appreciate that your website is too, as it's a reflection of you and your business or at the very least, your hard work on behalf of an employer. But to someone on the outside looking in, whether a computer security person looking at the problem to try and help you or even the attacker himself, it is very likely that your problem will be at least 95% identical to every other case they've ever looked at.

Don't take the attack personally, and don't take personally the recommendations that follow here or that you get from other people. If you are reading this after just becoming the victim of a website hack then I really am sorry, and I really hope you can find something helpful here, but this is not the time to let your ego get in the way of what you need to do.

You have just found out that your server(s) got hacked. Now what?

Do not panic. Absolutely do not act in haste, and absolutely do not try and pretend things never happened and not act at all.

First: understand that the disaster has already happened. This is not the time for denial; it is the time to accept what has happened, to be realistic about it, and to take steps to manage the consequences of the impact.

Some of these steps are going to hurt, and (unless your website holds a copy of my details) I really don't care if you ignore all or some of these steps, but doing so will make things better in the end. The medicine might taste awful but sometimes you have to overlook that if you really want the cure to work.

Stop the problem from becoming worse than it already is:

The first thing you should do is disconnect the affected systems from the Internet. Whatever other problems you have, leaving the system connected to the web will only allow the attack to continue. I mean this quite literally; get someone to physically visit the server and unplug network cables if that is what it takes, but disconnect the victim from its muggers before you try to do anything else.
Change all your passwords for all accounts on all computers that are on the same network as the compromised systems. No really. All accounts. All computers. Yes, you're right, this might be overkill; on the other hand, it might not. You don't know either way, do you?
Check your other systems. Pay special attention to other Internet facing services, and to those that hold financial or other commercially sensitive data.
If the system holds anyone's personal data,  immediately inform the person responsible for data protection (if that's not you) and URGE a full disclosure. I know this one is tough. I know this one is going to hurt. I know that many businesses want to sweep this kind of problem under the carpet but the business is going to have to deal with it - and needs to do so with an eye on any and all relevant privacy laws.

However annoyed your customers might be to have you tell them about a problem, they'll be far more annoyed if you don't tell them, and they only find out for themselves after someone charges $8,000 worth of goods using the credit card details they stole from your site.

Remember what I said previously? The bad thing has already happened. The only question now is how well you deal with it.

Understand the problem fully:

Do NOT put the affected systems back online until this stage is fully complete, unless you want to be the person whose post was the tipping point for me actually deciding to write this article. I'm not going to link to that post so that people can get a cheap laugh, but the real tragedy is when people fail to learn from their mistakes.
Examine the 'attacked' systems to understand how the attacks succeeded in compromising your security. Make every effort to find out where the attacks "came from", so that you understand what problems you have and need to address to make your system safe in the future.
Examine the 'attacked' systems again, this time to understand where the attacks went, so that you understand what systems were compromised in the attack. Ensure you follow up any pointers that suggest compromised systems could become a springboard to attack your systems further.
Ensure the "gateways" used in any and all attacks are fully understood, so that you may begin to close them properly. (e.g. if your systems were compromised by a SQL injection attack, then not only do you need to close the particular flawed line of code that they broke in by, you would want to audit all of your code to see if the same type of mistake was made elsewhere).
Understand that attacks might succeed because of more than one flaw. Often, attacks succeed not through finding one major bug in a system but by stringing together several issues (sometimes minor and trivial by themselves) to compromise a system. For example, using SQL injection attacks to send commands to a database server, discovering the website/application you're attacking is running in the context of an administrative user and using the rights of that account as a stepping-stone to compromise other parts of a system. Or as hackers like to call it: "another day in the office taking advantage of common mistakes people make".

Why not just "repair" the exploit or rootkit you've detected and put the system back online?

In situations like this the problem is that you don't have control of that system any more. It's not your computer any more.

The only way to be certain that you've got control of the system is to rebuild the system. While there's a lot of value in finding and fixing the exploit used to break into the system, you can't be sure about what else has been done to the system once the intruders gained control (indeed, it's not unheard of for hackers that recruit systems into a botnet to patch the exploits they used themselves, to safeguard "their" new computer from other hackers, as well as installing their rootkit).

Make a plan for recovery and to bring your website back online and stick to it:

Nobody wants to be offline for longer than they have to be. That's a given. If this website is a revenue generating mechanism then the pressure to bring it back online quickly will be intense. Even if the only thing at stake is your / your company's reputation, this is still going generate a lot of pressure to put things back up quickly.

However, don't give in to the temptation to go back online too quickly. Instead move as fast as possible to understand what caused the problem and to solve it before you go back online or else you will almost certainly fall victim to an intrusion once again, and remember, "to get hacked once can be classed as misfortune; to get hacked again straight afterward looks like carelessness" (with apologies to Oscar Wilde).

I'm assuming you've understood all the issues that led to the successful intrusion in the first place before you even start this section. I don't want to overstate the case but if you haven't done that first then you really do need to. Sorry.
Never pay blackmail / protection money. This is the sign of an easy mark and you don't want that phrase ever used to describe you.
Don't be tempted to put the same server(s) back online without a full rebuild. It should be far quicker to build a new box or "nuke the server from orbit and do a clean install" on the old hardware than it would be to audit every single corner of the old system to make sure it is clean before putting it back online again. If you disagree with that then you probably don't know what it really means to ensure a system is fully cleaned, or your website deployment procedures are an unholy mess. You presumably have backups and test deployments of your site that you can just use to build the live site, and if you don't then being hacked is not your biggest problem.
Be very careful about re-using data that was "live" on the system at the time of the hack. I won't say "never ever do it" because you'll just ignore me, but frankly I think you do need to consider the consequences of keeping data around when you know you cannot guarantee its integrity. Ideally, you should restore this from a backup made prior to the intrusion. If you cannot or will not do that, you should be very careful with that data because it's tainted. You should especially be aware of the consequences to others if this data belongs to customers or site visitors rather than directly to you.
Monitor the system(s) carefully. You should resolve to do this as an ongoing process in the future (more below) but you take extra pains to be vigilant during the period immediately following your site coming back online. The intruders will almost certainly be back, and if you can spot them trying to break in again you will certainly be able to see quickly if you really have closed all the holes they used before plus any they made for themselves, and you might gather useful information you can pass on to your local law enforcement.

Reducing the risk in the future.

The first thing you need to understand is that security is a process that you have to apply throughout the entire life-cycle of designing, deploying and maintaining an Internet-facing system, not something you can slap a few layers over your code afterwards like cheap paint. To be properly secure, a service and an application need to be designed from the start with this in mind as one of the major goals of the project. I realise that's boring and you've heard it all before and that I "just don't realise the pressure man" of getting your beta web2.0 (beta) service into beta status on the web, but the fact is that this keeps getting repeated because it was true the first time it was said and it hasn't yet become a lie.

You can't eliminate risk. You shouldn't even try to do that. What you should do however is to understand which security risks are important to you, and understand how to manage and reduce both the impact of the risk and the probability that the risk will occur.

What steps can you take to reduce the probability of an attack being successful?

For example:

Was the flaw that allowed people to break into your site a known bug in vendor code, for which a patch was available? If so, do you need to re-think your approach to how you patch applications on your Internet-facing servers?
Was the flaw that allowed people to break into your site an unknown bug in vendor code, for which a patch was not available? I most certainly do not advocate changing suppliers whenever something like this bites you because they all have their problems and you'll run out of platforms in a year at the most if you take this approach. However, if a system constantly lets you down then you should either migrate to something more robust or at the very least, re-architect your system so that vulnerable components stay wrapped up in cotton wool and as far away as possible from hostile eyes.
Was the flaw a bug in code developed by you (or someone working for you)? If so, do you need to re-think your approach to how you approve code for deployment to your live site? Could the bug have been caught with an improved test system, or with changes to your coding "standard" (for example, while technology is not a panacea, you can reduce the probability of a successful SQL injection attack by using well-documented coding techniques).
Was the flaw due to a problem with how the server or application software was deployed? If so, are you using automated procedures to build and deploy servers where possible? These are a great help in maintaining a consistent "baseline" state on all your servers, minimising the amount of custom work that has to be done on each one and hence hopefully minimising the opportunity for a mistake to be made. Same goes with code deployment - if you require something "special" to be done to deploy the latest version of your web app then try hard to automate it and ensure it always is done in a consistent manner.
Could the intrusion have been caught earlier with better monitoring of your systems? Of course, 24-hour monitoring or an "on call" system for your staff might not be cost effective, but there are companies out there who can monitor your web facing services for you and alert you in the event of a problem. You might decide you can't afford this or don't need it and that's just fine... just take it into consideration.
Use tools such as tripwire and nessus where appropriate - but don't just use them blindly because I said so. Take the time to learn how to use a few good security tools that are appropriate to your environment, keep these tools updated and use them on a regular basis.
Consider hiring security experts to 'audit' your website security on a regular basis. Again, you might decide you can't afford this or don't need it and that's just fine... just take it into consideration.

What steps can you take to reduce the consequences of a successful attack?

If you decide that the "risk" of the lower floor of your home flooding is high, but not high enough to warrant moving, you should at least move the irreplaceable family heirlooms upstairs. Right?

Can you reduce the amount of services directly exposed to the Internet? Can you maintain some kind of gap between your internal services and your Internet-facing services? This ensures that even if your external systems are compromised the chances of using this as a springboard to attack your internal systems are limited.
Are you storing information you don't need to store? Are you storing such information "online" when it could be archived somewhere else. There are two points to this part; the obvious one is that people cannot steal information from you that you don't have, and the second point is that the less you store, the less you need to maintain and code for, and so there are fewer chances for bugs to slip into your code or systems design.
Are you using "least access" principles for your web app? If users only need to read from a database, then make sure the account the web app uses to service this only has read access, don't allow it write access and certainly not system-level access.
If you're not very experienced at something and it is not central to your business, consider outsourcing it. In other words, if you run a small website talking about writing desktop application code and decide to start selling small desktop applications from the site then consider "outsourcing" your credit card order system to someone like Paypal.
If at all possible, make practicing recovery from compromised systems part of your Disaster Recovery plan. This is arguably just another "disaster scenario" that you could encounter, simply one with its own set of problems and issues that are distinct from the usual 'server room caught fire'/'was invaded by giant server eating furbies' kind of thing.

... And finally

I've probably left out no end of stuff that others consider important, but the steps above should at least help you start sorting things out if you are unlucky enough to fall victim to hackers.

Above all: Don't panic. Think before you act. Act firmly once you've made a decision, and leave a comment below if you have something to add to my list of steps.


No, the only way to change the validity date is to re-issue.

The reason is that the certificate's hash is calculated after the rest of the certificate is written, editing that field would cause the certificate's hash to change. If the hash is changed anyone else checking the certificate will know it has been altered, but won't be able to tell what changed. While this won't automatically prevent a connection, it will throw errors and warnings.


For example if an outer volume is created of 5 GB and an inner volume
  is created with 4 GB. An advisory forces the owner to reveal the
  password but is given the decoy password to the outer volume. Then the
  attacker wouldn't be able to write more than 1 GB (at the most) before
  seeing that there's a hidden volume.

It would not work like that. If forced, the owner would reveal only the outer volume password, and deny there is any other.

Then the attacker would be able to write to the whole 5GB, thrashing the secret data but unaware of its existence.

The owner, instead, while maintaining the outer volume, would give both password and so be safe against inadvertent overwrite of his "true" data.

  Also, what kind of "fake" sensitive files should go in the outer
  volume? If you think about it, it's not that easy to make fake
  confidential looking documents. You wouldn't be able to store any
  online passwords because they could be verifies as false easily.

You would just put in there something which you plausibly wouldn't want revealed, not necessarily confidential. Depending on the situation, some embarrassing flavour of porn might do. It would also help explain why the files aren't all that up to date; the "secret volume" is mainly there to be read (well, viewed), and gets only occasionally enlarged with new porn.


Impersonating Client Certificate Authentication with Same Subject Name

Good question. With C# and .NET it is hard to limit a number of trusted root CAs via X509Chain class you will use to validate chains. This class doesn't offer such functionality (although, underlying CertCreateCertificateChainEngine native function allows this via CERT_CHAIN_ENGINE_CONFIG.hRestrictedRoot, bit it is long story).

In Active Directory, for example, this question is solved by introducing an NTAuthCertificates record under CN=Public Key Services, CN=Services, CN=Configuration, {ConfigurationNamingContext} which stores CA certificates (direct issuers) which are allowed to issue smart card logon and client authentication certificates. Domain controller during smart card logon performs general path building and validation, then gets issuer (from validated chain) and checks if it is listed in NTAuthCertificates. If everything is ok, then certificate logon continues, otherwise, it fails.

I would suggest to go same way. Maintain a collection of CAs (again, direct issuers, not roots) which are approved by your policy to issue authentication certificates. You can store whole certificates, their thumbprints, public keys or whatever that helps you to strongly identify them.


How does KeePass master key derivation increase security?

The key derivation is entirely to take the users password and turn it into a 256bit long key to use whatever it's length and hopefully in a secure way.

If running a pure brute-force, yes one could directly guess the key by cycling through all possible patterns that are 256bit long, for this one wants to be sure the key derivation can't narrow the possible key space so all 256bit long keys are still possibilities.

One could try running a dictionary attack and passing all the dictionary words through the key derivation function to generate keys to try one of the points of the key derivation is to make this slow enough that this is not sensible on given hardware.

Now there are some flaws in the pseudo-code you gave depending on a couple of functions (CreateSecureRandomKey() would need to give the same data every time one opens the database to get the same key to use), I'm not sure as I would have to look into key derivation in KeePass myself.


Consequences of the WPA2 KRACK attack on older Windows and iOS clients

I suspect that some parts of KRACK are still applicable to both older Windows and older iOS devices.

The group-key handshake issue (CVE-2017-13080) has a Windows security advisory, but unsupported OSes like Vista and XP are not listed (unsurprisingly). Given that this is a protocol-level issue that has been in place for a very long time, and given that all actively supported versions of Windows are affected, my guess is that XP and Vista are also be affected. (It's also important to note both that paid XP support is still theoretically available, and that the Qualys advisory includes XP Embedded in its detection list for this CVE.)

The impact, from the paper:

  By forcing nonce reuse in this manner, the data-confidentiality
  protocol can be attacked, e.g., packets can be replayed, decrypted,
  and/or forged. The same technique is used to attack the group key,
  PeerKey, and fast BSS transition handshake.

The fast BSS issue (CVE-2017-13082), by contrast, does not appear to have an associated Microsoft security bulletin at all that I could find. At first, I tentatively concluded that no Microsoft products are actually subject to this specific CVE - but then I realized that others have been unable to locate any of the other specific CVEs in Microsoft references.

However, CVE-2017-13082 is an AP-side issue that can only be fully remediated by patching the AP. It's possible that if a device is using Vista or XP in Internet Connection Sharing and it is acting as an AP, then it might be subject to the fast BSS issue. [Edit: there is some evidence that ICS does not use 802.11r]

If so, the impact would therefore be the same as for other platforms - a specific kind of spoofing in which replaying frames from the access point to the client is possible. From the paper:

  When the 4-way or fast BSS transition handshake is attacked, the
  precise impact depends on the data-confidentiality protocol being
  used. If CCMP is used, arbitrary packets can be decrypted. In turn,
  this can be used to decrypt TCP SYN packets, and hijack TCP
  connections. For example, an adversary can inject malicious content
  into unencrypted HTTP connections. If TKIP or GCMP is used, an
  adversary can both decrypt and inject arbitrary packets.

On the iOS side, since iOS didn't strictly implement the protocol spec and sidestepped most of the client-side issues, and according to this article, the iOS patch primarily helps iOS clients to mitigate unpatched AP-side-specific issues.

Also, since iOS implements 802.11r, it's vulnerable to that subset of the CVEs. This is covered more thoroughly in this answer.


The difference between jailing, sandboxing and interpretation

I hear in these terms an attempt to explain at a higher level of abstraction a continuum of ways to approach the problem of hosting executable code on a system you wish to protect.

Native: allow executable code to run normally on the target system with full rights and privileges of other code on the system
Jail: allow executable code to run normally on the target system except that access to sensitive resources- from specific syscalls to specific APIs to resources like disk or network i/o- whatever is appropriate for the context- is blocked in some fashion. Think of this as a blacklist- a policy of default allow with specific deny rules.
Sandbox: a more restrictive environment than a Jail. Executable code runs in an abstraction of the target system, though some limited direct access to sensitive resources is allowed. Think of this as a whitelist- a policy of default deny (well, default abstracted/faked) with some specific allow rules.
Interpret: is a poor term for the concept, which represents the other end of the spectrum from Native. Executable code is run in a completely abstracted environment with no direct interaction at all with resources on the target system. A better term may be "Simulated."

Hope that helps.


Samsung SSD 850 EVO. Best way to protect personal data against thiefs

For Samsung 850 drives and other SSDs, your best and most secure option is to use the OPAL full-disk encryption by enabling a drive password in your system's BIOS.

The way the encryption on these SSDs works is that the drive is always encrypted -- it comes from the factory with an encryption key generated and set.   All data it writes and reads is encrypted/decrypted with this key, nothing is written unencrypted.

When you set a password in BIOS, the drive encrypts the encryption key (stored in the drive controller) with the password you supply.  Thus, until you enter the password and give the drive the key it needs to decrypt it's own encryption key, all the data is unreadable -- even to the SSD itself.   Additionally you can't issue any SATA commands or even format/repurpose the drive without supplying this password.

Note that this is transparent to the operating system -- the encryption is handled at the hardware level, and decryption at startup via the BIOS.  The OS, no matter what it is, will just see a regular SSD and interact with it normally.

When you use the Samsung software to conduct a "Secure Erase" of an SSD, it actually doesn't 'erase' anything in the pure sense of the word.  With SSDs, each write/rewrite of a sector can be easily recovered through forensic analysis.  If that data was encrypted, you can still recover it -- so long as you have the encryption key.  What the "secure erase" facility does is reset the drive's internal AES encryption key to a new one; effectively resetting the drive.  Thus, all the old information on the drive which could be recovered by forensics is now encrypted/unreadable even to the drive itself, making recovery of the data exponentially more challenging if not impossible.

The drive controller itself handles the password.  If your BIOS supports OPAL or SED drives, you cannot bypass drive encryption using the supervisor password of the BIOS to change the disk password.  Even if logged into BIOS with a supervisor password, you will be unable to change the password on an OPAL/SED SSD (if your BIOS supports this properly) without supplying the existing SSD password.  If you can, that means your BIOS never communicated with the drive to set the password in the first place.  If this was the case, the BIOS doesn't support OPAL and you could also simply plug the SSD into another computer and image the data unhindered. Most drive manufacturers offer tools you can use to check this and see if the drive's status is "encrypted," meaning a password has been set.

Note that TrueCrypt has now been retired and there's rampant speculation as to whether the project's codebase may have been compromised by some entity like a government agency; or if the creators simply retired.  Here's an article with some information.

Also note the vulnerability of full disk encryption is that your data is protected when the encrypted data is not in use/the encryption key is not in memory -- meaning when your computer is on and in use. If an adversary got ahold of your computer while it was running, it is possible (although difficult) for them to recover the key from the system BIOS/drive controller memory.

Of course, full disk encryption also won't protect you from the effects of malware or other compromises when the system is running as well.

Links

Samsung's marketing site noting Samsung 850 SSD's support OPAL encryption

Samsung SSD White Paper detailing how encryption works


How does a debit/credit card reader verify the PIN so quickly?

In fact, in many cases, the PIN is in the card. There are a lot of possible situations, not all of them well documented, and they are subject to evolution over time.

Some cards do not have the PIN code on the card in any way; at least, that was the case for Amex cards about 15 years ago, because you could change the PIN over a phone call.

Some cards have an encrypted copy of the PIN on the magnetic stripe. This can be decrypted into some secured facilities that have a copy of the relevant decryption key; an ATM or selling point could maintain a live connection to one of these facilities, and still take some time to contact the bank that actually manages the account.

Smart cards, with a chip, know the PIN code and can verify it. That's the main point of smart cards: the chip is tamper-resistant, thus can hold secrets; these secrets can be unlocked through authentication with a PIN code; the chip will autolock itself if too many wrong PIN values are presented. When the card is a smart card, PIN verification goes as fast as the card chip can do it, normally a fraction of a second.

(A tamper-resistant smart card does not prevent the overall protocol from doing something stupid which nullifies security; e.g., see this recent article that describes an actual case of fraud due to a protocol flaw.)


Safe way to store credentials for an application

A possible way to achieve this is to have an optional configuration file - that is not in the repository but handled separately from the source code - from which those values are read.

You may include a demo configuration with placeholders in the repo for release though.

Also, with such a way, it will be easy to modify for users for different deploy targets.


Alternatives to SMS as a out-of-band channel

Expiring your SMS token in 20 minutes will not mitigate the attack. Bad actors can either use SS7 routing attacks, or social engineering to gain access to your text messages. The social engineering attacks are much lower tech and easy to do. They essentially involve:

Calling your cell phone provider
Authenticating as you, or just convincing the customer service rep to help them. (See: https://youtu.be/lc7scxvKQOo?t=30s). The recent Equifax breach makes this even easier since bad guys can now answer your security questions as well (in many cases).
Changing the IMEI of your phone to their burner phone (like what happened here: https://carpeaqua.com/2017/07/07/hack-the-planet/).
Initiating password resets (to your email or other services) with text messages, which are now routed to the burner phone.

Once they have gained control and access to a few key accounts (your text messages and your primary email) they have the keys to the kingdom, and can take over - resetting passwords and locking you out of accounts as fast as they can. Typically, it takes people around 1 hour to figure out they got hacked. But, even if you notice in 15 minutes, it's very possible you've already lost control of key accounts, and it will take some time to get back in. During that time, the bad actors are routing around in your personal information collecting data and planning the next move, which includes further locking you out.

For strong, out of band 2FA, very little exceeds the security of time based one-time passwords, which Google authentication Yubikey utilize.

There are a number of libraries you can use to generate the 2FA keys. Here are some examples:

PHP: https://github.com/RobThree/TwoFactorAuth
Python: https://github.com/pyotp/pyotp
JavaScript: https://github.com/jiangts/JS-OTP (caution here. I am hesitant to use client side code to do this authentication. Server side is best.

I'm a little concerned OWASP hasn't updated their list in light of both the NIST recommendations as well as the Equifax breach, which puts people's security questions at risk. Perhaps they have their reasons. Speculating on what those reasons are, it could be that security questions don't have to be answered truthfully. Example: when asked: "What street did you grow up on?" I typically answer with a GUID. This, of course, requires the use of a password manager like LastPass and / or KeePass to keep track. But, security requires effort. Also, social media is a gold mine of security questions and answers. So, perhaps the recommendations don't need to change ... yet.


Easy to use, simple, secure password storage method?

There have been a few "encrypting text editors" around for a long time. I don't know what kind of longevity most of them have, really. UltraEdit will encrypt text files and it's been around forever. A short search sort of turned up these alternatives:

http://www.ultraedit.com/support/tutorials_power_tips/ultraedit/encrypt_decrypt_text_files.html

http://www.andromeda.com/people/ddyer/notepad/NotepadCrypt-technotes.html

http://sourceforge.net/projects/enotes/

http://safepad.codeplex.com/

http://www.cnet.com/how-to/how-to-encrypt-selected-text-and-entire-text-files-with-notepad/

Cryptography can be really tough to do right, so you want to investigate the background of whichever solution you choose. If you roll your own, you want to design it carefully, or you end up making promises that you aren't really keeping. You have to decrypt the data to view it. But when you decrypt it you have to store it and present it. Where do you do that? If you write it to disk unencrypted, even inadvertently via temp files that your app may create, then you've compromised the integrity of your solution. If you decrypt it only to memory, that's good, but you have to be able to securely overwrite it when your program exits, and it is potentially vulnerable while your program is running. If you're using a garbage-collected development tool like most modern ones (Java, .NET C#/VB, etc.), then you don't really have control over what the GC does with the memory your strings are stored in. It might be a very long time before that memory is actually cleared. In the case of .NET, strings are immutable (you can't overwrite them), but there is a secure string class that is overwritable (but harder to use). Or you can pin memory in unmanaged code sections and have your way with it. Which is also harder. But then you still have to consider the possibility of cleartext copies of your data ending up in the Windows paging file (or Linux/UNIX swap file), and so on.

Cryptography is just hard to get "right."  :-)


Using personal computer on my company's "guest" wifi

The company could log what sites you go to and record the traffic, if the connections are not encrypted then they could recover the entire session and know what you did. If you are using https, i.e. TLS to connect then they will only be able to see what sites you went to, not what you actually did, this means you'd want to be careful of what sites you go to.

If you want to make sure they cannot see what you are doing then using something like TOR would be a good choice, however I would recommend you don't violate your employee code of conduct or company's acceptable use policy when on their site, even when using your own computer.


A String that if encrypted or decrypted with the same key gets an English word/statement in both cases

If you're looking for a simple and novel way to do this, why not assign each word w an integer value, and each word m in the message an integer value, then map them across based on the key? As long as your mapping w <==> m doesn't exceed word group boundaries (e.g. nouns, pronouns, verbs, adjectives, etc. are mapped to the same group) and your conjunctives are appropriately mapped, you could feasibly produce semi-legible sentences as your ciphertext. The mapping could quite easily be generated by seeding a PRNG with your key value.

Assuming that you don't care about leaking the grammatical structure of your plaintext, and that your mapping w <==> m is uniform and random within groups, you actually have a reasonable level of security for large plaintexts.

I certainly wouldn't use such a cipher for anything important, but it'd be very interesting to see the kinds of ciphertexts you might produce.


Path Truncation not working in PHP while exploiting LFI

"Realpath" finding was completely redone in this commit on August 12, 2008, in a way that is no longer vulnerable to the path truncation attack.  These changes were released in PHP 5.3.0, so no version newer than that will be vulnerable (unless the bug was reintroduced, which does not seem to have happened).

As an aside, there is no indication that anyone ever notified the PHP developers of this attack or that the fix for this attack was deliberate - it actually seems that it was fixed as a byproduct of fixing another bug.

Additionally, when used with NGINX and FastCGI, PHP is still vulnerable to a similar attack in which the PHP interpreter will process a request from the webserver even if the filename has extra stuff on the end.  However, the behavior that allows this attack is by design in both NGINX and PHP, so the only way to protect from it is to use one of the five listed workarounds.


For chip credit cards, what's preventing me from breaking the chip to trigger the magstripe failsafe?

As others have said: nothing. The idea is that the magstripe is a fallback that will be phased out completely as chip cards become more widespread.

Change takes time.


Found it

http://sla.ckers.org/forum/read.php?24,33349
http://security.bleurgh.net/javascript-without-letters-or-numbers
http://sla.ckers.org/forum/read.php?24,28687

Converter to convert normal JS into brackets only JS:

http://utf-8.jp/public/jjencode.html


Is it possible to attack bridged DSL modem?

Yes, it's possible to attack the modem if we're talking about a software bridge.

In that case, the software which copies packets from the incoming network interface buffer to the outgoing buffer of the other network interface can have flaws. For example, it might be susceptible to buffer overflows. If so, it could be possible for specially crafted packets to exploit that buffer overflow, which might lead to remote code execution on the modem. There might also be bugs in the network interface driver that might allow for remote code execution.

I wouldn't think it was very likely, however, especially if your modem is running on a well known software brand. The networking stack is well understood and time-tested; I'd doubt there are very many exploitable bugs left in the core code of, say, the linux networking stack.

  My understanding is that in such configuration DSL modem is unreachable from the WAN

Bridged mode means that your modem logically doesn't act like a router, but rather like a switch. It connects two physically separate networks together by transparently forwarding traffic from one segment to the other. This means that in bridged mode the DSL modem doesn't need IP addresses, just like a switch doesn't need IP addresses, and if it doesn't have an IP address, then attacks at or above the IP layer become pretty much impossible. But "unreachable" is misleading:

At the very least, traffic still flows through it, opening up the device to the attacks described above.
If you're using a serial console or a special, designated port for modem administration, the modem might really be "invisible" to every layer above the physical link layer. But assuming that you're using a normal web interface to configure it, chances are your modem will still have an IP address assigned (which is possible even in bridge scenarios) - otherwise your webbrowser couldn't connect to the admin interface. And depending on how well the device firewall is configured, the admin interface may even be accessible from the WAN in bridged mode, since logically there is only one network.

Also note that while you do add a layer of extra protection to the modem, you've opened up your whole internal LAN to the WAN. Every machine on your LAN is now visible on the WAN.


Captcha are one of the best way to stop spam bot so you will need them somewhere, but they are a pain for the user. That's why I like when I can authenticate in some way to a system which means that I don't have to answer a captcha everytime.

Session cookie are the way to go to identify a client. He logs in 1 time (or proves that he is not a bot 1 time by answering) a captcha then you give him a session id inside a cookie. Actually there are usually 2 cookies, a session cookie and an authentication cookie. The session cookie is created as soon as the user connect to your site, the authentication is created when he logs in.

For blocking user, you could either block them by IP address, username or by terminating the session (invalidating his session cookie, so he has to reanswer a captcha). But if you chose to do it by username you have to protect the username by a password or anyone could impersonate any username.

Also, if you don't want your user cookie or login information to be stolen (by someone listening on your web traffic), you will need to encrypt all the communication between the client and the server using HTTPS. Otherwise, your cookies and login information are not safe. If an attacker gain access to a cookie he can impersonates that person.

I see 2 alternatives

Alternative 1 : Username + Password

Ask for a unique username, a password and an answer to a captcha when creating the account. After that, the client can simply log in with a username + password. If one account is a spam bot you can either block the username and/or the IP address.

Alternative 2 : Username only

If you don't mind to have duplicate username you can use this way. Simply, ask for a username and the answer to a captcha then gives the user a session cookie to authenticate him afterward. Of course, blocking by username is no use here and you should instead do it by IP address or terminating session.


Should HSTS header be sent on an error response?

It would be wise to always force the HTTP Strict Transport Security (HSTS) header because the risk of not encrypting may be worse.

In this particular case it's a direct tradeoff between confidentiality and availability. For most but not all businesses confidentiality is more important.

If your business values the confidentiality more than availability then force HSTS if availability is more important then don't.

HSTS is also especially useful if your development teams are prone to poor security configurations on the servers behind the load balancer. HSTS allows an organization to enforce https which in general is a very good thing.

Note: In general there's also a hidden benefit to doing this on the load-balancer rather than at the webserver layer. If the load-balancer is responding with the HSTS header it's actually reducing some of the load off the systems behind it and reducing the round-trip page loading of the site to the https page. This reduces the load on the webserver a small amount and for some attacks this actually INCREASES the workload on the attacker.

For reference:
https://tools.ietf.org/html/rfc6797


It seems "they" are trying to get different ads through your server - expecting it to behave as an HTTP proxy server.  (Maybe your was misconfigured before to be an open proxy.)

Instead of sending a:

GET /filename.php HTTP/1.1

They're sending a

GET http://adhost.com/dir/file HTTP/1.1

This way, "they" will be able to render many ads for their websites, coming from different IP addresses, essentially driving up their impressions, and potentially getting more money.

Ensure your server is not an open proxy, and else - don't worry, bots send all kind of requests to any public webserver.


Is there a secure way to transfer data outside the Internet?

It really depends upon the specific threats you may be facing, the direction of your data transfers, etc.

USB specific dangers

You mention the dangers of USB. The main one is indeed related to its firmware opening the possibility of a BadUSB type attack. When you need to transfer data in both directions, you may therefore prefer to use SD-Cards which are not sensitive to such threats (if you use an external USB SD-Card reader, it should be safe but dedicate it to a single computer, don't share it!).

I insist here that I'm mentioning SD-Cards as a viable solution against USB firmware attacks only. In such attacks, a USB flash drive firmware may be corrupted in order to simulate rogue devices (fake keyboard, network card, etc.), such attacks are not possible with SD-Cards. I think this is the reason why we see Edward Snowden relying on SD-Cards in Laura Poitras' Citizenfour film when exchanging files between his own computer and the reporter's ones.

SD-Cards are also equipped with a read-only switch. While such switches are very convenient to prevent accidental modification of the card's content, they cannot be relied upon to prevent malicious modifications since read-only access is not enforced by the card itself but delegated to the computer's operating system.

Enforce a one-way communication

You talk about a possible leak of information by some malware on Alan's computer storing data in some hidden channel. If your transfers are mostly in one direction only and this is your main threat, then I suggest you use read-only media like CDs or DVDs. I don't know if there are still CD/DVD readers on the market, it would be the best since it would physically remove all possibility for Alan's PC to store any data on them, but even without that it would be by far harder to store any data discretely on such disk.

With some digging, you may also find some other alternatives, for instance in the thread how to protect my USB stick from Viruses you will see a discussion pertaining to USB sticks containing a write blocking switch (which works in a more secure way than the SD-Card's equivalent), the use of write blockers which are equipment normally designed for forensic purposes, etc.

Long distance communication

Implemented as-is, the solutions provided above suppose that Alan and Bob are in direct contact, which may not always be true. However, data transfers outside of any computer networks remains possible even on long distance, mostly by using usual postal mails, aka snail mail.

This method may be wrongly perceived as insecure by some people, while when used correctly it can actually present a very high security level. Such method is used by the industry when it is required to move a very large amount of data securely. Amazon provides his Amazon snowball service for such operation, Wikipedia's page about sneakernet also lists some other real-life usage examples, including funny experiments inspired from an April Fool's day RFC using carrier pigeon to carry the storage medium.

In our current scenario, Alan and Bob will need to take a few precautions to ensure everything goes fine:

Alice and Bob will need to exchange their public keys. This may sound simple, but in the concrete world Alan and Bob may have no possibility to meet even once, may not know each other and may have no common trusted third party to vouch for each other's identity or provide escrow service. However, the whole security of this system relies on the fact that this operation must be done successfully. Fortunately, asymmetric encryption greatly helps, since the leak of these keys will have no deep impact, but it will be of no help against an impersonation or tampering occurring at this step.
The chosen data exchange medium may have some importance since each may present different characteristics:

Firmware based storage devices are the most frequent nowadays, ranging from the hard disks with higher data volume to micro SD cards which can be very easily concealed. One may prefer to buy it from some physical store to avoid any initial tampering, but as we will see later the device will in all case be not trustable anymore once the first shipment occurred.
Non-firmware based device present obviously no firmware related issue, but depending on the exact needs of Alan and Bob they may present other issues in particular pertaining to anonymity: burned disks and printed paper for instance may contain unique identifiers allowing to link them to their author (such identifier does not allow the author location though, but once his equipment has been seized they can be used to prove that this equipment produced them).

Of course the data will need to be properly encrypted and signed before being stored on the medium. I would tend to prefer an encrypted file which can be more easily manipulated than an using directly an encrypted partition on the medium.
I strongly suggest for the data to be properly backed up before being sent. While such transfer is secure in the way that a potential opponent will not be able to access or tamper with the data even if he manages to intercept it, the data may still get lost or disappear (it can be the result of either a voluntary or involuntary action: it happens that parcels get lost or seized without any intervention from Big Brother, Murphy is very good at that too!).
Methods to obfuscate the actual sender and recipient (from PO boxes to more advanced stuff), when combined with concealment of the storage device, can help to avoid interception.
At least on the recipient side, I strongly advise to not connect the received storage device directly to the main computer, but instead:

Connect the received media to a specially hardened minimal system (aka a sheep dip, the host itself may have no hard-disk and boot from a LiveCD) where you will be able to quickly inspect media content and the encrypted file (do not decrypt it on this host!),
You may possibly want to copy the encrypted file to a more trusted support (here one case where using an encrypted file instead of an encrypted partition can be useful). Moving the encrypted file to another support may be especially useful if using a firmware base storage device since, once it went through the postal service, you cannot guaranty the firmware integrity anymore (while the encrypted data is signed, there is no signature you can check for the rest of the storage device).
Then you can connect this most trusted support on your main air gaped computer where you will be able to safely decrypt it, making this step the end of the story :).


Is there any way an attacker can access the server and modify the site (php) code?

Via uploading a file and executing it. Review uploads, php enabled functions and use 'noexec' (in UNIX/Linux) mount option on filesystem. If your app must execute local binaries, create a regular job to review which binaries are available to the app. Think about using chroot or namespaces for PHP app.


CHANGE YOUR PASSWORD  it has been compromised.

Politely inform this service provider that this is a very serious vulnerability.  Passwords must be reset,  and must never be stored in a recoverable format.  Further more this is the type of vulnerability is inexcusable,  use another service ASAP.  Tell them that you are no longer using their service out of very serious security concerns.   If they made this mistake,  just think of the other festering security problems.


I have not found information like this either, and I'm not sure it's available.  I recently used one of these disks with the harddrive password enabled. The AES encryption on these disks is this simple to use and performs excellently.

But there's no way to verify that it's actually working.  It is black box encryption.

A while back I answered a similar question about this kind of encryption on spinning disks:

Unlock hard drive vs full-disk encryption

  This is black-box encryption
  It's black-box because although they claim to use AES128, there's no reasonable way to verify it. And although they claim to do it properly, there's no way to inspect their implementation.

  A few years ago I sent them a simple question... if all the drives ship from the factory with encryption turned on, then how do they seed their random key?

  I never got an answer and I never heard anyone provide a reasonable explanation. For all we know, all the keys on all the drives are identical. Unless you have a method to bypass the drive electronics to read the raw, encrypted platters, you will never know. Even if you execute a ATA SE "secure erase" function to delete the key, you don't know how the new key is being generated.


Can a symmetric key be safely embedded anywhere in a .NET desktop client program

In such case the application code contains the key and the logic to extract it. An attacker can perform the same steps as the application logic and will extract the key.