Does it make a difference to use a VPN to access home services? Situation: I want to set up some home servers that can store my files. Currently in the planning stage of the setup.

Problem: Security and stuff comes to mind when doing such things, especially exposed servers.

Question: Does it make a difference if I set up a VPN server at home and only expose the VPN server vs exposing the file server (or any other server for that matter) to the internet?

If you don't use a VPN, then ask yourself the following questions:

How would the connection from your client to your file server be encrypted?
How would the client and the server mutually authenticate each other?
How would the keys used to build this encrypted connection be managed on the client and the server?
How strong is the encryption, and how strong are the keys?

VPN's are used, because they provide reasonably good solutions to all of the above problems.

If your public-facing file server provides acceptable solutions to all of the problems above, then maybe you can consider accessing the server directly, without using a VPN.  For example, using key-based authentication with an SSH server may be an acceptable solution in your case.

But even in this case, if the VPN is integrated with a hardware firewall protecting the server, this provides an additional layer of security - because the hardware firewall blocks stray packets from random bots, etc. from even reaching your server.  This way, in the event that a vulnerability is discovered in the file server (which would otherwise be public-facing without the VPN/firewall), the server is still protected by the firewall.


How are Tor packets decrypted on the client? I am a bit confused about packet decryption of Tor on the client.

I understand that if a client sends a request to a web server by using Tor, the request will be encrypted a couple of times, and sent to a Tor relay. The relay will decrypt a layer by using its private key, and when the request reaches to the exit node, eventually, it will be completely decrypted.

But the problem is, on the return path, answer to this question says that the same encryption way (I am also adding the image showing the concept below) is also used for the return path; So, when the packets reach to the client they will be encrypted. Without knowing the private keys of the relays, how will the client be able to decrypt received packets from the server?

 Image showing the Tor concept

There is no need to know the key of the relays to decrypt the data they send back. TOR works the in the same way as SSL/TLS does: when you connect via HTTPS (HTTP over SSL/TLS) to a web server, you don't need to know the key of the server to decrypt the data you receive from it, this because during the SSL handshake phase, your browser and the server agreed on a symmetric encryption key that will subsequently be used with a symmetric-key cipher (e.g., AES). TOR works with the same principle, in some way it is like having three SSL connections one inside the other (although it is not exactly that...).


Replaying SSL traffic in an active connection Possible Duplicate:
  Are SSL encrypted requests vulnerable to Replay Attacks?

I have an SSL connection with my bank open from A to B

A -> B

Through that connection I transfer $100 to my friend. However, it just so happens that my friend controls a proxy somewhere between A and B (at say M) and is watching the encrypted packets go by (he can't see them unencrypted, but he is capturing the encrypted contents).

A -> M -> B

Scenario A) The ssl connection is still active, and my friend replays the packet that gave him $100.

Scenario B) I send another request to the bank for something unrelated. But this time my friend, at M, modifies my packet in transit to be the same packet that gave him $100 earlier.

Not sure if these scenarios would be handled differently, so I considered them separately.

What does SSL/TLS do to prevent these type of live replay attacks? I get that SSL generates a nonce during the initial handshake, but that would only prevent replay attacks for another ssl session down the road once new nonces are generated.

SSL connections use a stream cipher (RC4) or a block cipher in CBC mode (AES, DES), i.e. (very roughly speaking) ciphers where the next encrypted block is a function of all previously encrypted blocks.

Therefore an attack like the one you propose is not effective.

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
http://httpd.apache.org/docs/2.2/ssl/ssl_intro.html


How is composed “public host key and certificates (K_S)” in SSH_MSG_KEX_DH_GEX_REPLY message? (SSH2 key exchange) I'm trying to implement SSH2 key exchange in Java, and having some difficulties. The RFC4419 states, that:

  The server responds with:

 byte    SSH_MSG_KEX_DH_GEX_REPLY
 string  server public host key and certificates (K_S)
 mpint   f
 string  signature of H

My question is - how the "server public host key and certificates (K_S)" should be composed? Where can I find this information?

I have host public and private key, and can read all information needed like for example:

/*
 Read the required variables from the public key.
 */
DSAParams pubKeyDSAParams = ((DSAPublicKey) pair.getPublic()).getParams();
BigInteger p = pubKeyDSAParams.getP();
BigInteger q = pubKeyDSAParams.getQ();
BigInteger g = pubKeyDSAParams.getG();

/*
Read the private exponent from the private key.
 */
DSAPrivateKey privKey = (DSAPrivateKey) pair.getPrivate();
BigInteger x = privKey.getX();

Found the answer myself in RFC4253:

  Signatures are encoded as follows:

  string    signature format identifier (as specified by the
            public key/certificate format)
  byte[n]   signature blob in format specific encoding.

  The "ssh-dss" key format has the following specific encoding:

  string    "ssh-dss"
  mpint     p
  mpint     q
  mpint     g
  mpint     y

  Here, the 'p', 'q', 'g', and 'y' parameters form the signature key
  blob.

Signature formats:

  The following public key and/or certificate formats are currently
         defined:

   ssh-dss           REQUIRED     sign   Raw DSS Key
   ssh-rsa           RECOMMENDED  sign   Raw RSA Key
   pgp-sign-rsa      OPTIONAL     sign   OpenPGP certificates (RSA key)
   pgp-sign-dss      OPTIONAL     sign   OpenPGP certificates (DSS key)


Which cloud providers can be used for the simulation of DDoS attacks? Cloud providers have a great infrastructure to perform DDoS simulations. You can get thousands of virtual machines with different IP addresses, fully customizable with the tools you need for testing. But as far as my research is concerned, most of them do not allow DDoS testing and explicitly forbid it in their ToS. Amazon for example states:

  "You are prohibited from utilizing any tools or services in a manner
  that perform Denial-of-Service (DoS) attacks, or simulations of such,
  to or from ANY AWS asset, yours or otherwise."

Is there an established cloud provider that allows DDoS simulation and can be recommended for DDoS testing?

I'd suggest that the point here is terminology.  Whilst an illegal attempt to DDoS a site is obviously out of ToS for most cloud providers, what about providing load testing facilities?  when it comes down to it load testing to failure is likely to be pretty similar to DDoS and is, I would expect, quite legitimate. The key difference is authorisation.  DDoS is an unauthorised attack and load testing is a legitimate activity that a company has authorised.

There are a number of cloud based load testing companies (I'll avoid listing them otherwise this could be a product recommendation) but also AWS can likely be used for load testing (e.g. bees with machine guns)


Is storing a private key in a device as it was done in AirPort Express the right solution? Here's a story about how one guy reverse engineered AirPort Express and obtained the private key that was used to prevent cloning the device ability to stream audio to approved devices only.

So basically the whole "security" was tied to the fact that noone except a limited set of manufacturers new the private key and the key was stored somewhere in the device ROM and a determined guy armed with widely available tools could extract it.

Was this use of asymmetric key cryptography right? How should it have been implemented to make such attack impossible?

I think, like all security design choices this one came down to risk versus cost to do something different.  The first question they need to ask is, what are they trying to protect?

Apple aren't interested in encrypting my music as it streams to the speakers, they're merely trying to protect a revenue stream which relies on only authorised manufacturers knowing the private key details.

The main threat to this is obviously exposure of the private key. So, where should they store the private key? They really only have a couple of (practical) choices imho.

1) On the device

2) On the Internet (yay - I didn't say cloud!)

If they store it on the Internet, effectively we're dealing with something akin to a Certificate Authority. An example process could be when you set up the devices they dial home with some form of key signing request which results in a key they can store on the device which is effectively unique to it but which can be validated by the AirPlay compatible software which has the public key for Apple's "CA". Google "web of trust" if you need more info, though it sounds like you understand this stuff.

That's quite a lot of overhead for something they are trying to sell in bulk and for about £60 each. So I guess they chose to store the key on the device and leave it static.

Next then, they evaluate ways in which they think the key could be exposed if it's on the device. Two main ones spring to mind:

1) Network software based attack

2) Physical attack

So now, what mitigation do they have in place for these?

In both scenarios the key, as I understand it, can be replaced by software updates, albeit this is reliant on end users to actually install the updates (not too big a problem - just bundle the update with some cool new feature they were developing anyway and most people would upgrade in a flash - no pun intended).

A physical attack would require specific equipment and knowledge, not necessarily complicated but let's face it, beyond the desire of most people to bother.

They also add the paperwork control by expressly forbidding people to "reverse engineer" the key.

If they really wanted to go to town, they could have made the AirPlay devices tamper-proof with something like the FIPS 140-2 standard but again, this seems massively excessive for a cheap consumer unit.

So, to answer your questions specifically:

Was this use of asymmetric key cryptography right? - I believe so, based on a risk analysis, similar perhaps to above.

How should it have been implemented to make such attack impossible? - maybe as I outlined with an online key signing or similar but really the point is, nothing is impossible when it comes to encryption. You need a key and it has to exist "somewhere", there's always a risk. What we are actually trying to do, like with all security design decisions, is mitigate the risk to the lowest acceptable business level.

HTH!


Delete saved login credentials username and password Scenario:

Alice uses my website on her own computer and sometimes also on a computer that Mallory also has access to. Alice likes using the password manager built in to the browser. She is aware that she needs to be more careful on computers that others also use.

Is there a way that I can provide a button to forget Alice's login details after she has finished (both username and password)? If she doesn't do this, Mallory has the ability to retrieve her login details.

There are thousands of Alices using my website, so I'm going to assume that trying to educate them all is a losing battle. I'm looking for a solution that works with human behaviour, not against it.

If I'm not mistaken, the browser only saves the information if it is there when either the AJAX request is sent or the page changes.

Now I'm going to get slightly technical given that this isn't StackOverflow, but I won't go into too many details as you should post it there if you have code related questions, but given what you want the process could go like this for a state handling library like React:

the user presses submit.
you delay the execution of the page
change/login/ajax request.
you save the information to some state
(or a variable).
you set the values of the boxes to generic
"user" and "****".
You send the request and log in the user.

I'm not exactly certain if this will work with every browser, but I have noticed that websites tend to do something similar quite often. I will admit that this is highly dependent on the browser, but it always will be and I honestly don't think that browsers are smart enough to know the difference, and if they are, just place the submit button outside of the form (if preventDefault doesn't do the trick first).


Does verifying an additional fraction of a file decrease the chances of collision? If I have a file of indeterminate length and I generate the SHA256 of that file, then generate the SHA256 of the first half and the last half, then verify all three, does that decrease the odds of a collision attack?

Basic example:

The cat is in the house.

SHA256: aa4a1ee8c29e759ca71a0945b11ef34fb123e7d38e611082f2ea37898ba5e8cc

The cat is i

SHA256: 2d04e4d86b53cbe134f0bd3c79eb60a57ef7c3d34fb2c69b772f2ef9230c093b

n the house.

SHA256: c19216e36d4df8ece789dc86fc0624fd16771843fff7fd00fb1b393ac9ad9244

What about a weaker hash that's faster?  What about a smaller portion of the file?

You might be interested to read about ssdeep, a "context-triggered piecewise hash" (CTPH) used as a content-agnostic form of fuzzy hashing.  Ssdeep builds hashes of pieces of a file so that similarity can be determined; say one character changes between two otherwise identical files.  The checksum of the changed file parts will differ, but the checksums of all other parts will not, so the files are deemed to be highly similar.

You're essentially trying to do this but without intending to use it to measure file similarity.

I am under the impression that as long as you keep entire hashes (do not truncate them) and the segments you hash are large enough to make collisions rare (maybe 512 bytes?) then you will have a sufficient level of data integrity.  It is theoretically possible that you'll have more integrity since you have a longer hash length, but there are so many areas that you have to be especially careful about in your implementation that I would not at all recommend this.

That said, you specified three sha256 hashes, including one for the whole file.  As long as you're matching all three, this should be, at its weakest, as good as sha256 alone.  It's likely stronger still, but you'll (probably) be just as susceptible as a single sha256 when it comes to theoretical SHA-2 vulnerabilities, so you might as well go for another algorithm such as SHA-3 or even (since you still have the full file's sha256) something faster like MD5.  You can also consider storing the byte size.

256 bit SHA-2 should be sufficient for anything unless you're worried about the distant future. If that's the case, you can't take anything for granted, but I'd go with SHA2-512 and SHA3-512 and the exact file size.

If you just want more speed and aren't concerned with being attacked (i.e. you're just worried about data integrity from faulty hardware and/or crappy networks), you can start with just the file size, then calculate MD5 and SHA1 concurrently (two separate processes, one read of the file).  I still wouldn't mess with cutting up a file unless you wanted to use ssdeep (which appears to use MD5 for its pieces by default).

Perhaps an attractive balance of speed and integrity could be to check the file size, then the MD5 of the first 5MB (or the whole file if under 5MB), then the real integrity check, e.g. sha256 or sha3-512.  It should* be harder to create a collision and faster to detect failures (stop on the first failure) while being only negligibly slower than just the last check (it took me 0.003s to calculate the MD5 hash of a random 5MB test file).  (* I'm expert in neither cryptoanalysis nor cryptographic checksums: this is not authoritative.)

I'm tempted to say that if an attack isn't suspected, you'd be fine with both file size and MD5 (you'd probably be fine with just MD5, though file size would allow you to fail faster and provide slightly better data integrity).


419 Nigerian scam problem I fell in a scamming trap. It took me a while to figure it out. Blinded like an idiot. But it is what it is. I can only do as much as I can now. Tell me if there is anything else I should do.

After realizing, I scanned everything for viruses but there where none. I used Macscan and ClamXav.
I  changed all of my passwords. Unfortunately I gave them a copy of my passport. Not sure what they can do with that. I did go to the police, but all they said is that they will contact me if any criminal activity comes up under my name. Didn't use any kind of card, but am wondering if they somehow could have gotten to that information. I did answer their calls, and I don't know if they could gain any other information from it.

I know I am a naive fool. Please, if you can help me protect myself at this stage It would mean a lot.

Thank you.

First of all go to the police.
Tell them your story, tell them you sent them a copy of your passport. Alert your bank and credit card suppliers as well. The biggest problem with sending a copy of your passport is that they can easily do identity theft.

I wouldn't use an AV for your computer, I would just re-install your computer from scratch. As we always say:

  Your system is compromised now. Nuke it from orbit and restore from a trusted state (backup).


Does removing features from a library increase or reduce security risks? Software libraries targetting resource constrained environments like embedded systems use conditional compilation to allow consumers to shave space and thus increase performance by removing unused features from the final binaries distributed in production.

Assume that library developers produced the compiler flags and were a consideration at design and test phases of the library.

As most design decisions, there are tradeoffs, in this case the code complexity and product quality unarguably suffer due to the increased branches to design and test against.

However with regards to security, the net impact is not clear, there are both positive and negative effects from removing features. Initially, removing code reduces the surface of attack. But on the other hand, building a custom binary means that a bug, and thus exploit, might be present in that specific combination.

The implications differ from those of traditional runtime path complexity, not just because of the consideration of 2 different types of branching, but because compiler condition syntax is far unsafer than its runtime counterpart (at least in C).

An interesting phenomenon is that building a custom binary might expose the users to targetted attacks, but using a standard build might expose the users to mass exploits.

The question is, considering there are both positive and negative influences on security, if we were to quantify them, would the net impact be positive or negative? In other, less academic words, if one is concerned with security, should they build a custom binary without the features they need?

The specific example that sparked this question is Busybox heavy use of conditionally compiled feature flags. https://git.busybox.net/busybox/tree/networking/httpd.c

In this case I would consider the custom binary (if any) to be safer, due to the smaller surface of attack.

The main problem I would worry about "removing code" would be unintended side-effects, particularly when the code is being removed by a third party, not too familiar with the project.

In this case, these are conditional flags officially supported by upstream. And despite the large number of flags, they look sensible, encapsulating one feature each.

I don't think your statement that "compiler condition syntax is far unsafer than its runtime counterpart" is relevant here.

  building a custom binary might expose the users to targetted attacks, but using a standard build might expose the users to mass exploits

Using a standard build you would still be exposed to targetted attacks, in addition to mass exploits. The disadvantage would be that your custom build could somehow be vulnerable although the normal build was not, perhaps because the specific combination used was unsafe (e.g. suppose that it let you remove an check that was necessary), this would still be a bug in the code, since these are options offered by upstream.

Or perhaps because there was a vulnerability, but some of the other cruft made it non-exploitable (or hard to exploit), and removing a piece of code you made yourself vulnerable to it (for example, a buffer overflow could be overwriting an unused buffer in the standard binary, but overwriting the stack in your build).

However, it could as well be the opposite case that your build ends up being safe with the standard one unsafe. Those would mostly even out, so I would consider the smaller surface to "win" in general.

A different issue, which I think is more important, is maintainability. So you are now designing a new (IoT?)  system, and are deciding whether to use a custom build of busybox or using a prebuilt binary (I am leaving aside the potential issues of trusting the provided binary). Should you use a custom build, would that make it harder to update later, compared with copying a standard release? The main risk will come from future vulnerabilities not being patched in your release. If using a custom build will lead to the program not being updated in three years, but every quarter if using upstream binaries, the later would be much safer. (Sadly, the real world answer often is that the binaries will never be updated, in either way)


steganography - digital application? Recently I participated in a CTF game which held a number of steganography challenges. This got me really interested in steganography.

From what I understand steganography is most commonly used with images, data hidden in images. this is because images hold so many bytes adding hidden data is easy as it does not distort the disguise enough to be noticed by a human and if the image is fresh and has no other original it cannot be compared to the source image to spot that there is potentially hidden data.

So now on to the main part of the question:

What other digital applications are practical in communicating secret messages using steganography?

If you were constantly sending large pictures of cats to a receiver it might be fairly obvious you are up to something. is there anyway to hide data within web traffic or text messages which does not reduce the integrity of the steganography?

what other crafty ways are there to use steganography? could I encrypted a random normal string and hide an encrypted string within the bytes of another encrypted string, making the first string un decrypt-able but obscuring the secret point?

I am curious in the subject and its other more crafty application.

to narrow it down into one question!:

Are there forms of steganography which don't use media files such as images, sound files or video clips? but follow similarly used methods. e.g. Pictures keep their true meaning but have bytes hidden amongst their own original bytes

From what I have seen, steganography is often disregarded within an academic environment. The main reasons would be the low throughput that can be achieved (in terms of the rate (information bits/total bits sent) and the fact that it is closest to encoding than to encryption and thus it relies too much in security through obscurity.

As such, real world applications that implement steganographic approaches (and in that sense, every kind of file can be taken into account: pictures, audio, metadata and non-printable characters in PDF/office files) are most likely to fall within the realm of proofs of concept than an actual product. Just because something is cool and works, it doesn't mean it's the best way to do it.

On the other hand, I would say a lot of interesting research can be focused into detection. Being an actual non-trivial technique, it can be used for covert channel communication, enabling threats like data theft and undetected communication.


Is it a good idea to use the user's username as a salt when hashing a password like hash(username_str + password_str)? I'm helping my friend with hashing his passwords, and I've a question - Should he use one secret string as salt for hashing or is it better to have each user its own salt for hashing?

Consider these three hashes:

hash("secretKey777" + password);
hash("secretKey777" + username + password);
hash(username + password);

Which one is the hardest to crack and the safest?

I think it's best to use hash("secretKey777" + username + password); because for each user not only has "secretKey777" as a salt but also its own username. In case code that hashes the passwords leaks, there will be no attack on all the hashes at once - each has will have its own unique salt.

The primary characteristic of a salt is that it should be globally unique for each user's password hash.  It need not be secret, and a username will certainly not meet the required criteria of uniqueness. A shared secret string (used for all users) is not a salt, but a pepper, and has not been demonstrated to add any security over unsalted passwords, and so is not a viable option.

One construction that has the property of being particularly likely to be globally unique is random data of reasonable length.  The salt doesn't actually need to be random, but a random value, generated individually for each user gives us reasonable assurance that we have the uniqueness we need.

There's a bit more in this answer:  What should be used as a salt?


Security of an SQL database server used in web app At my organisation we have a website survey that one of the managers here uses for equality purposes. They designed and implemented the survey in Adobe FormsCentral which is now being retired, so I was asked to create something similar.

I'm going to be creating the survey using ASP.Net MVC, and have been thinking about adding the data to a database on an SQL server, so the data can be downloaded at leisure by the manager. The only issue I have is that my manager (not the same one that wants the survey) is worried about the security of the application.

Specifically he's worried about the fact we'll be creating a link from our web server (in a DMZ) to our SQL server that is currently only used internally. Although I want to say 'it will be fine', he does have a point. If the web server is compromised, it could then expose our database server, along with credentials to access it.

I will limit the credentials so that the survey only has write permissions to the specific table used, but I'm not sure if there are any ways to protect the credentials used to access the database server. I'll only be using read credentials on an intranet page that the manager can then use to download the results.

Is it possible to hide credentials from someone who gains access to the web server? Or is the answer 'Don't let your web server get hacked'? I'm interested in this for future reference too, as we might end up storing more sensitive data, for example customer addresses in future, and give access to them via the internet, rather than internally.

And are there any other things that I should be looking out for? I will already be guarding against SQL injection and scripting attacks.

For extra information, the web server has HTTPS and the SQL server has customer details stored in other databases, but these won't be touched by the application. Any help or advice on this would be appreciated.

You could, if you want to do extra amounts of work, have an intermediate middleware layer that brokers requests from the dmz web server. It could be as simple as a rest based api ( it might not be simple :) ). Once again the amount of work is dependent on the monetary loss associated with the data.

Also if you approach this from a programming perspective, that will be the methodology. But if you approach it from the inevitability of data loss, then you would go with a backup policy.


Seeking Review for Authentication and Message Encryption Approach I have a plan for handling authentication and message encryption, and I'd like some others with more cryptography knowledge to let me know if my approach is sound, or how it should be improved.

Client apps will be connecting to my server via a TCP/IP socket.  I'd like to avoid SSL/TLS.  On the server, I'll be storing for each user (and changed whenever the user changes their password): a random salt, the hash of the UTF-8 of their password plus the salt, a symmetric key, and possibly the encryption of that symmetric key (if the symmetric key is random, instead of being derived from the password/salt).

When the users logs in, the client will send the user name, the server will send back the salt, and the client will send the hash.  If the hash matches, then the server will send the encrypted symmetric key, and the client will decrypt it, and use the decrypted symmetric key for subsequent encrypted messages.  If I can derive the symmetric key from the password/salt, then there'll be no need to compute and store the encrypted symmetric key, or send it to the client for decryption.

For hashing the password/salt, I had been planning on just using SHA-384, but it was pointed out to me (by zaph) that I should "iterate over an HMAC with a random salt for about a 100ms duration and save the salt with the hash".  I don't want to use another library, so I'm thinking that this is what he meant:

int
    i;
byte[]
    passwordBytes,
    saltBytes,
    saltedPasswordBytes,
    hash;

passwordBytes = Encoding.UTF8.GetBytes( "MyPass" );
using ( RNGCryptoServiceProvider rngProvider = new RNGCryptoServiceProvider() )
{
    saltBytes = new byte[ 128 ];
    rngProvider.GetBytes( saltBytes );
}

//  Salt the password.
saltedPasswordBytes = new byte[ passwordBytes.Length + saltBytes.Length ];
System.Buffer.BlockCopy(
    passwordBytes, 0, saltedPasswordBytes, 0, passwordBytes.Length );
System.Buffer.BlockCopy(
    saltBytes, 0, saltedPasswordBytes, passwordBytes.Length, saltBytes.Length );

using ( HMACSHA512 hmac = new HMACSHA512( saltedPasswordBytes ) )
{
    //  Get the hash of the salted password.
    hash = hmac.ComputeHash( saltedPasswordBytes );

    //  Iterate, getting the hash of the hash.
    for ( i = 0; i < 2000; i++ )
        hash = hmac.ComputeHash( hash );
}

Another big concern is how to encrypt the symmetric key.  I was originally thinking of AES, and sending the encrypted symmetric key to the client, but I'm wondering if I should use something like the above, but varied slightly, such as putting a zero in the front of the salted password bytes before hashing it, and then taking the first 32 bytes of that for the key.  That way, I won't even need to encrypt the symmetric key.

My next problem is message encryption.  After reading through NIST publication 800-38A and blog posts, I'm so confused about cipher modes.  CTR sounds good, but it isn't supported in .NET, and I don't want to use 3rd party libraries.  Since my messages can get pretty long, and can have a lot of repeating portions, ECB sounds like a bad choice.  Using another one, like CBC, now I need to deal with the IV.  One approach I read is to use a new random IV with every message, and send it before the encrypted bytes.  That sounds okay for the first message sent, but I'd like to keep messages small, so I was thinking about altering the IV for each subsequent message, using an algorithm that both sides apply.  I read that the IV for subsequent messages needs to be unpredictable, so I guess I'd need to take the hash of a counter, and XOR that to the previous IV or something.

So, experts, am I going about this the right way?  Is that iteration correct?  Is it a good idea to use that approach (varied slightly, such as with a zero in front of the password and salt) for determining the symmetric key?  What cipher mode (and IV approach, if applicable) should I use for encrypting messages?

Thank you.

No, no, no, no, no!
The first rule of encryption club is do not roll your own algorithm.  ;-)

Seriously, just don't.  Even if it sounds good to you, or to everyone on this forum, don't do it!  It is easy to create an algorithm which you can't break.  This is rarely if ever actually secure.

My first question would be, what's wrong with using SSL/TLS? It pretty much exists to solve the problem you are facing.  If we knew why it was unsuitable for your use case, we might be able to offer a better alternative.

The most obvious problems with your design are: 1) all the goodies, including the symmetric key are being stored on your server, and 2) you are re-using the same symmetric key for each message from a given user.

This is very bad.

If the server DB is ever compromised, everyone's messages, past, present, and future are now revealed.  There is no forward secrecy.  At a bare minimum, message symmetric keys with the server should be limited to per-session.

As always, "is your security good enough" depends entirely on your threat model.  Who is going after your stuff, and what is it worth to them, and to you if it gets compromised.

This is not what I would call a production-ready approach to security.


what are the differences between TLS and SSL? What are the difference between Transport layer security(TLS) and secure sockets layer(SSL). what could be the weakness of them

SSL is the code name for three successive protocols that were designed by Netscape, back in the 1990s. The acronym stands for "Secure Sockets Layer". The three protocols are very different from each other (SSL 1.0 was never published but has been described as "embarrassing"; SSL 2.0 was published as draft; and SSL 3.0 was considerably modified to try to fix a number of shortcomings in SSL 2.0).

Then the whole concept was given to the IETF, who became responsible for maintaining the SSL 3.0 protocol. The subsequent protocols were called TLS, starting with TLS 1.0, then 1.1 and 1.2. The name change was partly meant to convey the idea that the protocol could be applied to any bidirectional transport medium, not just Internet sockets; and partly to avoid any potential issues with the reuse of the "SSL" acronym which might have been a Netscape trademark.

In any case, TLS 1.0, 1.1 and 1.2 are quite similar to SSL 3.0 in their definition and functioning; there is a much larger gap between SSL 2.0 and SSL 3.0, than between SSL 3.0 and TLS 1.2. Thus, trying to keep "SSL" and "TLS" apart from each other does not make a lot of technical sense. The difference in terminology relates to administrative concepts.

Personally, I tend to use "SSL" as a designation of the whole concept (thus encompassing all versions, from SSL 1.0 to TLS 1.2), and "TLS" only to designate the IETF incarnations of that concept. In many cases, I write "SSL/TLS" when I want to avoid any vain debate.

See also this answer.


How do I check that I have a direct SSL connection to a website? I always thought that if I had an SSL connection there would be no MITM attacks. Now it appears that isn't true (see comments in this question Is it okay from a security perspective to read foreign (untrusted) cookies in a trusted network?)

I'm still unsure how it works and whether each browser needs to install a certificate, but it sounds like a proxy on your LAN connection either redirects the domain (I probably misunderstood) or uses an alternative certificate (doesn't the cert need to match the domain? I'm still confused).

Would it be possible to check if I am connected to the true site? It would be helpful too if you can explain how the proxy can create a valid cert for a domain it doesn't have the real cert/keys for. (I know this is two questions but both can potentially be explained by one answer.)

To verify that you're talking to the remote server you want directly, two points are required:

You need to check you trust the server certificate (typically done via RFC 3280/RFC 5280).
You need to check that the certificate was issued for the host name you're trying to reach (RFC 2818 Section 3.1 and RFC 6125).

What constitutes that remote server is up to the service provider. You're confusing multiple kinds of proxy servers here.

There are normal HTTP proxy servers that can be used for HTTPS connections. This is done using the HTTP CONNECT verb and the entire SSL/TLS traffic between the browser and the target server is merely relayed by the proxy server. As far as the SSL/TLS connection is concerned, this is roughly equivalent to IP routing: the proxy won't see anything.
There are HTTP reverse proxy servers. This is what's discussed in the question you link to. However the request is then handled internally is up to the service provider.

In the same way as for database connections, it may be useful for the service provider to protect its internal HTTP traffic using SSL/TLS, if the requests are served by HTTP worker nodes. In this case, the head node of the load-balancer/reverse proxy will be the client to those internal web servers.

As far as you're concerned, the "true site" is the head node/reverse proxy. https://www.google.com/ certainly has more than just one box to handle the requests it gets. As far as you're concerned, the entire cluster behind it is the (big) machine.
MITM proxy servers. Some HTTP proxy servers will be able to look into the HTTP traffic (for example Squid + SSL Bump). To do so, they will re-generate a certificate using their own Certification Authority on the fly. Such certificates will fail validation in your browser (step 1 above), unless your machine has explicitly been configured to trust this local CA.


Is it legal to store users searches Im developing a webshop and i got a task asking for storing users searches. Is it legal?

It will be stored in a db with the fields Date, Search text, userId

You can store anonymous data regarding searches like search item, time made etc. Most websites employ a privacy policy that will outline what data they store (albeit vaguely) which will cover you to do what you outline but without one you must be very careful. To stay the right side of the law.


Why can I access the internet with all ports closed on firewall? For the heck of it I wanted to see how much I could close down my router from the rest of the internet. I was hoping turning on the firewall, removing any port forwarding and turning off UPnP would make me unable to even browse the internet. However, my PS4 still had a connection when trying it out, also any internet browsing also worked.

What am I missing here? How can ports 80/443 be open for web traffic? Also, the PS4 that requires a bunch of ports to be open still worked. Is it because the request is coming from inside my LAN that it opens these ports temporarily?

Thank you.

Access to the Internet consists of contacting hosts outside of your network, which relies on routing traffic via your local gateway, also your router typically. This traffic is sent to the router but not by accessing TCP or UDP ports since you're not trying to connect to the router itself. The router modifies the packets slightly (to make them look like they're being requested from a public IP address) and establishes outbound TCP connections (for the most part), which are bi-directional. Return traffic on an established TCP connection is expected and the router will forward it back to the original requesting host (i.e. PS4). This return traffic is not the same as an external host trying to open a port on your public IP address (probably set on your router).

So closing all your ports and disabling port forwarding means in the context of the router to close all TCP and UDP ports (and possibly ICMP...) facing the external interface (i.e. the Internet), so this rejects all new connections aimed at your public IP address. Closing all your ports on the internal interface means you won't be able to connect to service ports on the router itself (thus effective locking yourself out of the admin interface, so don't do this). Neither of these will stop traffic being routed to the Internet.

If you want to shut Internet access you need to make the router not route or forward traffic from the internal network. For example you could bring down the Internet interface (WAN) or add forwarding rules to block traffic from the internal network or disable masquerading (does not necessarily block traffic but effectively stops Internet access). This is not related to port numbers.


Should HMAC key be changed regularly? Should it be kept secret at all times? I am doing an HMAC of some cipher-text, IV and encryption algorithm. Right now I am using a hard-coded key that is known to both sender and receiver. I was wondering if the key should be changed once in a while? If it does, how would I synchronize the keys with the receiver? Is sending the HMAC key in plain-text a very bad idea?

You don't need to change the HMAC key unless you believe it has been compromised (or for some other reason, you wish for messages authenticated under the old key to no longer be considered valid).  Assuming you use a reasonable hash function, signing "too many" messages with the same key does not compromise the key.

All of the security of HMAC comes from the HMAC key being kept secret, so sending it in plaintext would almost certainly defeat the whole purpose of using HMAC rather than just a public, unkeyed hash.  If you need to be able to change keys, you may want to rely on asymmetric (public key) cryptography instead, although you haven't stated enough about your application for a more specific recommendation to be possible.


PCI DSS requirement 6.4.2 separation of duties between development/test environments 6.4.2   Is there separation of duties between personnel assigned to the development/test environments and those assigned to the production environment?

What does the separation of duties here mean? Is it in the sense of http://www.sans.edu/research/security-laboratory/article/it-separation-duties or something else? The formulation "between test and production environment" is really confusing me, it looks like they mean that one should have different sysadmins for test and production? Or do they just mean that developers shouldn't have access to production?

It is, of course, always wisest to accept the judgements of your QSA when making judgement calls, however during your own in-house compliance work I recommend checking out the Navigating PCI-DSS: Understanding the Intent of the Requirements document whenever confused by a requirement.

Looking at page 32 of that document we see the following write up regarding requirement 6.4.2

  Reducing the number of personnel with access to the production
  environment and cardholder data minimizes risk and helps ensure that
  access is limited to those individuals with a business need to know.

  The intent of this requirement is to ensure that development/test
  functions are separated from production functions. For example, a
  developer may use an administrator-level account with elevated
  privileges for use in the development environment, and have a separate
  account with user-level access to the production environment.

  In environments where one individual performs multiple roles (for example
  application development and implementing updates to production
  systems), duties should be assigned such that no one individual has
  end-to-end control of a process without an independent checkpoint. For
  example, assign responsibility for development, authorization and
  monitoring to separate individuals.

So, by the strictest reading, then yes. Developers have access to the development system, and may have user role access to production, but a separate individual will actually perform application installs/administration and system administration of the production environment. The real purpose of all this, as discussed in the last paragraph, is that there is no single individual that has end-to-end administrative control of the service. What they want are multiple people with visibility into the process so that no single person can do make changes in development and roll them into production unquestioned.

So, whenever possible, the official advice would be best summed up with a picture.

In serious practice, however, you need to figure out how best to manage that auditing and/or segregation while documenting your processes and eventually getting it properly handled by your QSA.


VPN and posts on forums I know that VPN changes my IP that is seen by websites but I wonder about topics and posts sent to them.

Does VPN change IP of the post/topic (IP from which the post/topic was sent) or it will appear as my real one?

A VPN encrypts your traffic between you and the VPN provider. The traffic appears as if it is originating at the VPN provider.

With that said, there's many other ways to identify someone other than their IP.

Cookies set in the browser
User agent
Various other fingerprinting (canvas, resize, visited links, flash, Java, webrtc, location API, etc.)

If you're attempting to post anonymously on a forum you're banned from it may evade a IP ban, but you could be identified from other logged information (most likely would be a full user agent match since those are saved on most server logs by default)


Secure USB cable for charging in untrusted environments On a long haul flight, I imagine that charging a phone (in flight mode) with the inbuilt USB port on the head rest would be a security risk.

Could I mitigate that risk by taking a regular USB cable and cutting the data (but not the power) cables? Or does the USB protocol need a data handshake to begin charging? Or is there another better solution?

Could I mitigate that risk by taking a regular usb cable and cutting the data (but not the power) cables? Or does the usb protocol needs a data handshake to begin charging?

Such a cable does exist, so a data handshake must not be required.

Such cords are discussed on some Stack Exchange sites:

Micro USB cables that only charge but no data, no mounting etc
(Samsung Galaxy S)
How can I tell charge only usb cables from
usb data cables

So yes, using such a cable or making one using a DIY approach could mitigate a risk that depends on the 2 data pins. Of course, a different kind of attack where unexpected power is sent, possibly with the intent to damage the device, would still be possible.


Can BTRFS provide authentication on an encrypted disk? One of the problems of disk encryption is providing authentication. An attacker with access to the ciphertext can modify the ciphertext at will without consequence. Given, this isn't a likely attack, but nevertheless a possible one.

An interesting thought occurred to me. My disks are encrypted with LUKS in AES-CBC ESSIV mode. I then run LVM inside of the encrypted disk, then BTRFS on the interior logical volume. If an attacker modified the ciphertext while the data was at rest, I normally would have no way of noticing that it had happened. However, since BTRFS checksums both metadata and data, a corruption would probably be noticed by the filesystem itself when trying to read that file.

Granted, BTRFS uses CRC-32 as a hash algorithm, but is my theory more or less accurate? Do I get authentication by using BTRFS in a LUKS volume?

In a way, yes. However, btrfs will silently repair the data where possible so unless there is an unrecoverable error, you won't know. Since you use LVM and btrfs, there is a good chance the data will be fragmented making it even more difficult for an attacker to change it consistently. Offline cryptanalysis of a btrfs filesystem is complicated enough on its own as the filesystem is, in my opinion, less predictable.

In respect to this, off topic - using LVM under btrfs is redundant. Btrfs features all the goodies LVM does and more. Performance-wise this is not optimal - btrfs uses extents of its own while unaware of LVM's extents. This could result in mid-extent fragmentation. It may look like a "security" feature but it is in fact not.

If you want "authenticated" data on a filesystem, the only way is signing them or at least having an off-line hash for the entire block device or any and all subsets of blocks on the device.


Security considerations for a web application without log in feature We were told to send an email with a link to the users. The users will get a token in the URL where they will be able to chose some options and post their selection. Example URL: https://example.com/DoSomething?token=wer545w5e54r

The application is being made in MVC .Net, Web API and is hosted in a server with https.

Currently, we are validating if the token exists we accept the transaction otherwise we are returning 401 error.

Could you tell me what are the security points that we consider on in order to make secure our application?

Our client does not want to deal with a sign-in form

When using a One-Time-Token like that, you usually have at least four problems:

Time frame of validity. If the token is valid for too long, it might get compromised, if too short, the method of delivery might be too slow to allow for a good user experience.
Method of delivery. You do not want to send those tokens over an insecure channel like mail without PGP or S/MIME. If you do, the token (effectively the username and password during said timeframe from 1) might get compromised and everything breaks horribly. If you use PGP or S/MIME, that puts a heavy Burden on the users, effectively restricting the user base to about 1% of what is possible, as a rough estimate, as others do use neither technology and do not know how (and you're effectively putting the "hassle hurdle" to register quite high)
Method of requesting such a One time token. If you allow for any unauthenticated user to put in a name and have you use some (probably computationally hard and resourceful) crypto and a communication channel, there's a higher attack surface for DDoS-Attacks.
Usability. If this does not yet sound like UX hell: what about people that do not have PGP on their phones (not free on most platforms) but want to use your service while on the go? What about people using a machine at some other place, like internet Cafés? You do not want to also check mail or whatever way to send the token you come up with there.

Oh and while I'm at at: your question sounds like you're never invalidating the tokens. That's horrible for many reasons, as is the length of your example token - it should have a lot more entropy and a lot more characters.


How can a git repository be sanitized efficiently and effectively? A git repository will contain information on every previous commit and all the information in that commit.

That means that if you have a git repository that contained any information such as secret keys or passwords, then you find yourself in a situation where the previous commits can be viewed and the information from those commits (even if you've since removed the hard coded sensitive information) is still available to anyone who can use git to analyze old commits.

In a perfect world we would all place our sensitive information in environment variables (.env file for example), but we don't live in a perfect world.

How can one effectively search through commits for potentially sensitive information and remove them? Simply removing commits isn't a good enough answer, because a project could have a 1000 commits to search through.

My current method for assuring a git repository is sanitized before sharing it is to simply reinitialize it with a new git repo, but this is not the most elegant solution.

In short, what is the best way to sanitize a git repository without throwing the whole history away?

Run a tool such as GitRob or truffleHog to find sensitive information in your repositories and then use BFG to remove the data from your GIT history.

  Replace all passwords listed in a file (prefix lines 'regex:' or 'glob:' if required) with ***REMOVED*** wherever they occur in your repository:

$ bfg --replace-text passwords.txt  my-repo.git

That all being said, please make sure to roll any credentials and keys that you discover in published repositories — it is best to assume those have been compromised.


Do all non-CA certs have to be End Entity certs? Still learning the differences between certs. Can someone explain? The internet has so far been surprising not lucid in describing certificates.

*EDIT to clarify EE

"End Entity" is defined in X.509 (well,RFC 5280) as:

 end entity: user of PKI certificates and/or end user system that is
             the subject of a certificate;

but the expression really makes sense in the context of path validation: an "EE" certificate is called that way because when it appears in a certificate path, it is necessarily at the end of the path. In that sense, an "EE certificate" is a certificate that either does not contain a Basic Constraints extension, or that contains such an extension with the cA flag equal to FALSE.

Now you can validate a CA certificate by putting it at the end of a path, in which case that certificate, though it belongs to a Certification Authority, can temporarily be an "end-entity certificate", depending on how you interpret that expression. The relation goes in the other direction: as per the path validation algorithm (specifically section 6.1.4, step (k)), for a certificate to be able to appear in a valid path at any place other than the end, it MUST be a "CA certificate" (meaning here "a certificate with a Basic Constraints extension with the cA flag set to TRUE).

This answers your question: if a certificate is not a "CA certificate" (as in "certificate tagged as being 'CA'", as opposed to "certificate owned by an organization that is also a Certification Authority"), then it may be used only as "end entity" within a validation path.

(Or, said otherwise: don't try to read too much in some ill-defined terminology. In practice, what matters is what implementations do, i.e. the path validation algorithm.)


Best practices to prevent logging of LDAP credentials by intermediate apps I am working on transitioning our project management tool (PMT) to use LDAP authentication instead of native auth that's currently in use.

We also have some internal web-based tools that interface with the PMT, using a REST-based interface exposed by the PMT. Some of our internal stakeholders have a concern in regards to security of the LDAP authentication entered into these internal tools, because these tools are outsourced and developed by external companies.

The way I imagine this would work is this (all communication will be over TLS/SSL):

User "X" enters their LDAP credentials into one of our internal tools.
Internal tool passes these credentials on to the PMT, which then authenticates them against the LDAP server.
Once successfully authenticated, the internal tool is able to exchange information with the PMT.

My management team has a security concern that when a user enters their LDAP credentials into an internal tool, the tool could abuse/misuse these credentials or log them into a file inadvertently, thus exposing someone's credentials.

Is there a way to prevent this scenario? Clearly, encrypting the credentials wouldn't help because the internal tool will need them to pass on the LDAP server for authentication. So how does one make sure that the internal tool does not see the credentials but still be able to authenticate the internal tool against the LDAP server?

So how does one make sure that the internal tool does NOT see the credentials but still be able to authenticate the internal tool against the LDAP server?

Many protocols exist to provide authentication without sharing user credentials with the application that's granting access. Several companies (Okta, Duo, One Login) provide tools to help implement using these where they are the application that sees user credentials and other applications get the identity information via whichever protocol is suitable for them.

It's definitely best to have users redirected via OAuth2, SAML, etc. than to provide their password directly to any application that may be used.


How to mimic a HTTP POST request? I want to mimic a HTTP POST request that I intercepted and have raw on a file, what would be the best way to send it and be certain that I sent exactly the same request?

example file: (private data redacted obviously)

POST /mobile/testAPN.ashx HTTP/1.1
Connection: close
User-Agent: [REDACTED]
Cache-Control: no-cache
Pragma: no-cache
Accept: */*
Accept-Encoding: identity
X-APP_PROFILE: 8
X-Protocol: 2
X-VAYO-LANG: he
X-IMEI: [REDACTED]
X-Handset_Platform: ANDROID
X-IMSI: [REDACTED]
X-PID: [REDACTED]
X-VAYO-ID: 1
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 3
Host: [REDACTED]

n=v

If you want to replay the exact request you have in the file as plain HTTP you can simply use netcat:

cat request.txt | nc host 80

If you want to replay it as HTTPS instead of HTTP you can use openssl s_client:

cat request.txt | openssl s_client -connect host:443 -servername host


What applications are at risk from "Backwards Unicode Names" and what are the mitigations? There is a vulnerability where some applications (such as explorer.exe) respond to Unicode characters that change the direction of the text (right-to-left vs left-to-right).  This may be used to mask an EXE file into one that looks like a text document.

More information on this topic...

What applications are vulnerable to this threat, and what are the mitigations/countermeasures?

Update

For example:

Mitigate Windows Explorer with AntiVirus product XXX
Filter email attachments using YYY
Limit Mac exposure with product iZ

My personal experience suggests that most products need updating or configuration to prevent end users from being taken advantage of.

Perhaps calling 'Backwards Unicode names' a vulnerability is incorrect of me.  However I consider any application that does not provide the controls to mitigate hostile use a vulnerability.  Perhaps this security is regulated to a class of products such as email filters or AV products.

My intent is to identity the products needed to prevent this from being exploited and maintain the reasonable and appropriate use of B.U.N.'s.

Doubt if we can classify this as a vulnerability. This is a case when support of legitimate feature fails to provide protection of usability in proper form. There are some languages where text direction is from right to left. Unicode consortium had sincere intentions to make support of such languages. By the way, topic itself is not new. About Unicode exploitation there were released two papers by Chris Weber:

Exploiting Unicode-enabled Software
Visual Spoofing Attacks and Defenses

I would say that you should point attention to any modern desktop application that supports Unicode - there is a high possibility that it is subjected to such attacks.
Going further, want to admit that incorrect or bogus implementation of Unicode can lead to any type of bug starting from visual spoofing till buffer overflows.

Unicode advises following document to be read: http://www.unicode.org/reports/tr36/tr36-9.html.


Identify suspicious flood of SMS (phone exploit?) edit
Based on comments and answers, there seems to be some misconception. Allow me to clarify:

I have of course searched for REG-RESP on Google prior to writing this question, but what is to be found is not helpful, or from what I can tell, even related (other than incidentially having the keyword in the text). There are a hundred thousand hits of some users wanting to use FaceTime or iMessage having trouble activating the service. This is not my issue.
I do not want to use FaceTime/iMessage, and I do not want to troubleshoot why FaceTime isn't properly activating or whatever. I explicitly deactivated both FaceTime and iMessage along with everything else that can be deactivated and isn't necessary to use the phone as a phone ("speak into the little hole, listen on the other side").
The phone has been working fine with no disturbances in this configuration since mid/end of April, until suddenly messages started coming in 3-4 days ago for no obvious reason. I did not use FaceTime or iMessage, or attempt to use it, nor register/activate or request anything.
No longer getting messages now. I didn't do anything to fix it.

/edit
Since about three days, I'm getting suspicious SMS sent to my phone (iPhone) in 12 hour intervals (seemingly from a UK number, but it's quite possibly, even probably, spoofed).
There is no "obvious reason" from my side why I should be getting these. The phone is a corporate phone, number is not "publicly listed", the phone is not being used for "anything not business", in particular none of this modern social media share-everything crap (facebook, twitter, and whatever you call it).
Newest firmware, bare minimum of apps installed on the phone (even removed anything Apple installs by default that you can remove, disabled what you cannot remove), every setting is, to the best of my knowledge, set to "paranoia mode". I did not contact anyone (not anyone not-within-corp) recently, nor disclose my number to some internet merchant or similar.
Thus, the only logical explanation seems someone is script-kiddying random phone numbers with some unknown-to-me kind of exploit (but if someone is probing random numbers, why am I getting these over and over again in 12 hour intervals?).
The Messages look like this:
REG-RESP?v=3;r=123456789;n=+491234567890
s=123456789ABCDEFFFFFFFFF01234567890ABC
01234567890...

(I replaced the digits with 12345... in case they're something "sensitive" -- for all I know these messages might as well be some highly illegal unilateral communication accidentially sent to the wrong guy's phone. The obscure 48-digit number might be a code for "terror strike tomorrow" to this scary Maghreb guy living down the road, you never know. So I wouldn't want to publish the actual numbers on the internet.)
The first number is seemingly random, the second number is the phone's number including country code, and the last number is an always-constant prefix of 10 hex digits followed by FFFFFFFF, followed by a seemingly random 48-character hex number.
The messages somewhat look like a query string that you would expect to be sent to a REST service (without host or path). Except my cell phone is, well, a cell phone, not a public web server.
The iPhone doesn't seem to know what to make of the messages either, it simply displays the message text as-is (well, luckily...).
There does not seem to be any suspicious outgoing communication from the phone. Turning off WLAN, the bandwidth quota shown by the provider does not seem to grow. With WLAN turned on and wiretapping on the router, one of the other odd connection to Apple is made every now and then (probably checking updates?), and nothing else.
Is this kind of request aiming at a known exploit in some phones? Seeing how the Apple phone doesn't seem to understand it, maybe Android phones?
Otherwise, any idea what this may be? Botnet control messages?

It is your phone attempting to connect to facetime or imessage. You can turn this off if you wish. I don't like to assume, but my assumption here would probably be that there's nothing malicious going on.

Try this : If you get an error when trying to activate iMessage or FaceTime

As an aside: There's a lot on Google for this. It would've taken you a lot less time to google "REG-RESP?v=3", for example, than it took to write your question.


Can I use stormpath user management service with a XACML library like BALANA? I'm trying to implement some security access control in a software I'm building. I came across Stormpath for user management and they have somewhat an approach for RBAC yet what I was considering is to rely on XACML for ABAC and more specifically BALANA from WSO2 in the sense that I may set the attributes for users and store the profiles in stormpath while I rely on XACML for the policies.

I'm a bit new in this so I was just wondering whether this is advisable or there is another approach would prove useful in my case in order to reuse things for security rather than building things from scratch.

It depends on your architecture. In principle you can use XACML with any user management tool or authentication management. The main questions are:

where do you insert your PEP?
How will it grab the user identity?
How will it pass it to the PDP?
Will the PDP need to call an underlying PIP? Will it need to call Stormpath to retrieve user attributes?

For more information on the XACML architecture and language you can check out the Axiomatics developer blog:

XACML Architecture
XACML Policy Language


Usernames - Should their length be limited? Possible Duplicate:
  Is there any added security benefit to username complexity requirements?

Are there any good security reasons for a web application to limit the length of a username?

If there is, what should be the minimum and maximum length allowed?

There is no good security reason to limit the length of a username. The only reason to limit the length of the username is so it doesn't stretch parts of the website when displayed, but even that can be solved differently.


The login page I'm testing lets me in as long as the username starts with the right name. How could the SQL query be made? Let's say my username is theusername and my password is thepassword. If use those credentials I login as expected. However if I add whatever at the END of the username, say theusername.random.stuff.at.the.end, I still get to login to my account. Doesn't work if I do that at the beginning.

Also, if I put an odd number of single quotes at the end whether I add the other random stuff or not (Example: theusername' or theusername.random'''), it won't let me in. Won't match any username in the DB. It will let me in if the number of single quotes is even though.

And lastly, if the username ends with a single quote and double dash (Example: theusername'--) it will take it as a valid username (It matches the username in the DB) but will say the password is wrong even if I submit the actual password.

I know when a submitted username matches an username in the DB because the page shows a different error for when the username is bad and when the password is bad.

My question is... Knowing they are using T-SQL, what query string are they possibly using?

Thanks in advance.

It's not possible to know the precise SQL query without seeing the code, but the following is plausible, but a stretch:

SQL

select * from users where username='{0}' and password='{1}'

Server-side Code:

Perhaps instead of validating input, this system is instead trying to sanitise. We can assume that passwords are not sanitised for dots (have you tried dots in your password?)
2a. Because of the '.' behaviour, let's assume that the code (PHP?) is grabbing the first bit of text before the first '.' character.
2b. Because of the even behaviour, let's assume that the code (PHP?) is filtering out evens only (using a loop with Replace("''", ""))

Database type

I assume the database is Postgres, where '' is the valid escape-character sequence. For MySQL it's '
Test cases:

theusername.random.stuff.at.the.end [success]

Sanitised username = theusername
Unchanged password = mypassword
Final SQL: select * from users where username='theusername' and password='mypassword'
Expected Result: Success

random.stuff.at.the.start.theusername [login fail]

Sanitised username = random
Unchanged password ='mypassword
Final SQL: select * from users where username='random' and password='mypassword'
Expected Result: Fail (Record doesn't exist)

Odd number of single quotes: theusername' [fails]

Sanitised username = theusername'
Unchanged password = mypassword
Final SQL: select * from users where username='theusername'' and password='mypassword'
Expected Result: Fail (Invalid Syntax)

Even number of single quotes: theusername'' [succeeds]

Sanitised username = theusername
Unchanged password = mypassword
Final SQL: select * from users where username='theusername' and password='mypassword'
Expected Result: Fail (Invalid Syntax)

Odd number of single quotes with double-dash: theusername'-- [says the password is wrong]

Sanitised username = theusername'--
Unchanged password = mypassword
Final SQL: select * from users where username='theusername'--' and password='mypassword'
Expected Result: Multiple rows (for some reason - maybe a bug that results in multiple username records being created with different passwords - perhaps over time? perhaps upon each password change?)
The server-side code gets multiple records and it processes them in a loop looking for a mismatch - it finds the mismatch on one of the records (even though there is a match, it isn't looking for a match) and response with the "wrong password" message.

Hopefully, this will help as a scratchpad for others to find a more plausible explanation. I don't like the server-side code assumptions, nor the multi-row assumption for test [5].


How to validate report given by a white hat hacker I give a contract to find vulnerabilities in my site to a white hat hacker. According to him he performed several attacks on my site for 15 days and find that there is no any security threats. I am not sure he actually did this or not. How can I validate his report?

Trust is a prerequisite: Even before signing the contract allowing a third party to try to break into your server, there should be a minimum background check regarding who you employ for the job (where do he comes from, what company he is working for, how much experience he has, which certification does he and his company have, etc.),
Check your logs: After the attack, even-more if he claims he failed to find any security vulnerability (so he did not had a way to alter the logs), his thorough checking should have left clearly noticeable tracks in the logs.


What all content PKCS#7 can have and what is the purpose of each? When signed data is packaged as PKCS#7,
what all content PKCS#7 could be there(Ex. certificates, signature, etc.)?
And what are the purpose of packaging all those contents?

You can embed any data within a PKCS#7/CMS structure.
The Cryptographic Message Syntax (which is the new name for PKCS#7) knows the types EnvelopedData for encrypted data and AuthenticatedData for signed/MACed data.

That way, you can create an enveloping signature, thus storing the signature and the signed data in a single file even when the format of your data does not support it.


Writing a Password Management System, need advice on database storage I am writing a collaborative password management system and have questions pertaining to the storage of encrypted passwords. Essentially, I would like several users to be able to access and change a database.

High level:

User runs the client which asks for username/password authentication (backended with AD/Samba/Radius/local).
Upon success, the user is required to enter a shared keyring password. This should be known to all users who have access.
The encrypted database is sent to the client which decrypts it and displays it to the authenticated user.

Slightly more detailed:

Upon database initialization, a random key is generated and encrytped with the human-readable keyring password. This encrypted key is stored on disk.
Each entry in the database that contains passwords is stored encrypted with the original key.
The keyring password is therefore required to decrypt the rest of the passwords.
The keyring password can also be updated without re-encrypting the entire database. All that happens is you decrypt the key with the previous password and re-encrypt the key with the new one.

Is this all for naught? Is this considered bad design? My goal is to prevent someone from simply downloading the database if given access to the server. I relayed this off of a friend of mine who half-jokingly said "Yes, because this prevents people from stealing Chrome's database." How seriously should I take that?

Any recommendations for proper design, algorithms to use, etc.?

Your solution would work for a very small team. Anyone who knows the keyring password will be able to see all of the secrets stored in the database. If you want to remove a user, you will need to change the password and redistribute it to the rest of the team.

Better approach for collaborative secrets database would be to use asymmetryc encryption. Consider this design:

Every user has its own private and public key registered in the database
Private key is stored enrypted with AES (or other symmetrical algo), with key derived from a user password
Public key is stored unencrypted
Each secret is encrypted with a key generated from a strong CPRNG
The key itself is encrypted with users public key
Sharing a secret is done by encrypting generated key with a public key of the user you want to share the secret with

This is roughly how other password managers (for example LastPass) share secrets.


How to login and encrypt data with the same password/key I've made a "vault" web app in PHP for storing passwords, credit card numbers, etc. It's mostly just for myself, but I'm practicing building it with multiple users in mind. I use two way encryption to secure the data, and want the user to login using their key (vs both a password to login AND a key for their data.)

I initially stored the username in plaintext, and the key/password one way encrypted with a salt. My first concern is that if someone had access to the SQL data, they'd probably have access to my code (my salt and encryption method) making shorter work of revealing the password, then being able to access the two way encrypted data with it.

I also didn't like the username sitting there in plaintext...that's half the login info right there.

Basically, I'm worried about the login giving away extra info about the encrypted data itself.

What is the best practice for logging in, and two way encrypting data with the same password/key?

...and does anyone know where can I learn more about this specific concept?

First of all, don't worry about the username.  The username is supposed to be public information — if it wasn't, it wouldn't be a username, it would be a password.  Just assume that an attacker will be able to find out the username(s) in any case, and design your system to be secure with that assumption.

Second, don't worry about the encryption (or hashing etc.) method being public, either.  That's Kerckhoff's principle — the encryption method should be treated as public, the only thing that needs to be secret should be the key (or password, in this case).

There are many good reasons for this, not the least being that it allows you to publish how the system works (and thus convince your users that it's secure, or to ask for help from security experts, or to just use an existing standard system designed and analyzed by such experts) without compromising its security.

Third, don't worry about the salt either.  The salt should also be treated as (potentially) public knowledge.  Its purpose is not to provide any additional secrecy, but to protect against attacks using precompiled hash tables by ensuring that every user's password is hashed in a different way, even if the actual passwords happen to be the same.

OK, so what should you do, then?

Well, first of all, you should use a secure key derivation function that implements key stretching (and salting, of course) to derive the user's encryption key from their password.  PBKDF2 should do nicely for that, although e.g. scrypt might be even better if you have it available.

Second, you obviously should not use the encryption key as the password hash.  In fact, you shouldn't store anything in your database that could be used to obtain the encryption key without knowing the password.  (For instance, the encryption key should not be a hash of the password hash.)

One thing you could do is derive both the encryption key and the password hash separately from the password using PBKDF2, but that would be kind of inefficient, since PBKDF2 is deliberately slow.  Instead, you could derive the encryption key from the password with PBKDF2, and then use a normal cryptographic hash (e.g. SHA-256) of the key as the password hash for logging in.  (Or, if you want to be extra careful, derive both the encryption key and the password hash from an intermediate key derived from the password using PBKDF2.)

Finally, to make changing the password easy, don't directly encrypt files with the user's encryption key.  Instead, for each file, create a random file key, encrypt the file with the file key and encrypt the file key with the user's encryption key.  That way, when the user wants to change their password, you only need to re-encrypt the file keys.


network improvements over ipsec I have a specific environment in which TCP is not optimal due to its general assumptions, and thus needs to be improved. This small improvement has been done successfully. It operates at various layers, from 2 to 4, and needs read/write access to some information displayed in the TCP packets, such as the congestion window size. I was now wondering whether I could extend my proprietary protocol stack to operate with ipsec as well. The problem is that ipsec encrypts everything over ip, and I need rw access to some TCP values (not all of them). During the configuration time, I have root access to every component of the network (hosts, routers, ipsec implementations, ...), but during run time, only end hosts should be able to decrypt the whole payload. I am not a security expert, and I was wondering if you could help me to figure out what options were available for me to achieve that goal, without compromising too much the security (at least the payload).

Thanks.

Are you sure you need link-layer encryption?  For most purposes, application-layer encryption is sufficient.

If you really need link-layer encryption, your best bet is probably going to be to tunnel your traffic over some secure tunnel (OpenVPN, SSH, IPSec, etc.).  While it is possible to design an IPSec-like protection into your protocol, that is a non-trivial task that requires competent cryptographers and will require looking at the detailed specifics of your protocol.  It's not something we can do on this site.

If you don't really need link-layer encryption, I think it's going to be a lot easier to deploy application-layer encryption.  Basically, you encrypt the traffic that is sent over your protocol.  If your protocol guarantees reliable in-order delivery, use TLS.  If does not, I suggest using DTLS.  These protocols have been carefully vetted, many implementations are available, and  it should be pretty straightforward to layer them on top of your protocol without fear that you will introduce some crazy subtle security bug in the crypto.


What account should be used to install SQL Server 2008 patches? The company I work for is currently going undertaking a project to remediate (among other things) a pen-test finding that a privileged domain-level account (which was compromised by the pen-testers during the audit) was being used for multiple maintenance and development tasks in production. Currently, we're trying to discourage the use of this account and break its functionality out into separate service accounts. We're getting especially firm push-back from the DBA group on the topic of trying to discourage its use in installing SQL Server patches.

So far, I haven't been able to find any guidance specific to accounts when it comes to "best practices" for installing patches so I was wondering if anyone had any first-hand knowledge or a good starting point on where to look. Thanks

As you mention a previous pentester compromised the domain-admin account. Once this happens pretty much the entire network is owned by the attacker.

This is part of the reason you should be careful using a domain-admin account to do patch management. If you issue remote commands via PSExec, RunAs, RDP etc then a token is left on that remote system. If that remote system becomes compromised (and the attacker is now a local admin) the attacker will want to elevate his influence on the entire network. If a domain-admin account was used for remote patching then privilege escalation can be accomplished via token-stealing. Metasploit even has a nice and easy module for this. And now the attacker is a domain-admin.

In the SANS reference they recommend

  you should enable the checkbox "Account is sensitive and cannot be delegated" within the accounts' properties

They mention that this should have no adverse effects on a domain-admin account.

Finally If you have many people with domain-admin accounts that may indicate some other larger issues at hand. Breaking the domain-admin account into separate service accounts (that are not domain-admin) is probably a good idea as well.


Finding/Predicting BotNet Generated Domains Without DGA Knowledge I will pose an academic perspective in my question, but I welcome any and every observation. So a botnet would generate 1000s of domain/day and an actual attacker will register a few, which will be used with a certain probability. Point is, given a dataset of say a million domains and without the knowledge of DGA (Domain Generation Algorithm), is there any technique/research available that predicts the likelihood of a domain being a bot generated one? I have my own few ideas to make one:

Exclude Dictionary Word Domains
Include Seeming Random/Garbage/Arbitrarily Large Domain Names
Cross Check DNS information for possible registration information etc.

Sadly, I couldn't find any standard research/text on this area. Any information would be helful.

All of your three ideas are not applicable:

Exclude Dictionary Word Domains

There are DGAs that use dictionary word domains, for example matsnu

Include Seeming Random/Garbage/Arbitrarily Large Domain Names

There are absolutely legitimate domain names that have been generated by an DGA, especially in this time of "serverless" hosting with ephemeral domain names.

Cross Check DNS information for possible registration information etc.

There is not way to tell legitimate and illegitimate customers of domain registrars that offer anonymity.

There is however a GitHub repository that collects outputs from various DGAs to try and use machine learning for recognition of plausible and probable malicious DGA generated domains.


If you revoke a certificate authority's certificate, do all of the certificates it issued become invalid as well? If you revoke a certificate authority's certificate, do all of the certificates it issued become invalid as well? What about for certificates issued by an authority beneath it?

For example, if root CA A issues intermediate CA B, which issues certificate C, and:

CA A revokes CA B, does certificate C become invalid?
CA A gets revoked (somehow), does its revocation cascade all the way down the chain such that certificate C is now invalid as well?

CA A revokes CA B, does certificate C become invalid?

Yes, revocation cascades down to the tree. If CA certificate is revoked, all certificates below (regardless of how many levels are below CA) are implicitly considered untrusted. Keep in mind that they become *untrusted*, not revoked.

  CA A gets revoked (somehow), does its revocation cascade all the way down the chain such that certificate C is now invalid as well?

Root CA revocation is an undefined operation within RFC5280. In this case, the CA puts its certificate (serial number) in its own CRL and signs with its own key. And now we have a chicken-egg problem:

The CA cert is revoked (listed in CRL), but the CRL is signed with a revoked key, so we can't trust this CRL and get a definitive answer about whether the root certificate is revoked. This problem is often solved by not checking root CA revocation using RFC5280  techniques. For example, in Microsoft's certificate chaining engine default configuration, root CA certificates are not checked for revocation at all.

Such cases (root CA revocation) are handled differently, using OOB processes, by maintaining a list of explicitly trusted anchors (root certificates) and removing a bad CA cert from the list.


What is the privacy benefit of VPNs? I'm learning about networking. And I feel a donkey.
Background
We connect to the internet by first connecting to a Wifi Access Point, or a switch.
Then when we open up a browser, or use any transfer protocol to ask for a file, and information is sent across a huge network.
If I get this correctly, when using a VPN the information is first send to a VPN server, and it makes the request to, let's say, the Web server.
Question
But my question is: How private is our data before reaching the VPN? Isn't it going to the ISP-servers first? What's the real privacy benefit then?
I've got a related question but if it's too much for one post, we can leave it out. Isn't it possible to de-encrypt HTTPS data if we have access to the target server? As I am supposing there should be a de-encryption formula in the server.

For sake of simplicity, lets assume you do all of your web browsing using HTTPS.
Now, first consider the case where you aren't using a VPN.  So, your traffic is routed through the ISP, then on to its final destination.  Then, suppose you browse to https://www.somewebsite.com/.  Your ISP can not see the information that you exchange back and forth between https://www.somewebsite.com/, because it's encrypted using HTTPS.  But, your ISP can see that you are visiting https://www.somewebsite.com/, because it can see the packets being sent back and forth over its network between your connection and https://www.somewebsite.com/'s server.
Now consider the case where you are using a VPN.  Because you're using VPN, all of your traffic is routed first through your ISP, then through the VPN, then to the final destination.  If you browse to https://www.somewebsite.com/, your ISP has no way of knowing this, because all they see is packets going back and forth between you and the VPN.  And, neither the ISP nor the VPN can see the information that you exchange back and forth between https://www.somewebsite.com/, because it's encrypted using HTTPS.
With regard to your final question about whether or not the target server can decrypt HTTPS data, the answer is yes.  With HTTPS, the sender encrypts the data, and the receiver decrypts it.  If this weren't the case, then the two sides would not be able to communicate.


What happens to PKI once quantum computers can break encryption? They say that public key infrastructure or PKI uses very complex encryption. What if that encryption breaks one day when quantum computers complete? What if they decrypt all private messages and data? What will be the replacement then?

Quantum computing is being developed to attack specific algorithms. Right now there are efforts under way to find algorithms that are resistant to quantum computing attacks. Such algorithms are called post-quantum.

The Public Key Infrastructure is built on the concept of certificates, not algorithms. Certificates are documents that are capable of storing many types of signatures using many different algorithms. If one algorithm falls, such as happened when MD5 was found to have weaknesses allowing the forging of certificates, we can stop using it and switch to another.

Researchers give us warnings as they close in on weaknesses. An example of this happened a couple of years ago when SHA-1  fell to an attack. Even though there was no immediately apparent vulnerability to certificates, people stopped trusting SHA-1 signatures on certificates, and switched to alternatives.

As quantum computing approaches the capability of cracking a specific algorithm such as RSA, the world will switch certificates to trusting only post-quantum algorithms. PKIs will continue.

Throughout history, cryptography has always been a game of cat and mouse. The ability to modify keys, algorithms, and protocols has always been critical to maintaining security. Quantum computing may be a threat, but not necessarily a game ender.


Using Single Domain Name to Identify Multiple Servers Improves Security? (Google's use of 1e100.net) Since 2009, Google has been using a single domain name to identify its servers across multiple products:

  Following standard industry practice, we make sure each IP address has a corresponding hostname. In October 2009, we started using a single domain name to identify our servers across all Google products, rather than use different product domains such as youtube.com, blogger.com, and google.com. We did this for two reasons: first, to keep things simpler, and second, to proactively improve security by protecting against potential threats such as cross-site scripting attacks.

Question: How does it protect against application level threats such as XSS? Are there any other advantages of using this technique from security standpoint?

Each production IP address has a unique hostname, which is predictable, consistent, deterministic, and entirely useless to anyone but a few engineers who I suspect can read these addresses like a map. These names matter a lot to those people; but for the rest of us we just care that it doesn't create new problems.

That's where the XSS comes in, because domain names matter a lot in security. On the web, a domain name is a security boundary. Cookies, browser objects, and other resources are shared freely within a domain but can't cross that boundary without certain provisions. So if each address had a hostname ending in "google.com" or "youtube.com" or any other domain that has associated web resources, then theoretically an attacker could request a resource that normally would be outside of the trusted domain, but which is also accessible through the IP's assigned hostname.

Rather than finding and fixing all such potential issues, a safer solution is to put the hostnames on their own unique domain which is never used for any other purpose and therefore can't harbor unwanted surprises.

It's also interesting to note that not all of Google's IPs use 1e100.net. Addresses under user control like those assigned to Google Compute instances resolve back to a name ending in googleusercontent.com.

  Disclaimer: I work for Google.
  Reclaimer: This is not an official Google response. I don't speak for Google. These thoughts and opinions are my own, and don't reflect those of my employer, my congressman, or the 80's rock band, Toto.


Given a hash value, is it possible to determine the length of the initial string that was digested? (SHA256) Also, given two hash values, is it possible to determine if either one of them was a result of digesting a larger string?
As far as I understand SHA256, nothing but guessing the string itself helps. Though, maybe I'm wrong.

Given a hash value, is it possible to determine the length of the
  initial string that was digested? (SHA256)

No. The result is always a fixed length output in the case of SHA256, regardless of input length. Therefore there is no way to know the original length from looking at the output. The hash function is designed so no knowledge of the original input can be determined.

  Also, given two hash values, is it possible to determine if either one
  of them was a result of digesting a larger string?

No, for the same reasons as above.

  As far as I understand SHA256, nothing but guessing the string itself helps.

Remember that different input strings can, and do, result in the same hash digest (the output).


Local AP - Outside Router MitM Attack? Let's say that we have our computer inside the local network. Our local network is connected to the Internet by AP+Router that connects to the router in other network which is connected to the ISP.
Now, I'd like to know if there is any chance that we can listen to the traffic between AP+Router and Router(in other network) from our local network?

No, you won't be able to do a MITM attack on the edge router and your access point/router. In order to perform a man in the middle attack you must be on a network segment that allows your device to actually get in between these two routers. As programings already pointed out your gateway is the internal router/access point, which means that without it you cannot get to the edge router or route traffic. In a MITM you are attempting to reroute traffic through you by some means (in this case I imagine your referring to ARP Poisoning?), which is impossible if you cannot get to one of your targets without going through the other.

In order to perform a MITM on these routers you would need to move onto a network segment that is between the edge router and the internal one. You need this due to the fact that ARP Poisoning deals with a flaw in ARP which lives on the second layer of TCP/IP. In your case you don't have access to the second layer that the edge router is working with because you are behind the internal router.


Is there a public database of mutex names that are associated with malware? I remember seeing something like this a while back, and it'd be incredibly useful for a project I'm working on. Essentially there was a list of mutex names, with a list of malware identifiers (e.g. W32/ZeusTroj) that are associated with each. Unfortunately I can't find it anywhere, and can't remember the name of the project.

Right now I'd settle for just the mutex names alone, but if anyone knows of any projects that include this data it'd be extremely useful!

ThreatExpert reports include mutex names, when applicable (see e.g. at the end of this report). I am not sure they provide the data in a convenient format, though.


Mixed Content error in IE11 - HTTPS resource on HTTP page I have an HTTP webpage with a piece of JavaScript that adds an iframe to the page.  The iframe is pointing to an HTTPS page.  In the IE11 developer console, this error appears:

SEC7111: HTTPS security is compromised by https://www.example.com.

This is not the typical mixed content browser warning when you have an HTTPS page loading an HTTP resource.  This is the opposite (HTTPS resource on an HTTP page).  Neither Chrome or Firefox give any warning on this page.  Just IE11 gives the error.  My IE11 setting is to Prompt for mixed content, however it doesn't actually prompt and is actually loading the HTTPS iframe.  The only indication of mixed content in IE11 is the error in the developer console.

Question 1: Will having an HTTPS resource on an HTTP page cause problems?  Are there other browsers that may either refuse to load the iframe or display a message/dialog prompting whether to load mixed content?  Ideally I'd like the iframe to load and for there not to be any browser warnings.  My instincts are that loading HTTPS content on an HTTP page should be alright, which I'm sure is why Firefox and Chrome are not displaying any messages.

Interestingly, I have run across some HTTP webpages that have an HTTPS script tag on them.  For example a script tag to https://apis.google.com/js/plusone.js on an HTTP page.  IE11 does not give any errors in the developer console on this page.  Because both the script tag and iframe tag are considered mixed "active" content tags, I would expect that IE11 would also raise an error for this HTTPS script tag, but it doesn't.  Question 2, what is the reason IE11 doesn't report a mixed content error in this scenario?

In the case of an HTTPS iFrame from a different domain, two distinct information sources are accessed. The purpose of Microsoft's error message in the developer console may just be to remind unexperienced developers that the information source in the HTTPS iFrame might need better protection.

In the case of an HTTPS script no additional information source is accessed other than the main HTTP page, because scripts from third party domains are commonly used mostly for loading libraries. In such case there is no secure information source that needs better protection.

On a side note, I believe that loading HTTPS iFrames, scripts and resources from HTTP pages is still adviseable because it prevents attacks at backbone and Internet provider level.


Is this a good hash function? unsigned int hash(bytearray[] msg) {
  unsigned int hash = 0xDECAFEBAD;
  for(i = 0; i < msg.length(); i++) {
    hash = ((hash << 4) XOR (hash >> 28)) XOR msg[i];
  }
  return (hash BITWISE-AND 0x7FFFFFFF);
}

No, it isn't.

If you're trying to prevent tampering, a 31-bit hash is much too short, even ignoring any shortcomings of a specific function.  If you're trying to catch data corruption, a standard hash such as CRC-32 is almost as fast and is designed for the purpose.