Android SSL trust killer mitigation? I have implemented SSL pinning in Android application but I am able to bypass using SSL trust killer. I am looking for some solution to be able to detect or prevent such attacks. One solution is to check for root and then uninstall the application because SSL trust killer requires root privileges.

Is there any other solution besides this?

Android SSL-TrustKiller does not simply work by putting a new trusted root CA into the trust store since an application could protect against this using pinning, like you do. Instead SSL-TrustKiller patches the SSL-API used by the program so that the usual way of pinning does not work any longer but that the application will not notice this.

While there might be a way to work around SSL-TrustKiller by using uncommon ways to pin a certificate which are not covered by the API patches it is impossible to find a general solution against TLS interception as long as the user fully owns the system (i.e. is root). Such a user could for example modify your application and disable the code for pinning or add hooks into the application to get to the plain text before encryption.


Effect of internet speed on Web App Security I'm looking into Web App security and this question occurred to me:
What could be some possible effects of internet speed on Web app security?

I'm thinking of low latency, low bandwidth connections preventing or slowing the effective upload of payloads to compromise a site and things like that. I know increasing the security of the site can affect the speed a little but what of the inverse, whether positive or negative?

Third world countries typically use less malware protection but also have the advanced world's yesterdays internet speeds. I'm thinking this will limit the use of these hosts for attack, say in a botnet or DDOS.

Most malicious payloads that you could upload to compromise a website aren't much larger than a typical webpage. So no, intentionally giving the webserver a very slow connection won't be very effective in preventing it from getting compromised.

I wouldn't say it's completely useless though:

If the attacker tries to brute-force account passwords on the site, the server's slow connection could slow them down. BUT there are way more effective ways to accomplish rate-limiting, that don't make your site highly susceptible to a denial-of-service attack.
If the attacker tries to exfiltrate user data from an already-compromised server, a slow connection would make it take longer and increase the chance that you will notice it.

However, the slight security benefits you get are more than outweighted by the massive increase in susceptibility to denial-of-service attacks (or even periods of higher-than-normal traffic volume), and the negative impact on user experience. A per-user bandwidth limit might make sense, but intentionally giving a webserver an extremely slow connection is NOT a sensible security mechanism.


HMAC API exposed through public site? (I also asked this question over on StackOverflow.)

What steps can I take to prevent unauthorised access to a method on an unauthenticated controller?

Background

The diagram below illustrates a microsite we're implementing, and an HMAC API we're providing (for several purposes) which returns commercially sensitive data to authenticated consumers.  The arrows represent intended (green) and unintended (red) communication.

The microsite allows us to collect data on behalf of a client.  It will be reached via an email campaign to their users.  We don't have a close relationship with this client, so I don't want to burden them in solving this.

The HMAC API is intended for address autocompletion.  There is no login for the microsite.  The page has an address input.  To enable autocomplete the page makes an AJAX call to the controller's autocomplete suggestion method after each keystroke.  The autocomplete suggestion method makes a request to the HMAC API.

The problem

I can't see anything currently preventing consumption of the controller's autocomplete suggestion method.

Considerations

I've read that AnitForgeryTokens aren't useful on GET methods or unsecured pages, and I can't use a one-time token because this method will be called many times.

Question

So how do I secure my controller method?

prevent unauthorised access to a method on an unauthenticated controller

If you don't have any authentication and authorization ("unauthenticated controller") then there can be no such thing as an unauthorized access: i.e. every access is allowed. And, what does not exist cannot be prevented.

If you could defined what unauthorized access means in your use case you might be able to add some authorization which prevents it.


question on hashing an aes-encrypted file I am storing multiple sensitive data on a server that I do not own. The data is encrypted using aes-256 using cbc mode. The keys are only with me, and are stored securely. I am worried about the data getting corrupted on the server via transfer (this I fix by doing an md5 hash after the ssh transfer is done). The other thing I am worried about is an attacker on the server purposely altering the data, so that the md5 hash is the same.

Would decrypting an altered file with via aes simply cause the decrypted data to be corrupted?
and lastly is md5 weak for this scenario, is hmac necessary?

If you take a CBC-encrypted file and alter one bit (i.e. change a zero bit into a one, or vice versa), then, upon decryption, this will:

jumble more or less randomly the corresponding block in the plaintext data;
flip exactly one bit in the next block (i.e. 128 bits further);
change nothing else whatsoever. In particular, decryption won't "fail".

See the schema on the Wikipedia page for CBC to understand why this works that way.

What you are seeing is that when you use encryption (for confidentiality), you usually also want to have checked integrity, with a MAC algorithm such as HMAC. It so happens that properly combining encryption and a MAC is tricky. Your best bet would be to use an encryption format which already does things properly. If you must, for some reason, do your own encryption, then try to use an encryption mode which inherently includes a MAC, e.g. GCM or EAX. If for technical reasons (e.g. lack of available implementation) you must still use CBC, then add some HMAC with the following rules:

Hash your master key K (the one you "store securely") with SHA-256. Split the 256-bit result into two 128-bit halves, K1 and K2.
Use AES-128 in CBC mode, with K1 as key, to encrypt the data. Be sure to use a random IV, generated anew for each file, with a cryptographically secure PRNG.
Compute HMAC/SHA-256, with K2 as key, over the concatenation of the IV and the encrypted file.
Store the file in some format which will include the IV, the HMAC output, and the encryption result. Simple concatenation would work, since the IV and HMAC output have known fixed lengths (16 bytes for the IV, 32 bytes for HMAC/SHA-256).
When decrypting, verify the HMAC value first, and proceed with data decryption only if the HMAC value appears to be correct.

You may note that I advocate for AES-128, not AES-256. This is because a 256-bit encryption key is needless overkill and incurs a 40% speed penalty. If you still want a 256-bit encryption key, e.g. because you need to woo some clueless manager with how big your key is, then use SHA-512 to hash your master key K into a 512-bit output, which can be split into two 256-bit halves.

I also recommend HMAC/SHA-256, which should be "fast enough". A basic PC can do AES-128 and HMAC/SHA-256 combined at more than 60 megabytes per second. If you need more speed and you have a 64-bit platform, then HMAC/SHA-512 can give you an edge, but at the expense of making it harder for 32-bit systems. In any case, 100 Mbit/s network will top at about 11 megabytes per second, so encryption speed will probably not be an issue anyway.


IP address opening email Company sends me an email to my gmail.com account.

I open the email in my gmail account. It turns from bold to grey, showing it has been read by me. I do not reply to it.

Can the company gauge my IP address when I clicked on their email and opened it in my gmail account?

They may be able to tell that you have read it, but they shouldn't be able to get your IP address. Since 2013 Gmail has proxied images through their own servers, so "tracking pixels" will only get the IP of the Gmail server. This only applies to the web client though (and I believe Gmail's official smartphone apps do this as well, but I haven't tested). If you're using a 3rd party IMAP client then it may reveal your IP address when loading images.

Note that if you click on any links in the email, they can get your IP address no matter what client you use, unless you check the link destination first and verify it's to a domain that you trust and not a tracking domain.


prevent/prohibit duplication of MFA software-token / ensure user identity As I was unable to find any thread about this particular question, I'm trying to ask the community for help.

We're currently using RSA RADIUS based 2FA to authenticate external VPN users from companies to let them manage their systems inside our corporate network. The support contract for this solution will not be extended from management, so we're forced to look out for alternatives.

One of our favorites that stood out so far is LinOTP, as it offers a great variety of different token types, has a per-user subscription based license model and can manage multiple UserIdResolvers aka. realms.

One of the things we're confronted with is that external users seem to be handing over their personalized RSA tokens to their colleagues to let them use them while they're e.g. on holiday even though we've let them sign a user agreement that prohibits exactly that.

As cheap and easy generating TOTP/HOTP based 2FA tokens seem to be, for me the biggest downside is the fact that the external user could easily "share" the QR code/seed that he's received from us by email with his colleagues. This in fact is even more "dangerous" than what we use right now, as the RSA token cannot be duplicated.

One other software token type I've found that is also supported by LinOTP is "mOTP". In turn to TOTP the user has to specify a random seed + PIN that he'll provide us instead of us providing something to him.
At first glance this looked exactly like what we were looking for. Unfortunately I soon realized that user B could easily impersonate himself as user A by just specifying the same seed + PIN. So the uniqueness is also not given but at least it's slightly better in my opinion than TOTP/HOTP.

During my search on the mOTP Sourceforge page I found an iOS client application that might do what we want to have: "Mobile-OTP for the iPhone with optional UDID security extension".
Here I assume the random seed will be hashed against an unique device identifier that would make it at the very least "harder" to impersonate as someone else and verify that this user is verified to be himself.

So I think my main questions are:

are there any known mechanisms to prevent duplication of software tokens / guarantee the "uniqueness" of the software-token? (e.g. QR code only valid for X seconds)
are there any known mechanisms to ensure the identity of the user trying to login? (besides regular username, password and the token)

Things I might mention at this point:

a bastion host was considered and still is, but should not be the scope for this discussion
Cisco DUO was taken into consideration too but turns out to be quite costy, at least compared to LinOTP (3$/u/m vs. 1$/u/m)

You cannot solve this with technology. It's a policy problem, not a tech one.
Even if you use a hardware token, nothing stops them to call the colleague and get a token. If you have a biometric-backed generator, or whatever, they will find a way to share. Having Human Resources step in and having a strong stance on this matter will solve it.
Remind everyone that sharing OTP tokens are a fire-able offense, and if (when) someone breaks this rule, fire him and summon a company-wide meeting after that to tell everyone that Mr OTP-Sharer was caught sharing his token and was fired.


Can a 3rd party validate the origin of an HTTPS session? I'm wondering if HTTPS can be used as proof that a server reported an answer.

If I understand correctly, the initial handshake is for HTTPS is the only time that the public/private key of the server is used. After that point a symmetric key is used, so the data passed back is not signed by the origin, just encrypted. Is this correct? If so, is there anyway to get signatures from arbitrary sites, given they support HTTPS?

If as a client I record the entire HTTPS session, is there any way I can prove to a 3rd party that the data I say I received was actually sent by the server?

Possibly, sometimes.

What's exchanged in the initial handshake is not just a symmetric key, but rather a "master key" for the session from which the client and server implementations of the selected cipher suite can extract keys for various purposes.

A cipher suite is split into a number of algorithms for different functionality:

Key exhange
Bulk encryption
Message authenticity

For example, TLS_DHE_RSA_AES_256_CBC_SHA256 would use ephemeral Diffie-Hellman and RSA for the key exchange, AES-256 for bulk encryption, and HMAC-SHA256 for message authenticity.

When the key exchange happens at the start, the long-term RSA key from the certificate is used to sign Diffie-Hellman key exchange parameters. The DH key exchange is used to agree upon a master key. The master key is then used to derive other keys, including 256 bits for the AES key (encryption key) and a number of bits for the authentication key (used in HMAC-SHA256, in this case).

Each record is authenticated using the authentication algorithm defined in the cipher suite. Usually, this is a HMAC hash.

Now, in terms of proving that the data was received after the fact, there are two cases:

If a non-ephemeral key exchange is used (e.g. RSA key exchange, not DHE or ECDHE) then the captured traffic can be entirely recovered, including validity of the authenticity hashes, given the private key of the server certificate.
If an ephemeral key exchange is used, then even if you get hold of the long-term key (server's private key) after a connection has occurred, you cannot recover the master key, and therefore you can't recover the messages or prove the validity of the messages. This is due to a property known as "forward secrecy", which arises due to the fact that the private elements of the key exchange are generated specifically for that session, and are discarded when the key exchange completes.

If, at the time of the connection, you decide that you do want to prove the content at a later date, you could save the master key of the session somewhere. By giving this key to the 3rd party who captured the conversation, you could show them the contents and they'd be able to see that the authenticity records were valid.


Delete cookie or set httponly and secure I'm currently in the middle of a vulnerability assessment and have found the cookies do not have Secure or HttpOnly set. I have recommended they set both of these to true for their cookies, but the developers have replied with they are not going to, for the following reasons:

They won’t be able to delete the cookie when logging out via javascript
The cookie is only used for meta data, not to authenticate data requests

Is this a valid defense? I can't find any (security related) reasons for choosing to delete a cookie over setting Secure and HttpOnly.

Login/session tokens or tokens that carry user data have to be Secure and HTTPOnly, or they become a security issue.

Explicitly hitting a logout button, rather than just token expiry, results in a "logout" request to the server. Have the server invalidate the authentication token (cookie) but setting it to some junk value. For example, Set-Cookie: token=loggedout.

Deleting a cookie may be a client side action, but setting a cookie can be done on the server side and you can still maintain HTTPOnly and Secure (which, as 8zero2.ops pointed out, is unrelated to this issue).


What is the risk of copy and pasting Linux commands from a website? How can some commands be invisible? Like all beginners in the land of Linux, I usually look for websites that
contain some useful shell commands, mark it with my mouse, copy it (CTRL + C)
and paste it into a terminal.

For example, if I need to install package_name.deb

sudo apt-get install package_name.deb

I will give my root password and install the package_name.deb

When I paste this command to my text editor, it will be something like:

sudo apt-get install package_name.deb && apt-get install suspicious_file.deb

Second example, if I want to add a new ppa (terminal)

sudo add-apt-repository ppa:some/ppa
sudo apt-get update

When I edit my sources.list, I will find something like:

deb http://ppa.launchpad.net/some-ppa/

and

deb http://ppa.launchpad.net/a_suspicious_some-ppa/

The problem is the second ppa deb http://ppa.launchpad.net/a_suspicious_some-ppa/  is added automatically and without my permission.

As you can see, there is an invisible part. It does not appear on my terminal.

What is the risk of copy and paste from an untrusted website in the terminal and how to fix my operating system?

Websites can append to your clipboard

The risk is exactly what you said it was. It's definitely possible to append malicious commands to the clipboard.

You could even append && rm -rf /* (only executes if the first command was successful), or ; rm -rf /* (executes even if the first command was unsuccessful) and brick certain UEFI devices.

You should also check out Michael's post in this thread for another example.

In the end, it really depends on how creative and malicious a particular evil "hacker" is.

But how can you make the commands "invisible" in the terminal?"

Method one

echo test;echo insert evil here;clear;echo installing package

Execution order:

Echo "test" happens
Echo "insert evil here" happens
Actions are "cleared"
Intended action happens here, but you don't see the rest.

...

You can try to scroll up in the terminal window to find the rest of it.
Method two

stty -echo
tput smcup

This will disable the terminal from showing what you're typing, so it doesn't appear in the terminal window at all.

You can try it like this:

stty -echo;tput smcup;echo evil commands
expected command

Those are just two really rough examples, but show the potential of what can be done to obfuscate commands. Note that it likely doesn't hide from ~/.bash_history unless the hidden commands specifically delete/modify it's contents.

You should assume that there are other ways to do this.

Mitigation

I recommend using an addon to disable clipboard manipulation. There are unfortunately ways to get around that, so I'd recommend pasting everything into a GUI text editor before it goes into your terminal, or anywhere.

You need to verify what you're doing. If you don't understand each individual command, you should google it. This is proper tinfoil hattery because copy and pasting can force the commands to auto-execute on many Linux flavors.

Repairing your Linux installation

You might not have any idea how deep the rabbit hole goes. Unless you have the time and effort to put into it, I'd suggest you just nuke from orbit, unless you have important files. If you have important files, just back up the non-executable stuff (no pdfs, documents, etc), and then nuke from orbit.

If you have PDFs, you can convert the PDF to post-script, or copy and paste the contents into a text file. With documents, copy and paste the text and format it later.


Does a Smartphone contain all the essential properties of a Smartcard? If not, what is missing? Can a smartphone, alone, be a valid substitute for a Smartcard?   If not, what is missing technically speaking?

Does the TPM chipset (which I assume is in the phone) provide enough security to "act as" a smartcard in various situations?

Since smartphones now can perform HOTP, TOTP, Asymmetric crypto, and zero knowledge proofs among others, and also authenticate the user with a thumbprint sensor that smart cards don't already do... perhaps using a smartphone is a better solution

Can a smartphone, alone, be a valid substitute for a Smartcard?

In one sense the answer is yes because a smartphone has all the capabilities that would commonly be attributed to a smart card.  I'm not sure I consider them equivalent because a smartphone has many more vectors by which it could be compromised.  The advantage of narrow scope is that it is much more easily reasoned about and therefore more easily secured.


How do I inform a company I found a leaked database of theirs on the Internet? Recently I found a leaked database of a company and I do not know how to go about contacting the company. It is so weird because I cannot find any type of Information Security contact email to report this to. It just has a support email. I feel uncomfortable sending the link to the support email.

Should I ask for an Information Security email contact from that company or what should I do?
By the way, the support email for the company is more of a fraud or customer support email not a technical support or security.

Also, what would be a good template to follow to give the best insight of the leaked database?

For clarification I did not penetration test any website that owns or distributes or has any relation with the company that seems to be likely to be possible originators of the database. I however found the database while using my internet searching abilities. I did not use any special tool or calculated methods. I am not a magician that knows where all databases or leaks are. I do stumble across content that is floating on the internet on places where they should not be.

The way I found the database was in a legal manner and not in an illegal fashion.

Don't give security info to non-security people. Use whatever contact method is available to ask for the right security person. Don't give details about what you found until you get someone who will understand it.

Then provide the details about what you found. Don't ask for reward or demand any kind of action or else you are very likely not to be taken seriously. Just provide help and leave it up to them to deal with.

I'm not sure what kind of template you need. Give them the info/steps they need in order to locate the information you found. If you sound too "scripted" you might sound like a scammer. Be human. Be helpful.


How do you verify the key given by remmina (libfreerdp2) This morning I took an update to remmina and started getting a "fingerprint changed" warning. When using xfreerdp (from freerdp-x11) I get they old key. The old key being 20 bytes and the new key being 32 bytes.

I originally thought this made it a remmina bug, but changing to freerdp2-x11 gets the new key.

The thing is I knew were to find the thumbprint to verify the old key (It is in certlm.msc "Remote Desktop" folder). I have no idea where this new key is coming from and nothing so far seems to tell me how to make sure it's really coming from my Windows 10 install. It appears most notes I see on this just tell the user to accept the new key or turn on "ignore invalid certificate" and no mention of how to verify this 32 byte key.

So I'm desperately trying to find out if there is anyone who knows where this new 32 Byte key is coming from and how do I check it against the Windows host?

freerdp is now displaying the remote desktop thumbprint in SHA256 format.  Before that, it was displaying it in SHA1 format.  Windows is still displaying it in SHA1 format hence when you look at it visually, the numbers don't match.
You can extract the certificate in Windows and generate a SHA256 for the certificate. Run the following on the extracted certificate:
openssl x509 -noout -fingerprint -sha256 -inform der -in remotedesktop_cert_der_x509.cer


How important is a dedicated SSL certificate vs. shared for eCommerce? At my work, we've been using Network Solution eCommerce for many years now, and they have been working very well for us. However, as the years go on, their services become more and more outdated. As a web developer in 2014, working with a strictly table-based layout is frustrating. The constant need to us JavaScript to modify the layout, as well as using multiple CSS hacks has driven me to look for a new solution. My boss wouldn't mind moving away from the platform either.

I have been eyeing up Shopify for some time now. It's a designers dream in terms of eCommerce, being able to design it from the ground up using HTML 5, proper CSS, and eliminating the need for all the JavaScript and CSS hacks. However, they use a shared SSL certificate instead of a dedicated SSL. On our current site with Network Solutions, when a user goes to our checkout, they go to https://www.ourwebsite.com/checkout.aspx. With Shopify, they go to https://checkout.shopify.com/carts/randomhashidentifyingyourcart.

This doesn't really appeal to my boss. He believes that as a medium-sized, reputable business, if a customer noticed that change in the URL, it would either a) deter them from continuing, or b) make us look smaller/less reputable than having our own SSL. I understand his point, but I'm not sure that many users will care. He uses Shopify for one of his side businesses already, so he is familiar with the platform and loves it, but just isn't sure the SSL issue is fitting for our business.

I guess I'm looking for some other peoples opinions on this issue. Sometimes I can convince them to make changes even if they don't like to, so I'd like to have some opinions and info from other people to back me up a bit. We have many more pros for making the switch than cons, with the cons only being the SSL.

The "shared SSL certificate" actually translates in a visible form an underlying structural property, i.e. that Shopify is a shared eCommerce platform. When you use Shopify, your store is running on their systems. If that makes you look like a cheap business, then well, I guess you are a cheap business after all. The shared SSL certificate is just a technical point in which your cheapness is made apparent.

Technically, having your own name for SSL connection can be at odds with some constraints on Shopify's side. It is due to the following:

In HTTPS, the SSL occurs first; the HTTP request (which includes the target server name, as seen from the client) will be sent only when the handshake is completed.
During the handshake, the server shows its certificate to the client.
The client expects the intended server name (as it appears in the URL) to be part of the identities contained in the server certificate.

So a server who is hosting several (many) sites with distinct names on the same IP address must somehow guess the intended server name, so as to use the right certificate. Such guessing may use the Server Name Indication extension, if the client sends it -- but IE on Windows XP does not send any SNI. The consequence is that if Shopify wanted to support shop-specific server names for SSL, then they would have to do one of the two following things:

Allocate a new IP address for each shop (given the current relative shortage of IP addresses, this can become expensive).
Forfeit XP+IE customers (a non-trivial business decision).

In any case, Shopify is God: they have full control over your online store. The shared SSL certificate corresponds to that fact; it does not add any additional security issue.

(Said otherwise, you get what you pay for. If you want your SSL with your own name, then you have to own your own IP address, preferably your own server as well.)

Personally, as an occasional online customer, I feel rather safer when I see that the payment system is handled by a bank or some specialized platform like Shopify. That's because I know that 99.99% of frauds and other similar adverse events don't occur during the transit of the credit card number over SSL, but afterwards, on the server side. I really prefer it when professionals are at the command. Attackers don't bother trying to run fake SSL server to catch a dozen credit card numbers; they prefer hacking into amateurish servers to purloin thousands of credit card numbers where they were (poorly) stored.

However, I am known not to think like an average customer. That's the fate of being an information security professional, I believe.


Bypassing file upload restrictions However an exercise I do not manage to resolve, I have to bypass a check of extension of a form in PHP.

It turns out that just the extension is verified, but certain special characters are replaced what makes that even by trying the following combinations, it does not work.

test.php%00.png
test.php:.png
test.php$.png

I specify, these names of files bypass well and truly the check of files. But as this one is then renamed, he returns to the state of PNG.
For example, with one of the examples higher, the file is going to be renamed as follows: 556112012015test.php-.png

The purpose is relatively simple... I am supposed to send on the server a executable file PHP. But I have to admit that I do not find. I have a part of sources to use, here is :

// Censored.

This line clearly indicates that any characters other than letters, numbers and points will be replaced by a dash.

$name_file = preg_replace('/([^.a-z0-9]+)/i', '-', $name_file);

As it is an exercise, there is necessarily a way to exploit it. But I do not find..

Thanks,

I shouldn't really answer homework, but your upload script needs to have a very specific filename. Take a closer look at what happens if you upload a filename that already exists.


java script in link href="javascript:alert(1)" In an app I am testing they allow to input a domain name, store it, and when they print it on the browser they concatenate "http://" at the beginning of the domain. So, if you input "google.com", then they create a link like this:

 google

So, if you try to input "javascript:alert(1)", the link would be

 google

If they would not concatenate the "http://" at the beginning, that javascript would execute when the link is clicked. So, we can be sure that that is 100% safe from XSS because they always concatenate the "http://" at the beginning?

Thanks!
Note: If you input quotes, they encode them as \u003ca

I don't think this method would be safe from XSS. This type of vulnerability sounds like a typical case of Reflected XSS. If you would escape the href tag with some " you can enter a XSS code. Your link would look like this if you enter foo.at"><script>alert(81)</script>"page=1 into the input field ->

<a href="http://foo.at"><script>alert(81)</script>"page=1">google </a>

I would suggest to use a filter on the website which converts all special chars to an other format. Like htmlspecialchars in php.


Dynamically decrypting files Is it possible to store (video) files encrypted (using AES or similar) in the cloud and have clients' browsers download those files and dynamically decrypt them to start viewing them whilst they are streaming?

If yes, is this possible with basic AES or does it require a special cipher algorithm?

Not really.  You could use some proprietary DRM that does something along these lines and works with browsers, but you are probably better off decrypting on the server side and transporting the video content over TLS to protect it from interception.

To clarify based on your additional information you would have a web application server that decrypts the videos on the fly as it loads them from the cloud storage.  This should be achievable by streaming data from the cloud storage and then streaming the decrypted output over HTTPS to the browser.  Getting this to scale may be quite tricky though as you'll be held back by the latency of the cloud storage.  You may want to prefetch of cache popular segments of videos on your web application edge or go with a video-capable CDN (content distribution network) if your cost model permits that.

If you can do decryption in JavaScript and you can use WebSocket or WebRTC to send binary data streams, then you can decrypt the buffers as they arrive.  Feeding the decrypted data into a player of some sort incrementally is the next step.


What TLS and SSL protocols should I have turned on I am using Explorer as my browser.  What do I have to have on regarding the TLS and SSL protocols.  There are several of each one.

Enable all of the versions that can be enabled (preferably, TLS 1.0 and higher), and then let the order of preference to the server.

Since you're using Internet Explorer, go to the Internet advanced settings and enable the following according to your version:

Internet Explorer 6: Enable TLS 1.0
Internet Explorer 7: Nothing to do. TLS 1.0 is enabled by default.
Internet Explorer 8-10: TLS 1.0 is enabled by default. Enable TLS 1.1 and TLS 1.2
Internet Explorer 11: Nothing to do. TLS 1.0, 1.1, and 1.2 are enabled by default.


multiple dice ware lists to make memorable passphrases? I understand the basics of why diceware produces good security and why seven word passphrases are a good idea these days.

The EFF has helpfully produced updated diceware lists that eliminate lots of the hassle of memorizing diceware passphrases. (see https://www.eff.org/deeplinks/2016/07/new-wordlists-random-passphrases)

But a seven word passphrase even using the EFF's new long diceware list can still be hard to remember. Sure, over time, most people will remember it, but I wondered if there is not a simpler way to achieve security and memorability.

(Apologies in advance if this is a rehash of something much smarter people have already thought of.)

Since knowledge of the diceware list is irrelevant, because only the length of the list of unique words contributes to the entropy, then presumably choosing from multiple lists is as secure as choosing over and over from one list.

So why not create four separate lists, each with 7,776 words, but each strictly limited to either a) adjectives, b) nouns, c) verbs, and d) adverbs?

A diceware passphrase would be created normally, rolling 5 dice for each word.

But, assuming we are aiming for a seven word passphrase, we would choose:

word 1 from list a (adjectives)
word 2 from list b (nouns)
word 3 from list c (verbs)
word 4 from list b (nouns)
word 5 from list d (adverbs)

This would produce an English sentence of the form:

adjective noun verb noun adverb
(e.g. blue fireplace eats dog briskly)

which would be probably bizarre but also easily memorable for most people (with no less entropy than a five word passphrase chosen from the standard diceware list or from EFF's improved long diceware list).

That's not long enough for security though, so we could continue and choose:

word 6 from list b (nouns)
word 7 from list d (adverbs)

resulting in a 7 word passphrase of the form:

adjective noun verb noun adverb noun adverb
(e.g. blue fireplace eats dog briskly television enough)

Slap an "and" between the 5th and 6th word and the sentence probably is as easily memorable. Presumably the "and" cannot decrease security because even knowing it, we still have 7776^7 word combinations in the sentence.

I assume the biggest problem with this scheme is there may not be 7,776 adverbs in the English language (or maybe there is?).

In that case, we can still use a similar scheme, using two sentences constructed only from lists of adjectives (of which there are probably an order of magnitude more than necessary in English), nouns, and verbs, like so:

word 1 from list a (adjectives)
word 2 from list b (nouns)
word 3 from list c (verbs)
word 4 from list b (nouns)
word 5 from list b (nouns)
word 6 from list c (verbs)
word 7 from list b (nouns)

Slap a semicolon or period between words 4 and 5 if you want and you get something like this:

adjective noun verb noun noun verb noun
(e.g. blue fireplace eats dog; television flies pizza)

I speculate these types of sentences are more easily memorable for most people because they create action images which people can remember easily. In the example above, it would be of a blue fireplace eating a dog, while a TV is flying on a pizza.

An 8 word passphrase could be made by including an adjective in the second sentence too, obviously.

Is this a strategy already explored?

Does it have known weaknesses?

Are there published diceware lists of nouns, verbs, and adjectives? (And adverbs?)

While they don't directly answer your question, I think that reading up some of the other password-related questions on this site will help you think through this process.  I would start quite simply with this question, which is also the most upvoted question on this site.  Together, the answers really break down the relevant security and usability concerns:

XKCD #936: Short complex password, or long dictionary passphrase?

The short of it (as you seem to understand) is that any password generation strategy ultimately boils down to entropy, which can roughly be understood as "randomness".  Selecting 7 times from a word list with 7,776 words would give you a total of approximately 1.719e27 possible passwords, or approximately 90 bits of entropy.  The fact that you switch between lists for the given word order doesn't really change the picture substantially (you technically have more words to chose from, but you switch between the list of choices in a predictable fashion).  As a result, from a strictly-entropy standpoint, this isn't substantially stronger or weaker than a more standard diceware generation pattern.  On the other hand, if it makes it easier to remember the password, it would at least be a usability improvement, and that is always a good thing.

That being said, both are certainly "secure enough" for the foreseeable future.  Relevant would be this thread that talks about a password with 80 bits of entropy:

Is an 80 bit password good enough for all practical purposes?

And this looks at the practical limits for cracking password hashes:

https://security.stackexchange.com/a/13016/149676

All of which boils down to the same thing: cracking a password with 90 bits of entropy would likely cost more than the entire economic output of the USA, but you are still vulnerable to phishing, social engineering attacks, and the like.


Identification through digital signature. How safe is it? Let's say I want to give some data to Bob. I have his public key. I tell him to generate a digital signature for text "{some_stuff: 1, nonce: 2}". After he does that and after I verify it's the right signature, I give him the data. I use a different nonce for each session. Is there anything I need to be aware of? Is it pretty secure?

Digital signatures are used extensively for authentication in many secure protocols, such as SSL/TLS, SSH, etc.  Of course, this requires the verifiying party to have some way of knowing that the public key purported to belong to the autheticating party is true and correct.
The parts that are not clear from the description of your process are:  1) How does Bob authenticate you?, and 2) How is the data transferred from you to Bob securely?
Ideally, your protocol should have a way for the client and the server to mutually authenticate each other, and for the data be encrypted as it is sent through the network.  It's best if the encryption is done using perfect forward secrecy (PFS), so that if an eavesdropper on the network records the cyphertext passing through, he can not later decrypt the cyphertext even if one of the parties' private keys is later compromised.
For the sake of this question, assume that each party has a long-term key pair, and each party has some way of knowing that the public key purported to belong to the other party is true and correct.  Modern protocols (such as those mentioned above) accomplish all of the above using a method along the lines of the following:

Client generates an ephemeral key pair and sends ephemeral public key to server.
Server generates an ephemeral key pair and computes shared secret using server's ephemeral private key and client's ephemeral public key.  Server signs shared secret using server's long-term private key, and sends ephemeral public key and signature to client.
Client computes shared secret using client's ephemeral private key and server's ephemeral public key.  Client verifies server's signature on shared secret using server's long-term public key.  Client signs shared secret using client's long-term private key, and sends signature to server.
Server verifies client's signature on shared secret using client's long-term public key.

At this point, if all of the signatures have verified, the client has authenticated the server, the server has authenticated the client, and the client and server share a shared secret.  This shared secret can be used as an encryption key to a symmetric encryption algorithm (such as AES), so that the two parties can share information between each other securely.  At the end of the session, both parties discard the shared secret and the ephemeral keys to ensure PFS.


Card Present PCI Requirements We are using an IDTECH card reader for iPhone that is not encrypted, our application is web based and runs inside of an iOS app to pull the data off the card. We are then using a client side encryption library to encrypt the card data before it goes to the gateway. We do not store the card data in our database and our servers are PCI DSS Compliant. We want to use the non-encrypted MSR so we can scan driver license as well. Will this method comply with PCI 3.0?

In a nutshell, no.

Basically, any physical input device that "receives" clear card data (for example, by data entry - typing, swiping or other methods) must appear on the PCI "PTS" certification list.

In theory (and very concisely), this certifies that the device uses approved forms of encryption, key management,etc., only outputs safely encypted data, and is tamper-proof (to the point that any tampering destroys the crypto keys.)

Basically, the use of an uncertified device for input negates everything.     It theoretically could be possible to obtain a "compensating control" around that,  but as a practical matter, that is NOT going to happen.   You are best just getting an approved device as your input device (for example, Magtech has a line of devices that work with IOS devices.)

Search the PCI PTS list as a starting point, or reach out to your financial institution for guidance.)


Whitelisting only particular hosts on Windows 10 There is a laptop which is to be secured and only certain websites should be accessible.

Reason is possible data theft by user or malware, from vpn-only-accessible websites which this laptop will be accessing daily.

Laptop is physically secured with lock and in a surveilled environment, USB ports are disabled.

For whitelisting particular sites, approach taken was to:

Set IP to DHCP but DNS is manually entered, given a bogus server IP,
which is inaccessible. So DNS look-up doesn't work.
Add hosts records to c:\Windows\System32\drivers\etc\hosts . So DNS
look-up for allowed websites works.
By checking Chrome console errors, add other required asset hosting
domains to file above (i.e jquery of particular website is sourced
from cloudflare CDN and such.)
User has limited privileges and can't make changes to above.

This method is cumbersome and I was wondering what other ways might be more suitable and easier to implement.

Hosts file sample:

X.X.X.X    allowed-website.com
Y.Y.Y.Y    cdn.asset-domain.com

You can enforce it via GPO. The steps are for GPO settings but you can use local GPO settings also.

Navigate to User Configuration > Policies > Windows Settings > Internet Explorer Maintenance > Security and then click on the “Security Zones and Content Ratings”

Modify Content ratings to "Import content ratings" > modify settings

In the approved sites tab give your whitelisted url.
In the General tab uncheck "User can see websites that have no
rating"


Using 1-day expiration GPG keys only... any disadvantages? From the thread Does OpenPGP key expiration add to security? , we know that the faster the keys expire, the greater our security. The minimum expiration for a GPG key seems to be 1 day. Thus, isn't it much more secure to generate a new GPG key (that expires in 1 day) once per day?

That means, we generate a new GPG key whenever we want to sign a document, and we only re-use the key for a maximum of 24 hours before generating a new one.

However, this practice does not seem to be widespread. I see many people using the same key for months, or even an entire year before generating a new one.

What may be the disadvantage of only using 1-day expiration GPG keys?

What may be the disadvantage of only using 1-day expiration GPG keys?

Even a minimal check of a new GPG key in professional/sensitive/regulated environments should involve something akin to a phone call to the other party's known phone number, and checking the key's fingerprint against what they have for the fingerprint.

If I have a daily file process, then for every key I get (1 per day per client/vendor/process/etc.) this requires

obtaining your daily key
importing your daily key into my keyring
validating your daily key's fingerprint to reduce the chance that it's an imposter
having my automated process figure out your newest key (NOT something that anyone I'm aware of currently does)
avoiding key identifier collisions as my keyring grows
pruning my keyring regularly to get rid of thousands of expired keys over the years

Further, imagine I have as few as 100 automated file processes, and if they're all (business) daily, that's over 26,000 keys a year!  The Birthday Paradox is going to start rearing its head for short keyid collisions, not even counting the time spent doing all the above maintenance... and debugging the inevitable issues.

Key management is enough of a pain already - a hundred new keys a day?  I don't think so.  I'd rather deal with 100 purely random passphrases a day for symmetric encryption than 100 new GPG keys a day - it's less overall effort.

On a human note, I don't even want to think of the friendly name and email address collisions, given how hard it is to get most companies to use a SHA-256 or better self-signature, or even good cipher and hash preferences.


My postfix server is getting DOSed, what can I do? Port 25 is open and I'm getting thousands of emails. How can I make it stop?

If you can, try to :

Rate limit your router to prevent your server from being
overwhelmed
Add filters to tell your router to drop packets from the obvious
sources of the attack
Timeout half-open connections more aggressively
Drop spoofed or malformed packets
Set lower SYN, ICMP, and UDP flood drop thresholds


company is sending md5 string via GET['password'] dangerous? So, this big, reknown company (you all heard off) is sending md5 encrypted strings (with GET key: password) over HTTP.

I accidentally came over it since I wanted to use jnlp on a non-windows machine. And I am curious. Is it by definition insecure to work like this, or can it be safe when one uses SALT and other stuff alike?

The URL looks like this: url/folder/page/?login=[USERNAME]&password=[MD5-String]
This URL is also stored in the corresponding .jnlp file.

I hashed my password to MD5 and it is not the same as the password in the URL.

First and foremost, I am curious. I do not have the skills to exploit this (if it where possible), and don't even want to exploit it. If you guys think I should notify the company in question: I will do so.

Thanks!

I am curious. Is it by definition insecure to work like this.

No. Submitting passwords via GET is not fundamentally less secure than submitting them via POST (which is what every other site does). It does mean that the "password" is stored unencrypted, but if done right, that password that they're storing not your actual login password but rather a password used specifically for this purpose. In fact, the string you see that you assume is MD5 may actually be the password itself, generated at random.

A authentication token passed in a URL is problematic because it (a) is easy to copy, even accidentally, (b) is cached, (c) shows up in referrer strings, (d) shows up in logs, (e) offers little in the way of actual authentication. Instead, of doing true authentication, the URL itself is the key.

On the other hand, this may be exactly what the company wants. If you want a protected resource to be accessible to anyone who knows the correct URL, then this is how you do it.

If they simply called it "access token" instead of "password", would you suddenly feel better about it?

  If you guys think I should notify the company in question: I will do so.

If that will make you feel better, then go ahead and tell them. They already know, of course, since they built it. It'd be like notifying someone that their car is blue.


Website asks for my identification card - Is it safe? I want to register to a site (something like Steam that you can add money and buy later) and for the registration to be completed, it asks for a photo to be taken with my phone of my identification card (with my ID number and personal details like my name, age, place I was born etc). Is it safe to give them a photo of my ID card? Can they do anything with it without my permission?

I'm talking about ID cards, not credit cards.

With the updated information, that PaySafeCard are requesting this I would be more confident it's not a scam / social engineering attempt, they are a legitimate and registered UK company.  Although - any one can be vulnerable to a breach, so the question is do you trust them to securely store a significant piece of your identity? Do they store it permanently, if so , how and where? Do they destroy it after initial verification?  These are perfectly valid questions and their customer services team should be able to answer you and comfort any doubts, if they can't then don't trust them with your data.


Modern Browsers, Safe to Ignore CSRF? For users using modern browsers, is it safe to assume they won't be able to be hijacked via CSRF and the likes? If not, how likely is it that an attack can take place?

No, there is no protection offered against CSRF by any browser by default. This is because the browser does not know the difference between a legitimate cross site request and an attack.

How likely - this depends if

A CSRF vulnerability exists in any of the sites you visit that you remain logged into.
A CSRF exploit for one of those sites is active on any other site you may visit.

You can protect yourself if you only log into one site at once, and clear your cookies between each (it might be better to restart your browser to make sure session cookies are cleared too, although Chrome can run in the background too so you'd need to make sure it is fully closed, and additionally Chrome can resume sessions between restarts so experiment to make sure your settings are correct to prevent this).

Also you should make sure other objects are cleared such as HTML5 local storage, and Flash and Silverlight storage. It might be easier to open a new incognito or private browsing window for each site you visit, making sure to close all tabs and windows before you visit the next site.

Both approaches will make sure that any CSRF attacks attempted while you browse the web will fail because you will not be authenticated on the target site. The only possible CSRF attack you may have to worry about is if you use any sites that use your IP address as the only means of authentication, or if you have set your browser to automatically provide a client-side certificate. Incognito mode should protect your from the latter though.


Can javascript damage data and hardware? I once had a script looking like the one below:

window.open("SameSiteUrl");
alert("spamspamspam");

it had some strange laggy effects... Anyways, a friend "pranked" me by running the script overnight. My PC had a shutdown timer, but when I went to turn it on, it said that one of the CPU cores was failing to respond. Later I found out that it got fried.

My point is, can JS scripts like this really be used to damage your data nowadays?Or worse, damage your computer like it did to mine? If so, how common is it? I haven't noticed such scripts before until recently again. I'm more worried about my data then my hardware.

I know javascript is kinda limited, but I also know you can easily lag a tab or browser to death with it.

Modern CPUs are designed to prevent damage due to overheating. They have overheating protection that operates independently of OS or BIOS. So, it is unlikely that executing JavaScript can damage your hardware.

As to potential impact on your data, modern browsers are designed to execute JavaScript in a limited environment that is meant to prevent abuse of JavaScript to harm or steal your data.

Even though that is the intent, from time to time vulnerabilities in browsers are found that might allow attackers to affect your browser in some way - for example, crash it by tricking you into visiting a Web site that they control.

Your best protections against it:

Keep your OS up to date
Keep your browser up to date
Use a browser extension that allows execution of JavaScript from trusted domains only (Firefox, Chrome)


Could somebody explain connect loop DoS? I'm trying to understand this vulnerability.

How can I reproduce this?

This vulnerability forces your proxy to go into an infinite loop, causing a DOS because of exhaustion of local resources like CPU, RAM or any other resource.

The reason that it would go into infinite loop is because basically all you're proxy is doing is forwarding requests to someone else. What happens when you tell your proxy to forward the request to itself? It would receive the request, forward it to himself, receive it again, forward it to himself again and so on.

Now at first this may not be a big problem with just 1 request looping, however if you send thousands of proxy connections like these it will build up as a problem really fast.

The same thing could be done in internet routing protocols if it had not been for the TTL (Time to live) flag in the IP packets. According to rfc2616 you're proxy should not forward requests if Max-Forwards field is set to 0.

To reproduce this you would create a HTTP packet looking something like this:

  CONNECT <proxy connection>:80 HTTP/1.1
  Host: <proxy connection>:80


Purpose of using GUID for files along with underlying permissions checks Some sites utilize a GUID for a file name when it goes in storage. For example, when you load up a receipt, instead of having the receipt named something like 1200 (an incremental number), it will have a GUID instead. What is the purpose of using this GUID if the underlying back-end code permissions checks are in place (User must be admin with receipt reading permissions or must be the receipt owner) instead of leaving in the incremental numbers in place?

Because generating a new GUID is trivially easy, whereas keeping track of which was the last sequence number issued and making sure that the next one is issued only once (no multi-user timing problems) is much more difficult.

Also, a GUID leaks no data; a sequence number discloses the number of files being stored.


Auto log-out sequence based on inactivity on desktop devices Applications that monitor user activity may log out of the app if there is no user activity in the app for more than kLogoutInterval period. This value could be 1 or 5 or 10 15 minutes based on the type of the app.

The question is however — how do you store the timestamp? Do you store the timestamp in the memory using some ActivityManager singleton class? OR for every activity, you would update the timestamp in the keychain? OR any other pointers?

EDIT: Just to clarify, the question is — is this timeout filed critical? Can it be simply exposed in the memory? Does it need to be stored in a secured asset like a keychain? What is the overall risk assessment for using this timestamp casually?

If an attacker can write to specific memory locations to prevent logout, you're already severely compromised.  Any attacker that can change arbitrary memory can write arbitrary code to it.

If an attacker can read specific memory locations, you're also very likely severely compromised if you store anything in memory you wouldn't want world+dog to know.


Somebody trying to ssh attack via hosting services on me. What is the best response? I am having a lot of failed ssh authentication requests for the past two days, from various service providers. It seems somebody is intent on breaking into my computer.

I am using Ubuntu on a Dell laptop, I need to have sshd running for work purposes, so shutting it off is not an option.

I blocked all the ips off for the moment, and crippled the attack. What is the best response to such a situation?

It's very common among public servers or a host. I'm going to assume that your host is a server which is using Public IP i.e can be accessible from anywhere. Here is some precaution:

Change default port: The ideal idea for this kind of situation is to move default port (22) into higher port. You can do that by changing the configuration file located at '/etc/ssh/sshd_config' as following,

$ vi /etc/ssh/ssh

And make the following change,

# Port 22
Port 23415

Define specific IP: You always can define specific IP of the host from which you usually ssh to your laptop and drop all other requests with IPTABLES with the following commands [here I am assuming you are using port 23415 in place of 22],

Drop IP's trying to connect in port 22

sudo iptables -A INPUT -p tcp --dport 22 -j DROP

Whitelisting IP's: You can add multiple IP.

sudo iptables -A INPUT -p tcp -s YOUR.IP.HERE --dport 23415 -j ACCEPT
sudo iptables -A INPUT -p tcp -s YOUR.Another.IP.HERE --dport 23415 -j ACCEPT

Drop Other IP's request:

sudo iptables -A INPUT -p tcp --dport 23415 -j DROP

Save new rules:

sudo iptables-save

Using SSH securing app: There are plenty of SSH securing app available like Fail2ban, Denyhost, Sshguard etc.


Github Pages Security, From .com to .io Github pages is now using github.io domain instead of github.com I've read github explanation but it's still difficult for me to understand the root cause. Why would a domain become a security issue?

The HTTP cookie mechanism allows you to specify the domain a particular cookie is associated with. The domain can be the domain of the page setting the cookie or, more interestingly, one of its superdomains. E.g. foo.bar.example.com is allowed to set cookies on the foo.bar.example.com, bar.example.com and example.com domains.

What does this mean for GitHub Pages? Well, subdomains of the github.com domain are allowed to set cookies on it, meaning they can perform session fixation attacks by providing the browser with an existing session cookie. Here's how a simplified attack scenario would look:

Let's say github.com uses a cookie called SESSION_ID to identify active sessions. This cookie contains a unique hash, long enough to be impossible to to guess. Each hash is associated with server-side session data, i.e. a logged-in user.

Now consider an attacker who sets up a GitHub Page at evil.github.com. They include some of their evil scripts in the page and then trick a victim to visit it. What does the page do? It sets the SESSION_ID cookie on the github.com domain to a valid value known to the attacker. This would cause the victim's browser to effectively log in to GitHub using the credentials provided by the attacker. The attacker could then follow the activity on the account and retrieve any data created by the clueless victim.

Moving GitHub Pages from github.com to github.io fixes the issue, since there are no user accounts or sessions on the new domain.


Security of the KWallet password encrypting application? According to http://gaganpreet.in/blog/2013/07/24/kwallet-security-analysis/ , the KWallet password management system is quite weak, it uses key splitting, Blowfish 56, and no salt.

  The key generation can be described as – break up user password into blocks of 16 characters each, and apply SHA1 2000 times on each of them. This is key stretching without a salt. These blocks are then trimmed and concatenated to fit into 56 bytes, the maximum key length allowed by the Blowfish cipher.

It also says that, although it uses CBC, the way it uses it it becomes ECB.

  KWallet uses CBC, or to be accurate, it pretends to – the keysize used for CBC is the length of the string to be encrypted, which turns CBC into the less safe mode of cipher – ECB.

My issue is, I use the same password for root as I do for my KWallet.  /etc/shadow is only readable by root, but my .kwl file is readable by anyone, so anyone can get the file and try to brute force it, with possible success.

So is there any way I can improve the security of KWallet?  It's not just for my manually inputted passwords, it's also for web browsers and applications which rely on KWallet to store passwords (e.g. Chromium), so I can't just switch to another program.  Perhaps I could edit the source code, or find a fork that's compatible?

My final questions are: Is there any way I can improve KWallet's security, and how much of a security concern is using it?

The blog post you quote is quite imprecise in its formulation. However, by looking at the KWallet source code, especially this file (for the password hashing) and that file (for the invocation of the encryption code), we see the following:

The password is extended into a symmetric key of size 20, 40 or 56 bytes (160, 320 or 448 bits) by applying SHA-1 repeatedly. Namely:

If the password has length 0 to 16 characters, the key will have length 20 bytes and be the repeated application of SHA-1 (2000 times) on the password (the password is hashed, then the 20-byte output is hashed again, and again, for 2000 invocations of SHA-1).
If the password has length 17 to 32 characters, then the key will have length 40 bytes: the first 16 characters are processed as above, then the remaining characters are processed similarly, yielding 20 more bytes.
If the password has length 33 to 48 characters, then the key will have length 56 bytes: the first 16 characters are processed as above, the second chunk of 16 bytes of characters as well, and then the third chunk; the output for the first chunk is then truncated to 16 bytes, for a total of 56 bytes.
If the password has length 49 characters or more, then the 2000 SHA-1 invocations will happen four times. For the fourth chunk, the complete rest of the password will be used. The four 20-byte output are then each truncated to 14 bytes, and these are concatenated, yielding a 56-byte output.

As a password hashing function, it is quite poor. It is clunky and not regular. It is not salted, allowing for efficient parallel attacks, when several KWallet instances must be broken (as usual, "parallelism" also means that precomputed tables can be used, negating the slowing effect of the 2000 SHA-1 invocations). Moreover, it "splits" the password, so if an attacker finds a password hash, then he can attack each chunk independently of the others. This means that the security of the whole thing relies a lot on how well the Blowfish block cipher behaves when used as a hash function. This is, at best, a poorly studied property.

The encryption purports to use CBC, but does not. In CBC, you are supposed to encrypt a sequence of blocks (8 bytes per block with Blowfish); before encrypting a block, it is first XORed with the previous encrypted block. For the first block, we must conjure a formal "previous block" which is the Initialization Vector. CBC requires a random IV.

In the KWallet code, we see that the code indeed prepares a random IV of the right size.... then completely fails to do CBC. The call to encryption is:

int rc = bf.encrypt(wholeFile.data(), wholeFile.size());

(line 291 of backendpersisthandler.cpp)

Looking at the implementation for this encrypt() method, in cbc.cc, we see that it will create a temporary buffer of the same size of the whole file; then fill it with zeros; then XOR all these zeros with the data to encrypt (which won't change the data...); then proceed to encrypt each block independently of each other. This is, indeed, ECB mode, not CBC. It is quite obvious that this is a programming error; the lesson to learn, though, is that since KWallet appears to work, then the mistake was not detected: security cannot be tested through functionality.

(This implies that the random IV which was computed does nothing here; it is encrypted by itself but does not impact any other byte in the whole file.)

ECB mode is known to be weak in the following sense: it leaks information about what blocks are equal to each other. For an uncompressed picture, this is deadly, as demonstrated with the usual penguin image. For a KWallet, this is a source of worry: the internal structure has some redundancy, and this may be exploitable, although it would require some effort to ascertain the extent of the issue.

Note that since the password is not salted, two successive versions of the KWallet protected with the same password will use the same symmetric key, so block equalities leaked by ECB apply to all successive versions of the KWallet.

There is a homemade MAC. The last 20 bytes of the file (excluding some padding) contain a SHA-1 value computed over the rest. This is, generally speaking, not a good MAC. It would be an extremely bad MAC if the encryption used RC4 or a block cipher in CTR mode. With a block cipher in ECB mode (as used here), it is not as bad, but still poor.

The whole code reeks of homemade crypto slapped together by someone who did not master the concepts. This is bad. Also, I find the code to be atrocious in many respects (e.g. when the password chunks are hashed, the loop which invokes SHA-1 repeatedly is ruthlessly duplicated; that's a shooting offence). To "improve" KWallet, I suggest deleting the whole code and starting from scratch.

It seems that the code includes some optional support for not doing the password hashing and encryption itself (as we saw, it does it very poorly), but instead using GnuPG. Now THAT is a good idea. GnuPG implements the OpenPGP format which, for all its shortcomings, is at least decent cryptographically speaking (when properly used), and GnuPG is also known to be a tolerably good implementation. To improve storage of your KWallet, see if you can convince your computer to use this GnuPG support code and format.


What is the definition of "multi-failure" disaster recovery? There are several compliance and certification criteria that mention "multi-failure" disaster recovery. What exactly is the definition of this? A google search did not turn up a clear answer for me.

Multi-failure tolerant systems are exactly that; Systems that are designed such that they can handle multiple failures through multiple/layered redundancies. You won't find a more detailed definition of this in any RFP, compliance, audit, due-diligence document as it's a general concept and will look different for every system/service.

For those looking for a bit more:

If there is any question to your ability to handle multiple failures, you need to run some scenarios. Get a high level view of your system, try to identify any single points of failure, if you succeed, you have work to do. Assuming you didn't, identify your failure domains. At a high level, this would usually be a Data Center. Lower levels could be Racks, servers attached to a common NAS/SAN, VMs on a bare metal host, individual applications, etc. In your scenarios, randomly pick a piece of hardware, application, rack or other object in your system architecture and mark is as dead. Also mark anything that relies on that object dead. If it's a rack, everything in that rack is dead, if it's a database cluster, every thing that needs data from that source is dead. If its a data center, everything there is dead. You get the idea. Now, with that object dead, and it's failure domain dead, add another random object to the down list, along with it's dependencies.

If you find yourself wanting to avoid certain parings of objects in these scenarios, you probably have some work to do. If you find that for the vast majority of combinations of two or three random objects marked offline, your service is still online and clients are happy, you've done well. Most companies will be able to identify at least a couple areas where they need improvement.

If you have three data centers with complete copies of servers/apps/storage in each dc, you can easily check yes on this question. But a lot of companies don't operate with three production capable sites.

As a related note, while AWS, Rackspace, etc offer multiple availability zones, etc... At a high level, any single service provider is still a single failure domain. This is a common note that pops up on these types of scenarios. This may or may not be a risk your business can accept, but you should at least be aware of it and actively make that decision. Numerous cloud based companies use more than one provider or use a cloud provider and in-house resources. It's also really sad when you see a company offline because they had all of their resources in one availability zone when it went down.

Disaster Mitigation Planning is all about identifying failure domains and ensuring there is n+1 replicas of any subsystem, where 'n' is the number of failures you have at any given time.


What information about me do stores get via my credit card? Lets say I buy something at some (physical) store and pay using a credit card on one of these electronic terminals. What information do the owners of this store get about me (or my credit card) from this transaction?

Can they find out whether multiple purchases were paid using the same credit card?

From the card itself, the Merchant gets the track data, which includes card number, expiration date, and cardholder name.

If the Merchant requires zip code verification, they'll get your zip code, obviously.

(Card-Not-Present Merchants often get address data for billing/shipping purposes, but you asked about physical stores... and they get that from the Customer, not the card itself.)

The Merchant can track purchases made with that card within their store(s), but not those made at other, unconnected stores.  Be aware that sometimes multiple stores (e.g. HomeGoods, TJ Maxx) are actually the same "Merchant" (TJX Companies).

The Processor, on the other hand, can correlate a single card's activity across multiple Merchants.  They don't generally have transaction details ("what you bought") but they do have amounts, categories, Merchants, times, all of which may be provided to the Card Brands (Visa, Mastercard, ...) upon request, or law enforcement upon a subpoena.

Each processor will have a different view.  If Processor A handles Merchants A, B, and C, and Processor B handles merchants D, E, and F, then the Processors will have completely disjoint sets of data to work with.  In general most Merchants use a single Processor; some load-balance across multiple Processors for redundancy and availability, but most transactions will only be seen by one Processor.

Processors do a lot of data analysis to provide value-add, but not to the extent of providing individual cardholder details across Merchants.  Most such data analysis is done on large, anonymous buckets, but others, like householding, require identifying factors be used in the analysis.

Processors, Card Brands, and Banks can also make loose inferences about what you're buying based on the Merchant Category Code (MCC).  These aren't very exact - those salted peanuts from the Exxon station might get classified as "Gas" - but they provide some guidance.  These are the codes that Corporate-issued credit cards will use to block non-work transactions.

Finally, cards themselves are informative.  Merchants can tell the difference between a prepaid card and a Black Card, and they can treat the cardholder differently in accordance with their status, for example extending discounts to higher-value-card holders.  This is true not only in a physical store, where the Merchant sees your card; Processors can provide this sort of metadata to Card-Not-Present Merchants as well.

(The ability to determine the type of card is not unique to Processors; it's based on the BIN (the first 6 digits of the card) and you can look it up with freely available tools like binlist.net.  However, since the list changes over time, and since it's only a portion of guidance, this is a service most usefully provided by a Processor.  For example, anyone can tell if a card is a Black Card - but as a Merchant you might treat a Black Card with a high chargeback rate differently than the rest.  Only the Processor can integrate that guidance.)


Finding out what headers are visible I would like to find an easy way to find out what headers are visible on my websites. For example PHP version, server etc.

I've looked around and can't seem to find a good explanation on the subject for a novice like myself. So what's the easiest way to get all the headers a hacker could use against me? Would prefer to see it in the browser without downloading an external program for this, but it seems necessary from what I've seen sofar.

Could anyone point me in the right direction?

You're probably using one of the possible tools right now.  Both Firefox and Chrome have developer tools that allow you to see both the request and response headers for any request that is made.

In Firefox go to Tools -> Web Developer -> Network and then make a new request by clicking on a link or refreshing the page.

In Chrome, go to the menu -> Tools -> Developer Tools and choose the Network tab and then make a new request by clicking on a link or refreshing the page.

To see the headers for a request in either browser, just click on the request in the list in the developer tools.


One Time Password Algorithm for Humans Is there a one time password generation algorithm (based on predefined secret and a changing value/time/counter/etc) that is simple enough that it can be processed by an average human but safe enough that the secret cannot be found with just a few passwords (say 5-10)?

I have seen questions on various specific password schemes and how secure they are. But I'd like to know more generally whether some well-know algorithms exist.

Intuition tells me, that if something is easy enough to be processed by a human, then its also easy to break. But then again I was very surprised that asymmetric encryption is possible, or secure key exchange (DH). So, surprise me!

Edit: Some clarification.

The question came up when I was pondering about two-factor authentication for outdoor use. A typical two-factor authentication for safe environments (home, office, ...) uses a password and an OTP generator in a device or on your phone. You loose the device/phone, there's still the password. A keylogger steals your password, there's still the device/phone.

But what about situations where both could be stolen? For example, you use an app to pick up an e-bike on the street or to open a locker in a train station. Someone might watch while you enter the password on your phone and later also steal the phone itself.

The problem could be solved by using passwords that become useless within a short time frame (eg. 10min). In addition the phone would have an individual secret (e.g. SSL client certificate) to make brute-force attacks against the password authentication harder.

mr.spuratic's suggestion around Blum's HCMU algorithm is pretty close to what I was looking for. It still looks a little too heavy weight for the average human, but with some practicing it would be feasible.

There are some commercial schemes, e.g. GridGuard from SyferLock that claim to do this, but I have never used them (I have no affiliation). This relies on the user choosing correctly from multiple options during authentication rather than a typical time or counter based OTP (which means no mental arithmetic).

Solitaire (Schneier), is often cited for a human-computable cryptosystem, it would need some adaption for authentication purposes though. A challenge-response authentication with shared key would be practical, but does not fulfill your description of the OTP.

What should work (with the usual caveat) would be an implementation of TOTP (RFC6238) or HOTP (RFC4226), using an alternate HMAC hash such as Blum's HCMU (Human Computable Machine Unbreakable, description here) mentally computable hash (see also the more generalised OCRA (RFC6287).

TOTP/HOTP are basically the (truncated) output of a HMAC using SHA-1, the input being a shared secret and timestamp or counter. You would need to use a strictly alphabetic representation of the input though, as Blum's algorithm applies only to alphabetic input.

Blum also co-authored a paper Towards Human Computable passwords (on ArXiv), though large parts of it are heavily mathematical. It doesn't briefly covers OTP in §7.2.

See also:

https://crypto.stackexchange.com/questions/9787/are-there-cryptographic-hash-functions-that-can-be-computed-using-only-paper-and
https://crypto.stackexchange.com/questions/844/is-there-a-secure-cryptosystem-that-can-be-performed-mentally


Static code analysis strategies Imagine: We have been given the source code of several software programs, some open source, others proprietary. What's the best strategy to analyze the source code in each case?

For example: We know that open source software is usually more reliable than commercial software. So I'm wondering if it's a good idea to, instead of inspecting the open source code line by line, download the original code from the web, and compare it with the code that's been given to us. If there's no difference, we conclude that the source code is probably safe and we can skip manual code inspection.

Is this practice acceptable? Are there other strategies that can speed up source code analysis?

I'm assuming here that what you want to do is perform static analysis for the purpose of identifying security issues in the code bases you've been provided?

If that's the case there's a number of approaches you can take.  Assuming that the people who are doing the reviews are not skilled application security analysts, you're going to need to rely on tools for a lot of the work, although beware the tools in this fields are seldom (if ever) point and click affairs.

Depending on the language you may find the vendor has some tools that can be used (e.g. FXCop)

Then there are open source tools like flawfinder and RATS

Lastly there are a number of commercial solutions like Checkmarx and Fortify and if you want a managed solution Veracode

Exactly how you go about it will depend on your budget (hint, the commercial tools aren't cheap), the skills you have available and the amount of time for the reviews.


Would this approach allow secure, typo-forgiving password handling? Years back I voiced an opinion that making password handling forgiving, by accepting perhaps a single wrong character, would cost entropy but would not be leaving the barn door open; an additional entropic character or two should (I thought) be enough to offset loss of entropy by accepting near-misses.

I also said that I didn't see any way that wouldn't bear killer implementation issues; a fuzzy match to a stored plaintext password would scream "STORED PLAINTEXT PASSWORD" to security professionals and sink like a rock.

However, what if multiple trapdoor-encrypted passwords were stored: the "real" password, and all the variants that meet an error tolerance standard intended to foresee most "near-miss" typos. Such a criterion might hold tightly to near-miss requirements and only tolerate one near-miss rather than two, but while it would entail a different schema, it would be possible to have multiple passwords (the original as typed and slightly forgiving variants) without the unnerving insecurity of storing plaintext passwords.

What are the security liabilities of this approach above loss of entropy by having maybe a couple of orders of magnitude more strings that would be accepted? If an attacker has a hundred encrypted passwords that are all typo variations on one single password, is cracking one password potentially easier than a hundred completely unrelated encrypted passwords?

From a User Experience perspective, I imagine there are some UX types who would drool over, if you have to type a password rather than e.g. Facebook OAuth, showing tolerance to the most common typos in entering passwords.

One method that could be used would be to generate "acceptable typos" upon initial password entry, then to store the hashes of all of these. There are some problems with this: you increase the time required for a password change and for password verification, especially if you're using a slow password hashing method, as usually recommended, and you increase the storage requirements by a potentially variable amount.

Assume that the password used is "Password1!", and that "acceptable typos" are the case of individual letters (or the presence of appropriate characters from pressing Shift and a number), the swapping of adjacent characters, and missing a single instance of a duplicated character (these are not the only possible typos, but from my typos, they're pretty easy to do!).

That means that all of the following would be acceptable:

Password1!
aPssword1!
Psasword1!
Password1! [transposing "s" and "s"]
Paswsord1!
Passowrd1!
Passwrod1!
Passwodr1!
Passwor1d!
Password!1
password1!
PAssword1!
PaSsword1!
PasSword1!
PassWord1!
PasswOrd1!
PasswoRd1!
PassworD1!
Password!!
Password11
Pasword1!

Given any reasonable password algorithm (or MD5), these will all have unrelated hashes:

2b4ae288a819f2bcf8e290332c838148
c435f7c0de60f0f69bce9f9a671e748a
8aed93fca5d9b2416c51fee36b03bc6b
9fbad358027d70c0db81fc23ab483c3c
dbf220c136f6b1f27c30997090da4697
c36fc47e48c2a52e450cd06f60bbd3bf

To verify a password in this case, you hash the input, and check all the possible values. You can even salt the input on an account level, and you only have to calculate one hash. There is a flaw though.

Knowing all of these hashes doesn't actually help an attacker directly, but they can apply the same rules as you did to any password list they have, and should any of the hashes match, they get access to the account - this applies if you use an account specific salt too. The trade-off for login speed helps them too.

Luckily, it's quite easy to defend against that, with a hash specific salt. If you use most implementations of bcrypt, you get this for free:

Password1!:$2a$04$GgLXwKnxLmnLV/UUtbYahuT9L8R.8/SoKAnRKZUyCuEEgfrX5ITLm
password1!:$2a$04$5Ol8psikd7h0Gt/ZWtQAve0PdA/LO4oub/0JMGC5AA/Rsup/3SBbG

Now they have to try all of the modifications against each stored hash. Depending on how you store your passwords, they might be able to optimise which variations they try against each hash, but since they don't know whether the correct password is "Password1!" or "pAssword1!", there is a risk of missing things if they do. However, when someone wants to log in, you need to do the same.

This is the trade-off - if you use a hashing method which takes 100ms to calculate, and need to calculate 1 value, it'll take 100ms to check. If you need to check 10 versions, it'll take 1s of processing time. If you do the checks one by one, you get a timing issue - fast responses mean the original password has been found, slower ones mean it has a typo. If you do them in parallel, you've increased the computing requirements for your system.

Using just the above list of "acceptable typos", you get a variable number of potential passwords. For "Password1!", that means you're storing 21 hashes, one of which happens to be a duplicate of the original password. If you require constant time output when logging into your system (this is a good thing), you either need to be able to calculate all these hashes in a given time, or to delay every login to the time it would take to calculate all the hashes for the longest password you support. If you don't, you've made a password length oracle.

There are hashing methods which allow for similar input to result in similar hashes, but these don't tend to have desirable properties for hashing passwords. They are generally optimised for finding similar parts of large data structures, so are high speed, meaning that large numbers of potential passwords can be tried quickly. They, by definition, don't have an avalanche effect, meaning that a potential attack could try common passwords, then pick the "closest" hash to the ones found for additional mutations. If an output hash from a mutation is "closer" to the stored ones, the input is also closer. With a cryptographic hash, even a fast one, changing a single character in the input is expected to change most of the output. There isn't a concept of "closer" in terms of output, so an attacker can't do better than random changes, hoping to get a match.

If you avoid the hashing issue completely, and go down the HSM route, it might be feasible to have a HSM which stores plain text passwords in an unrecoverable way, and which could produce responses of "original", "typo" and "no" using classical comparison methods. This might be acceptable if you allowed some actions to logged in users, but then required the correct password to be provided for high risk operations (e.g. changing the password), but it's not likely to be cost effective for most providers.

It's certainly possible, but there are a lot of potential issues with doing it, and it's unclear whether the UX benefits would justify the effort. It would probably be a lot easier to encourage the use of password manager applications, since they'll avoid the risk of typos in a lot of cases!


Is VM escape has the same severity as me getting in a car crash? I'm exploring the threats for VDIs on VMware, based on the article it seems the risk for VM escape has low severity as described here:http://vmescape.com/index.html

  Did we forget the discussion of "Risk Management"? Is there a risk? Of course. There is also a risk of getting in a car crash as you drive to work. But you still do, right? Because the risk is very, very small. And I would argue that the risk of a true "take over the hypervisor" level VM Escape is FAR smaller than your getting in a crash on the drive to work.

I also wish to understand the severity of VM escape.

Depends on your threat model

VM escape vulnerabilities are, in general, rare compared to other classes of vulnerabilities - there are less such vulnerabilities found each year than e.g. critical vulnerabilities in mainstream operating systems or their bundled components. Assuming that there currently aren't any known unfixed vulnerabilities for VMWare, and that you have the latest VMWare version (which is a reasonable assumption most of the time) this means that you're only vulnerable to attack by an attacker exploiting an as-of-yet unknown zero-day vulnerability. In general, this is expensive - such a zero-day vulnerability can be bought or sold for something in the ballpark of $100 000 so you should expect that this amount of resources would not get "wasted" on a low value target.

So the question is whether it's plausible that someone would spend $100 000 to attack you - most people are low value targets, and in this case there's no "economy of scale" where it would make sense for an attacker to attack lots of random computers (e.g. for ransomware or spam) as most such targets wouldn't have VMs and there's little additional benefit; something like Cryptolocker would bring only marginally more revenue to the attacker if it also included a VM escape exploit.

If you consider that your attackers are likely to spend a substantial amount of resources to target your systems specifically, and your systems can be targeted by a VM escape exploit, then you should consider VM escapes as likely, and not otherwise. It's also worth noting that in order to do a VM escape, the attacker generally needs to gain code execution. So if you are intentionally running attacker-provided code (e.g. as an antivirus company or running code tests for anonymous third parties) then the risk becomes much higher than simply running virtualized servers.

Iccording to SANS criteria, that's not low severity but medium severity - "Vulnerability requires significant resources to exploit, with significant potential for loss".


Self Signed Certificate in Certificate of Chain I setup an internal Root CA with another Intermediate CA, which will issue and sign the certificates for other internal servers.

When I did the "openssl s_client -connect :443"
it shows the error message that "Self Signed Certificate is in the Certificate of Chain".

I believe this could be due to the Root CA is self signed, as Root CA self signed its own issued certificate. And the certificate of Chain contains the concatenate of the Root and Intermediate CA certificate.

If I remove the Root CA certificate from the certificate chain file, it shows another error "unable to get local issuer certificate".

I did a "openssl verify -CAfile  ", it shows ok.

I tested with a client PC to access the server with the cert installed, but only able to connect using normal port 80 but not the SSL/TLS port 443 (The site can't be reached).

I am not sure what did I miss out? and how do I troublesome?
Any advice?

The first error was because s_client doesn't like to see the root CA in sent in the TLS connection. The second error is because s_client doesn't trust the root CA.

To solve this second error, run s_client with the -CAfile option and specify the root CA.


The proper way to validate user inputs I am currently building an multiplayer application game on Android, and the server-side logic is deployed using Cloud Functions, which is a server-less environment. The application logic is as follows: two users are given a question (i.e. the same one) and they both try to answer it. When one user answers the question, we check whether their answer is correct or not in server-side. This is where I am confused. Suppose that the user's answer is incorrect. The server will come to this conclusion and send back data to the client-side to notify the user that their answer is incorrect. Suppose that the client-code is as follows:

boolean is_correct_answer = getServerResponse();

In our example, the getServerResponse() will return false in this case (i.e. since the user's answer was incorrect). From what I understand, the client-side code can be manipulated, and so the value of is_correct_answer can be set to true by some hacker. Therefore, the server side validation wasn't useful at all in our example. My question, then, is: what is the proper way of validating user's answers and subsequently notifying them whether their answer was correct or not?

is_correct_answer should be a public static final boolean member of an instance of a Class; something like a Question class, as opposed to a variable that gets reassigned a value more than once.

Beyond that, If this is a native Android (non-webview) application, it appears to be quite involved and difficult to alter client-side runtime values, where a user would have to alter the value stored at that memory address.

I came across some interesting approaches, attack surfaces, and more that you may want to consider at https://hackerbot.net/mobile/android


What are the problems with creating an own CA for intranet? In the comments to Creating my own CA for an intranet several people strongly advise against creating your own CA for an intranet.

Especially:

  don't do it. Nope. Bad idea. Buy $10 CA signed certificates instead. Don't be your own CA. No. Nope. Bad idea —  KristoferA

But also:

  echo "Abandon all hope, ye who enter here." —  Tom Leek

Why should one put more trust in an arbitrary CA that sells certificates for $10 than in the company's own IT department?

(I'm even inclined to trust certificates signed by suppliers or clients1, 2 more than I would trust certificates signed by the common root CA's.)

Is keeping the CA server secure the problem?
Is distributing and installing root certificates the problem?
Is the RA and/or the distribution of up to date CRLs the problem?
Is restricting who or what receives a certificate and who or what signs a certificate a problem?
Any other problems?  (Perhaps my limited knowledge, and the limited knowledge of other IT professionals in general, about all essential aspects for a secure CA.  Are why KristoferA, Tom Leek, and others strongly advise against «homebrew» CA's.

Probably a professional CA will have more expertise in the first three areas and they could do better than any «smug» who creates his own CA.
But still the factor of trust comes to mind especially for the last part.

1.) Given that my company has a longterm relation with these suppliers and clients.

2.) Restricted to certificates about their own servers and employees.

There is nothing at all wrong with running your own internal certificate authority; the vast majority of large companies that I have interacted with have their own internal CA.

Advantages

The nominal cost of a cert becomes nearly zero when amortized over enough systems and users; when you purchase certificates from an external CA, this will never become the case.
It can be a lot easier to manage certificate expiration and renewal, since you can assign ownership to an internal group, instead of a single user who requested it.
You can do all sorts of neat things that are very difficult or expensive to do with external CAs, such as creating wildcard certs for subdomains, like *.test.company.com, or creating weird invalid certs for testing purposes (SHA-1 2017, 512-bit RSA, etc.)

Disadvantages

Running a CA is really hard.  For your own internal CA, you obviously don't need to have quite the level of security controls of a real CA, but it's still quite complex.
The people who are capable of creating and running a CA are certainly not cheap; in the US at least, you can expect that people with strong knowledge of cryptography and/or PKI will be making six figures.
It's not just enough to have a CA, you also need to build systems around them.  Websites/APIs for requesting certs and handling revocations, notification systems for certificate renewal, installation packages to push out root certificates, etc.  You could buy a software package that manages a lot of this for you, but that's certainly not free either.

For sufficiently large companies, there becomes a tipping point where the cost of purchasing all these external certificates and the loss of flexibility entailed therein becomes a significant enough issue to create your own CA.

Otherwise, I agree with those who warned you against it: for the vast majority of small to middle-size companies, it's simply not economical to run their own CA; it makes far more sense to simply deal with a company that specializes in the matter.  Even a thousand certs at $10 a year is a steal when compared to the cost of setting up a well-run internal CA.

Summary

It's not about trust, it's about cost.


Exporting data beyond a cryptographic boundary Scenario

We're working on putting a FIPS 140-2 compliant SQL database on a dedicated machine behind the internal firewall of an organization, and need the capacity to push a specific document or record to an external organization in an ad hoc manner. EG: notify "Zap Labs" that a specific file is awaiting download, then "Zap Labs" can authenticate and retrieve it.

The Problem:

I have very little experience, but pretty solid theoretical understanding. It has to operate on Windows Server, but I can prototype it using OS software on Linux or BSD to get a feel for what needs doing and work from there - I'm trying to understand more right now than implement.

The Question:

What's a good resource on installing and configuring an authenticated login over HTTP? I know there are some serious issues with web app vulnerabilities that need to be considered and I am not familiar with them. Also I figure confidentiality will be ensured via HTTPS(SSL), but I have literally zero experience with how I might actually set that up.

Also, how should I manage the connection between the database and the DMZ web server? I can think of a couple ways this could be done, but none of them seem secure.

Thanks.

As armb said, FIPS 140-2 is used for certifying cryptographic modules. A database is not a crypto module but a database may perhaps may make use of a FIPS140-2 module. This does not mean the database is certified.

There are a number of ways to send a document from the database to a different security environment. The main risks you are trying to mitigate against is you don't want anyone else to be able to see the document and you want to prove it came from you and not someone else to the entity that revives it.  The best way to do this is to sign and encrypt the data.

You could do this in a number of ways, its a fairly open question:

send it over a trusted bearer, eg a dedicated link or a USB stick by a person who is trusted.
Over a secure channel that provides the signing and encrypting, eg SSL using mutual certificates or a VPN.
Signing and encrypting the actual data to be sent and then send it over an untrusted bearer, eg the internet.

You can make all these different options as manual or as automated as you want. If its automated, you should probably have some controls to make sure your not accidentally releasing data you don't intend.

I hope this helps.


How to use my WiFi to inspect its user traffic and to run MiTM attacks? As part of a security research, I need to make my WiFi open, and to inspect the traffic of the ones who connect to it.
Additionally, I need to be able to change the content of the webpages they see, and generally to act as a man in the middle.

Do you know relevant tools or tools that already do this?
Can someone give me some guidelines and relevant references?
Which technical problems I might face during the development process?
Which platforms/languages are recommended for such a project?

I'd like to suggest Ettercap, a free and open-source network security tool for man-in-the-middle attacks.

I recently used its ARP spoofing functionality in an Ethical Hacking / Penetration Testing training, and was amazed how easy it is to set up.

It's included in the Kali Linux distribution.