Try to use Makros at: Options -> Sessions -> Session Handling -> Add -> Rule Actions
and enable the Sequencer at the Scope Tab within the Session handling rule editor.
Looks like you have to define Makros to "visit the Link" aka call the
URL the link points to with the given Token. Look around the Sessions-Tab
for the appropiate way to accomplish the task.


A broad statement such as "this is impossible" is unlikely to be 100% accurate.

It is true that Java (and similar languages such as C#/.NET) runs with a JIT compiler that will produce the actual opcodes only at runtime, so the sequence of opcodes is harder to predict; it may also change with the VM implementation version. Moreover, the language has an efficient GC that promotes dynamic memory usage, and in particular immutable strings, which offer a lot of data-dependent timing behaviours.

It is still possible to write code that is immune to timing attacks, in particular for cryptographic algorithms. You just have to shun some of the nice properties of Java, and use it as if it was some kind of watered-down C. Work on arrays of byte or char, use arithmetic rather than tests... (so don't use boolean). For instance, this timing-immune code compares x and y, and swaps them if x is greater than y:

int cc = (y - x) >> 31;
int tmpx = (cc & x) | (~cc & y);
int tmpy = (~cc & x) | (cc & y);
x = tmpy;
y = tmpx;

We may note that Java makes such code actually somewhat easier to write than C since, contrary to C, it offers standard, fixed behaviour when right-shifting a negative value.


Convert the Owasp Zap certificate
from .cer to .der using openssl or using web service for change the format (https://www.sslshopper.com/ssl-converter.html) and follow the same process that do you see in (https://blog.ropnop.com/configuring-burp-suite-with-android-nougat/)


The answer to your question

If you know two of the four words and the position of said words, it should be an easy* task. Write a script that generates passwords depending on your source list and your two known passwords like $known_pw_1 $known_pw_2 $test_pw_1 $_test_pw2 (of course depending on the position of your known passwords). For each word you put in $test_pw_1 you need to iterate through all $test_pw_2.

There's also a good StackOverflow answer on how to input passwords into command line prompts.

*depending on the following The "BUT"

The "BUT"

So here's the BUT that will take all the fun out of your programming exercise above:

Depending on the word list you used and the alphabet (UPPER case, lower case or MiXeD?), you'll have a hard time calculating through all possible combinations. So if you're using the original diceware word list, it has 7.776 words in it. Meaning your initial password list with two variables has 7.776^2 (=60.466.176) possible combinations. If you have lower case and upper case words mixed, that expands to 7.776^4 (=3.656.158.400.000.000) combinations.

So if you calculate 1-3 passwords per second (I haven't checked the filevault specs but I highly anticipate that it will most certainly slow decryption down to prevent such brute force attacks) you're still looking at around 700 DAYS when calculating all 7.776^2 combinations, 4 BILLION YEARS if we're talking about 7.776^4. And we haven't even talked about mixed character words.

(my math might be off here, please somebody correct)

PS: Hashcat apparently does ~61.481 H/s


It's PowerShell Invoke-Expression

The meaning of `download cradle' comes from Raphael Mudge's talk on Flying a Cylon Raider where he describes how to continuously stage external PowerShell scripts from a launcher. In his techniques, which largely describe the use of ReflectivePick (popularized via PowerShellEmpire's psinject) from the original UnmanagedPowerShell work, a .NET runspace instance provides an execution context for the PowerShell pipeline.


Is AES feasible for secure hashing files?

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.


Setup a private VPN for family in China?

Note that my information may be outdated, as the last time I really dug into this subject was in 2013 - 3 years ago. I lived there, and experienced all the inns and outs of VPNs and Proxies.

The love-hate affair with VPNs in China

  I have family in China. During the past weeks their internet connection was severely limited. VPNs such as Astrill and similar weren't working anymore.

Yeah, this happens during a lot of interesting events, and certain times of the year. The Internet becomes heavily restricted, and most of the VPNs keep getting blocked.

Shortly thereafter, the VPNs are generally unblocked because the ruling party members are using them too. ;) It's mostly just for show. However, they'll sometimes ban entire lists... so it's often a game of cat and mouse.

Homebrew Solutions may not be the best course of action

  Is it possible to setup my own VPN (or alternative), either on AWS or at home, in a way that would be more efficient for them than Astrill?

Yes, and this can work, but! It's highly suspicious. And if you're using your own home proxy as a VPN, you'll eventually be banned from connecting to Chinese websites and communication protocols. Do you want to lose contact? Because this is how you lose contact.

Chinese authorities are notoriously paranoid, and think that any kind of communication with foreign entities denotes espionage, especially if you are in any way connected to individuals listed in the data stolen from the OPM breach, and especially if the people you're talking to have appropriate guanxi (关系： "connections," "relationships", etc).

You will not pass under the radar.  In most cases, you will only connect to VPNs which are allowed to be connected to. In fact, this will put your family in China under suspicion. "climbing the wall" （翻墙） is not something you want to create a homebrew solution to, as it's suspicious. It's better to get lost in the noise.

PPTP vs. OpenVPN in China

  If VPNs all get blocked by some machine-learning chinese wizardry, what about a more custom solution like payload hidden in pictures? (steganography)

It's more like this: if you utilize standard VPN protocols which begin their connections in a standardized way, it will be blocked due to DPI. OpenVPN for example, did not work for me, but PPTP did.

Unfortunately, PPTP with MS-CHAPv2 is quite insecure, and easy to decrypt. PPTP is also vulnerable to man-in-the-middle attacks. Part of the reason why it works is because they're able to redirect traffic.

If you're trying to discuss anything sensitive, do not use PPTP. Do not use anything, actually. There are a lot of reasons for this, but it's beyond the scope of this answer.

Recommended VPNs

  My thinking is that if I do it for a few people it would pass under the radar. What would you recommend?

Now here's where our, "questions seeking product recommendations are off-topic as they become obsolete quickly", rule really comes into play: VPNs are extremely volatile in China. One day they're banned, another day they're not. Some times, entire VPN companies become completely inaccessible, and sometimes you need to contact support to get updates, if you're lucky enough to find some way of contacting them.

And even if this was on topic, it's best not to tell you at all. Why? Because the CCP trawls the internet for VPN companies, signing up for them, and downloading the product's entire IP range, and then blocking them.

For things that do work, telling you assists "them" in helping to block more hosts, degrading the experience for everyone else. Find it yourself. Chances are, if you find something that is working, they're using it too. :-p


Is it dangerous to serve executable cgi files in public folder?

In short, separating CGI files, which are often scripts, makes it easier to ensure that the web server will never mistakenly return the text of the script to the client instead of executing the CGI and returning the results.  If the script "source code" is revealed to the client, it may expose sensitive information, such as embedded database connection passwords or just information about how the script executes that could be abused by an attacker.

For example, the entire /cgi-bin directory is usually configured to execute files and never to return content.  If you edit hello.cgi and leave an editor backup file hello.cgi~ behind, the server should never return that file as content if /cgi-bin is configured correctly.  On the other hand, if that backup file is sitting in a normal web root that serves files, then the magic mapping of ".cgi -> execute" won't take effect for the hello.cgi~ file, and the server may therefore return the content of hello.cgi~ instead of executing it.


Is it okay for websites to send passwords as plain text if they hash them when they are stored?

The site probably (hopefully) uses TLS via HTTPS to encrypt the traffic between your browser and the webserver. Even with encryption, the browser displays the network traffic in cleartext since it has (obviously) acces to the traffic before it is encrypted and after it is decrypted.

You can find out more about the use of encryption by looking at your URL bar and looking out for a green padlock (in most browsers).

Encrypting the credentials via HTTPS and storing the password hashed (plus points for salt & pepper) with modern hashing algorithms is seen as reasonable secure. Nevertheless, there are more and more evolving techniques for authentication. Hashing the password on the client side and saving this hash as it is is a bad idea (described in Client side password hashing).

EDIT: I've just seen the comments, weren't there when I was writing this, sorry for duplicating.


How to find out Protocol used for web communcation (SSL vs TLS)?

In Chrome:

Press F12, then select "Security" at the top. Then on the left select the site. See screenshot.

In Firefox:

Select the information/security icon on the address bar, and follow the screenshots:


Why are no CD crakcs required to run games without a physical disc?

Games that shipped on physical disks often checked to make sure the disk was in the CD-ROM Drive before allowing you to play. It was a simple and somewhat effective way to ensure the average consumer didn't pass the CD around to all their friends and still keep playing the game.

This was also done with Floppy Disks, and sometimes asking the user to enter the first word from a specific page in the accompanying player's manual.

The crack you mentioned was often done by someone looking to pirate the software. They'd modify the game's executable to jump over the code that made the CD check. If a studio later wanted to remove the check, but not redistribute the entire game with the art assets and everything, they could do the same.


Can anyone explain how to use an X509 client certificate to securely authenticate a user?

How would I make use of the certificate in a web application, username and password login form to provide secure authentication?

The point would be not to have such a form at all. You would use HTTPS. The server TLS configuration would require a client certificate (which is optional). In response to that option in the TLS connection setup, the client (web browser) would typically prompt the user to select an acceptable certificate from those he has available; you would of course have had to get the user his private key and matching certificate beforehand. The server would need the necessary CA certificates to verify the client's certificate. Once the TLS connection completes, the web server would make the authenticated client identifier available to the application in some form (e.g. environment variables with Apache mod_ssl); at least, the X.500 "distinguished name" which is the subject of the certificate.


Remote host identification has changed - How do I know if it's an attack or not?

You did the right thing, don't connect if you don't know what happened, that is exactly what the warning is for. This message would absolutely appear if an attack was taking place. If it wasn't it could also appear if something else has changed.

You need to investigate what caused the change before drawing a conclusion.

If you can login in an alternative way (i.e. via cpanel?) check the SSH daemon configuration for the keys it is using [/etc/ssh/ssh_host_*], the configuration could have changed and the order of the host keys presented could have changed, thus showing a different one, check the date of change of host key files, try to find the fingerprint of the stored key files and compare to the value you have, etc.  Has the IP address changed since you last connected?

Try to connect to the host using a completely different network (e.g. tethered to a smartphone as opposed to using the local wifi?), see if the same happens.


Automatic detection of a compromised web server

There are a number of local processes that will watch files and directories for any changes, writes, deletions, and accesses. When these events occur, the process creates an event log through syslog. This can happen in a second.

If the syslog entries are sent to a remote server (as they should be) you will have nearly instant alerting to file changes, without the possibility of "fooling" anything, without any "unnecessary" web traffic.

There are pre-packaged software to do this, or it can also be done using custom scripts (pre-packaged, tested software tends to be better).


Is it a good idea to deprecate support for some insecure clients on a website?

In your particular case, dropping the support seems like a good idea.
Every new service you provide, adds a potential attack vector. Apart from that you increase the maintenance cost of your product. Adding a completely new support mechanism for less than 0.01% users doesn't seem like a good idea to me unless they are significantly important users (say have a 10% share in your income or something).

However, you can have a safe website which uses HTTP (Stack exchange doesn't use HTTPS). In a general scenario, I would say the decision is more related to economics and maintenance issues rather than technical issues.

How badly do you want a A rating?
Do those customers generate enough revenue to balance the maintenance cost of non-HTTPS servers?


Is there any danger to downloading a malware binary, but not executing it?

Malware sitting quiescently on your system is not a danger in the sense that it can spontaneously do something. The risk is more along the lines of, "Don't Push The RED Button!"

The fact that it's there is an opportunity for mistakes. It could be a manual mistake of you inadvertently running it, or another program (like a Virus Scanner) finding it and taking some undesired action like auto reporting to superiors or technical response teams.

Malware can be handled safely but it needs to be handled carefully. Assume that it may be accidentally run and consider your response recovery. Purge the VM or hope you can eradicate it from your main system.


Is \ converted to \\? If not, break out of the string using \"; it'll be converted to \\", which will be treated as a sole (escaped) backslash and then a string-terminating quotation mark.

Inserting a newline will break the string, but also break the JS application. If you don't have some way to recover from that - such as the ability to insert a new script block on the same page - that's probably acceptable, but you already said that closing the script tag (presumably to then open a new one) doesn't work.


The main difference between IP and ARP spoofing

IP spoofing is filling in the IP address field on a packet with an address that isn't the sender's IP address. This means you can't receive responses to that packet, so it isn't particularly useful, but it can be used as part of an exploit in order to make it harder to trace, or to make it look like the packet came from another source in order to bypass IP based authentication measures (obviously only if the exploit doesn't require a response from the server). Another use is when carrying out DDOS attacks - here you don't care where the response is sent as long as the server handles the request.

An ARP spoofing attack involves transmitting faked ARP packets. The Address Resolution Protocol is used for translating network addresses (IP addresses) into link layer addresses (MAC addresses).

What normally happens is, a computer sends out an ARP request to every device on the network, asking for the MAC address corresponding to a given IP. The device that currently has that IP address then sends an ARP response back to the computer that originally made that request, containing it's MAC address.

In an ARP spoofing attack, you send a fake ARP response with your MAC address, before the intended recipient can respond. Now the computer that made the request thinks that that IP address belongs to you, and it will send all traffic that was intended for that recipient on to you instead.

You can then forward the traffic back on to the original recipient - you don't have to do this, but it allows you to intercept the connection without either device being aware. If the device that you have ARP hijacked is the gateway, you can now intercept (and tamper with) all internet traffic on the network (provided it isn't encrypted


You probably need to block things that might be harmful while still allowing people to get their jobs done.

Instead of trying to call out specific devices, consider blocking or approving USB devices by class types.  For example, you might approve all HID devices (class 03) and Audio (class 01), which might be required by people with special needs (custom mouse pointing hardware, keyboards, hearing aids, etc.)  Similarly you might block all Mass Storage (class 08) and Networking (class 02) devices so that hackers can't perform malicious acts.


My friend revealed both private and public keys for his server. How serious is this?

I suppose that these files are for "his SSH key" as a client.

Revealing the public key (id_rsa.pub) has no consequence: when we call it a public key we mean it. The private key (id_rsa) is of course the problem.

The way you use, as a client, your private key, is to push the corresponding public key into the server, in the .ssh/authorized_keys of the target account. When the public key is in this file, then whoever knows the private key may log into the server under that name. That's how the public/private keys work on the client side in SSH.

So there are basically three possible, rational reasons that would allow your friend to disregard the disclosure of his id_rsa file:

Maybe he never pushed the public key anywhere. When he logs into a server, he does it by typing his account password for that server, always. If his key pair is never used, then revealing the private key is harmless. But then, why would he have such a key pair?
Possibly, all the servers he connects to, with private key authentication, are located on a private network, with only non-hostile users, and strong isolation from the outside world.
It is conceivable that the private key is protected by a password (or "passphrase" in SSH terminology), which means that it really is encrypted with a key derived from the password; and your friend has great trust in the strength of his password.

Note that even if the private key is unprotected (or protected with a guessable password) and grants access to some servers reachable by attackers, then what the attackers can do is log in to these servers in the name of your friend (which is already a big problem). This does NOT grant to attackers the power to do a Man-in-the-Middle attack (MitM is double-impersonation, so a MitM attacker must know the private keys on both client and server); they cannot either decrypt past or future sessions that they eavesdrop on, or alter data of ongoing sessions (notably, the asymmetric keys in SSH are used for authentication, but the key exchange uses Diffie-Hellman).


Do generic custom scripts avoid detection more than common security applications?

A packet is a packet is a packet. There is no difference no matter how you generate it, be it using a tool like scapy or using a scripting language like Python or Ruby.

What matters is the frequency and contents of the packets you are sending out. For example, a IDS might get suspicious if you are hitting the system with multiple SYN packets on multiple ports, which is what happens if you use the default -sS flag on nmap. What a scripting language will allow you do to is specify exactly how many packets you want to send out how many times. This is a very flexible option that allows you to craft out your scans in a very fine-grained manner to avoid detection.

Of course, a tool like nmap has many options, including but not limited to the --max-rate and --max-retries flags that allow you to tune the scanning frequency. This may or may not be enough depending on the exact situation.


Secure API key mechanism for identification

How can we generate some API key to uniquely identify the developer?

Include a custom claim in the JWT to identify the developer.

{
 "accountType" : "developer",
 "iat" : 1422779638
}

  Can it be jwt access token without expiry?

If you are providing sensitive information through the endpoint, a token without expiry is not a good practice. If it s for a dev environment, you can have long living keys.

  Can anyone explain what should be the standard mechanism for this scenario?

Easiest way this can be handled is as mentioned in the answer to first question. Ideally if the access each user need to have on the API endpoint is different both from operation and data access perspective, strong authorization need to be in place rather than blanket all developer/all user authorization.


Does an end user (or CA) certificate have any "fingerprinting" to indicate the brand of PKI being used?

Not a direct answer, but maybe hints in the right direction
Cert linters
These might be interesting to spot anomalies: There is Peter Bowen's certlint (written in Ruby) and Kurt Roeckx's x509lint. Both of these are integrated into crt.sh. Here are some examples with interesting anomalies: cert for *.gmaptiles.co.kr and example.com
Also there is another certlint: GlobalSign's certlint (written in Go). I haven't tried that.
Pubkey generator identification
Also: There is some research on how to detect the library used to generate RSA pubkeys: From Usenix Sec 2016: The Million-Key Question—Investigating the Origins of RSA Public Keys (Archived here.)


Is the Gmail activity log still missing activesync?

I did some testing, using my windows mobile phone & activesync. The Activity Log, indeed does not log anything, only when just receiving mails. But whenever you do some change that can lead to an update operation, then it logs this attempt.

Say for example I initiate a sync operation and 10 messages are downloaded on my mobile as soon as the activesync finishes - 7 I have already read on my PC and 3 new unread.
This sync operation does not get logged in the Activity Monitor.

If I read one of the already read mails, and then sync, again it is not logged.

But I read one of the unread mails, and thus change its state, the next sync operation is logged (with name "Mobile"). The same happens if I send a mail - the sync gets logged.

So to sum up, a clever attacker that has stolen credentials can read all the emails of a person, without being noticed, by manipulating the active sync queries so no updates are sent, or by changing the state of the mails back to unread after reading them.


Impossible to make connections through closed ports?

DoS attacks don't require any open ports on your side. They can just use all your bandwidth even if the ports are closed.

How?

The IP packet are sent from the attacker, and routed through several routers until it reaches your system. If the port is open, the connection succeeds. If not, your system can send back a "Port closed" message or simply drop the packet.

Either way, the packet has already travelled all the way to your system, clogging all the path along the way.


Does Self-signed certificate differ from CA from a security point of view?

Features

A self-signed certificate is capable of having the same security features (encryption, extended validation, permitted usage) as a certificate issued from a leading issuer such as VeriSign or GeoTrust. These options need to be set when the certificate is created.

Trust

However the purpose and the advantage of Public Key Infrastructure (PKI) (such as Internal Certificate Authority used inside an enterprise, VeriSign/Symantec, GeoTrust, and many more) is that there is an existing trust relationship between the client and the certificate issuer (e.g. VeriSign). The client (people and browser) trusts that the issuer has checked you out and has verified you are who you say you are. Certificate issuers have stringent security practises that they have to maintain. This type of relationship is not replicated with a self-signed certificate.

You can install a self-signed certificate into a browser (needs to be done for each browser) to make it recognise the certificate as trusted.

If you do not do this step the user has no way of knowing the certificate has changed unless they manually inspect the certificate. This could be dangerous because someone could intercept the transmission (man-in-the-middle) and the user would not know the certificate/host was the wrong one.

Summary

When looking at functionality alone, a self-signed certificate offers neither more or less security then one issued from a leading certificate authority.

Websites are for users, and a certificate trust is important so the user knows your website is who it says it is.

My personal opinion is that the trust and ease of deployment gained by using a public issuing authority is very important for a public web site, especially if you don’t have an existing close relationship with the people visiting it.

A self-signed certificate may be suitable for limited internal development / testing.

An internal Certificate Authority for use is a good solution for enterprises who use certificates internally and have an expertise in PKI.

Hope that helps


Then md5 was proven to have collisions so people started moving to SHA1 and so on.

Note that collision resistance is not required for password hashing. Still there is no reason to use a weaker than necessary hash.

  Why can't SHA512 be used in a password algorithm if we iterate it enough to create it slow? Example is to SHA512 the password 100k times.

You can do that. As long as you mix password and salt already at the beginning it should be secure.

We don't recommend that, because there is no reason to invent your own scheme, when there are plenty of standard schemes.

  Why is PBKDF2 or bcrypt recommended instead of doing the above? Or why is it not?

Because they're standardized and have been looked at by many cryptographers. So you can be more confident that there are no weaknesses in the scheme than with your ad-hoc scheme.

PBKDF2 is essentially an iterated hash function, which uses HMAC to mix the password and salt.

bcrypt is a different construction. It's slightly harder to break that PBKDF2, since it requires a bit more memory(a few kB), increasing the number of required gates a bit.

There is also a scheme called scrypt which has a tunable memory parameter, allowing you to have the scheme consume significant amounts of memory(several megabytes or more). This prevents special hardware to be much more efficient than standard hardware, since they still need to buy lots of RAM.
scrypt is probably the strongest of these schemes. But it's relatively new, and uses uncommon primitives, so many users still choose older schemes.

  This answer states that it is "not for hashing a password for safe storage for authentication purposes". However this answer (with many upvotes) recommends the opposite

That question is about an explicit NIST recommendation for PBKDF2 with password hashing. There is only a recommendation to use PBKDF2 for password based key derivation, a closely related technique. The absence of a NIST recommendation does not imply that the scheme is bad.

  If a PBKDF2 function relies on SHA1 underneath, is it inherently insecure if SHA1 can be proven broken?

If there is a first pre-image attack against SHA1, that works under certain constraints, then yes, PBKDF2 with SHA1 is broken. A collision attack on the other hand is not enough. A first pre-image attack is typically much harder than a collision attack. For example we don't even know one against MD5.


Hiding version - valuable or just security by obscurity?

The problem with security by obscurity is when you depend on obscurity to get security. If that's your only or main form of defense, you have a problem.

With that said, obscurity can add security to a system already using better strategies for security. There is no reason to expose that information, so you should not. It's useful information for an attacker, so you should certainly hide it whenever possible. The problem is when you start thinking along the lines of "well I hide this information, so no attacker can find out and use it to attack my system, so I'm safe."

Your system should be secure regardless of whether that information stays secret or not, but you shouldn't do the attackers any favors by releasing it.


Wireshark - How to see the domain of HTTPS websites visited

There are four possible meaning of a server's domain name:

The raw value of the IP address in the IP packet. Check out the Dst value in the IP panel
The result of reverse name lookup on the IP address in the IP packet. Note that a single IP may have multiple domain names attached to it, and some names may not appear in reverse lookup, so this isn't always a reliable way to get the actual domain name used by the user. See: https://osqa-ask.wireshark.org/questions/37680/can-wireshark-automatically-resolve-the-ip-address-into-host-names
The value of the SNI (Server Name Indication) header of the TLS connection. See: https://superuser.com/questions/538130/filter-in-wireshark-for-tlss-server-name-indication-field
If you are able to decrypt the TLS, the Host header of the HTTP request. Note that this value may differ from the domain name in SNI. Use the HTTP panel to see HTTP header values.


what can you do in sql login details and encryption key is available

Some things you can try:

Check for credential re-use. For example, can you log into the SSH server using the DB credentials?
Try to get code execution on the server. Since the web server obviously has access to the database, if you can launch another process with the web server's permissions, you should be able to access the DB from there.
Attempt SQL Injection (SQLi) attacks on the web application, which can be used to get at the contents of the database without ever directly connecting to it yourself.
Port-scan the server to see if the DB is perhaps listening on a non-standard port, or if there's some other vulnerable program listening on another port (a privileged debug service listening on 8080, for example).
Look up what the crypt key is used for (I'm not familiar with this system myself, but I'm sure the info is online) and see if it's anything useful like encrypting/signing authentication tokens (would let you spoof being an arbitrary user). This probably won't give you direct access to the DB, but might let you do something like access an administrator account in the web app and from there you can possibly access more data or find vulnerabilities in new attack surface.


Isn't extracting an encrypted file to disk a bad idea?

If it's useful to decrypt files to a local folder or not depends on your use case

If you use it to provide a secure offline way to transport files from one computer to another it seems perfectly fine to me. The transportation phase is secure, what the receiver does with it is no longer the responsability of the usb disk encryption

If you want to ensure that the files aren't accessible (Without the decryption key) once you have copied them, then you should be copying the files to an encrypted partition (Full disk encryption, a VeraCrypt partition, etc) or use another layer of encryption over the files, like an encrypted 7z file

I never used SecureAccess but I'll be surprised if it doesn't have a feature that doesn't need to decrypt the files on the fly without storing them in a persistent storage


Does Hole Punching put added Vulnerability on the Client Side

The question depends heavily on the software security architecture used but yes there have been cases where the peer to peer software implementation did allow bad actors to access files on the hard-drives of other people participating in the peer to peer network. Likewise some of these designs also allow participants, or ISP's, to identify the files other users are sharing remotely.

This said it doesn't mean these applications are necessarily unsafe some could be very safe but any time you add an application which listens to the Internet (or other systems) you are increasing the attack surface of the computer. This risk is not unique to peer to peer software but peer to peer software is more likely to have listening ports.

Again it really depends on the security models used more than anything.

In general all of the security issues with securing a non peer to peer protocols will apply to peer to peer protocols as well. This just happens to be a many to many set of connections rather than one to one or one to many.

Again, they could be really secure but every implementation will be very different.


This is about defence in depth.

Whilst only the correct app should be the only one with access on a non-rooted phone, there are many examples indeed (especially on Android) of applications capable of breaking out of the standard security model.


You can probably negotiate with your bank to allow you to use night deposit bags for drive storage. Pad it so the drive can cope with shocks from lots of coins. You can arrange so they won't open your bags. During the day, somebody can move the backup disk in a safety deposit box.

That said, with the data encrypted, your current solution isn't necessarily a bad one. You have reasonable controls to prevent loss of the data by means of encryption.


What websites can be protected by a particular SSL certificate?

If you view the certificate in your web browser, you should be able to find the certificate subject alternative name value for the certificate.  This will show a list of all of the sites that can be secured using this certificate, in addition to the site shown in the common name for the certificate.  You may see wildcard values used in some of the names, such as *.hsbc.co.uk or *.security.hsbc.co.uk.

As an example, if you look at the certificate protecting this page, you'll see that Stack Exchange uses one certificate for all their sites:

Firefox :

Chrome :

The site we're currently on, https://security.stackexchange.com is covered by the wildcard SAN *.stackexchange.com.

Bear in mind that in order for any site listed in these fields to use this certificate, the site would need the private key that corresponds to the public key in the certificate.

These conditions must be met in order for your browser to make a SSL/TLS connection to the site, without warnings.


Can my open Firefox Sync session be used to circumvent a Master Password?

According to Firefox Help - Recovering important data from an old profile:
Your passwords are stored in a JSON file that has encrypted entries, the keys are within a sqlite database.

key4.db - This file stores your key database for your passwords.
logins.json - Saved passwords.

So if sync is active and working with a attacker, you are vulnerable to this, luckily the sync service requires a password.
https://support.mozilla.org/en-US/kb/using-master-password-sync

The so-called 'master password' does not protect your passwords, it just blocks someone from grabbing it remotely.


Does visiting cached pages disclose my IP address to site admin?

The cached page still contains references to the original content (images, scripts and style-sheet files, etc.) so, when you look at the default cached page, your browser will request this content to the original website, possibly along with a "referer" header telling explicitely to the website that you are currently viewing the Google cached version of which page.

However Google offers you the alternative to see the "Text-only version" of the cached page. By this way all these tags linking to the original content will be stripped off and your browser will contact only Google servers.

And as per you second question, all your interaction with the text-only version of the cached page will remain local to your browser: you can right-click, select, copy, save or examine the source code of the whole web page or a some elements of them freely.

Foot note: the above statement is true for a "normal" behaving browser and environment. Some browser plugins and antivirus proactively check the links contained on a webpage displayed in the browser without the user having to click on them (use case can range from checking the URL reputation to actually downloading the web page to accelerate navigation). You should know if your system has got such feature installed on it. In case of doubt, a simple test with a network monitoring tool like Wireshark would tell.


How to make a report after a ddos attack? what information do I need to write on the report?

Sorry not to have a good link, but my thought is you want to cover:

What happened?

When did it happen, and for how long did it continue?
Who did it and how?
What was affected - what sites, what servers, how many servers, what part of the business?  What customers?
Root Cause Analysis

What was the impact?

Damage to servers
Damage/exposure of information
Damage to corporate reputation
Damage to human life (crossing fingers that this is a definite no!!!)
Cost of Recovery (Time, Equipment, etc.)

Halting/Preventing

What has been done so far?  Break it down into immediate response vs. ongoing updates
What else should be done?
What is the projection for this happening again?
What about something like this, but not exactly the same?
Are there any changes we could make to future process to prevent/mitigate this type of risk?

Break into past/present/future - what did we do immediate, what are we doing now, what are the big things we should do in the future that will require high level funding?

Future Prognosis

If we do everything in the report what is the likely state of the system to future attacks.  Probably not "bulletproof", so give some assessment of likelihood.
How about if we just leave the system in it's current (partially fixed?) state?


Is it good practice to let Node/Go/... act as a frontend webserver?

Well-tested code helps to reduce the risk, but even PHP keeps issuing patches to remedy security issues.

The problem is not with "newcomers" but with appropriate protections and controls over any type service that you expose. PHP/Apache/etc. behave (and fail) in predictable ways, but we can predict their behaviours because we have experience with them and know how to respond.

Whether you use the oldest, most maintained codebase on the planet, or your own custom-made product of a "hack-a-thon" weekend, you still need to make sure you have all the appropriate protections in place. From that perspective, your admin's "fear" is perfectly rational: add extra protections around that which you do not fully understand, even if that means you end up being heavy-handed. Then, you can tune, refine, and adjust the controls to an appropriate level.

It's your admin's job to protect the server and the infrastructure so that all services can provide value. It's your job (I'm assuming) to provide a valuable service to the stakeholders and customers. You both need to work together so that everyone can be served.


What is the exact meaning of "Keying material"?

What is the exact meaning of “Keying material”?

Keying material is a more general and fancy term for "secret keys of (unspecified) format, length and amount", where the "unspecified" part may be clarified depending on configuration or is just outsourced to other sections of the paper.

It is this general to include things like shared Diffie-Hellman secrets (which are not suitable as symmetric keys), which have more structure than normal keys.
It provides a nice sense of abstraction. For example I might say: You feed your keying material into a KBKDF (like HKDF) and use this as the input to TLS-PSK, without ever having to know how you established that material (DH? ECDH? PSK?)
It allows to not care about the actual format or location of keys (is the key in software, on a card or in a HSM and how is it stored in detail?) as it just tends to be used for "you (but nobody else) have access to this".
It allows to include multiple keys which are needed to access one particular system (e.g. if you'd need two keys to access something you'd just say keying material instead of "key a and b").


Should we bother with cell-level encryption for an ASP.NET/SQL Server web application?

I think the answer to your question pivots on a slightly different perceptual view - which is, where does the decryption take place?

Technologies like TDE function at the database level.  In practical terms, this often means that a DBA - or someone who has compromised appropriate privileges - can access the decrypted data and structure.

Cell-level encryption, on the other hand, may more commonly be implemented at the application layer.  Which means that the DBA will never have the ability to access anything other than an encrypted blob; the key to decrypt it is (should be) sequestered at the application level.  This is valuable because, in both security and compliance worlds, dual control is a powerful ally.  The application engineers can decrypt data, but only if they grab a lot of it from the database, which is usually not subtle.  The database administrators can grab lots of data, usually subtly, but if they can't decrypt it then control is preserved.

When you're thinking about which makes sense, you need to think about the threats you're concerned with.  If you're just worried about cold disks and backup tapes, TDE covers your concern.  If you're worried about the attack vectors into a live functioning application+database pair, TDE makes less sense and you may want to consider more fine-grained controls that separate the decryption capability from the data store.

If you have multiple co-located applications with different encryption keys which enable access to application-specific encrypted blobs on a shared backend, then yes, that may offer you more security... but it has pits you need to think about.  An attacker gaining some control of the app server is the standard worst case scenario.  If they gain access to the app server, can it gather decryption keys from the multiple apps and negate the separation?  You can't really separate apps with encryption keys if they're all on disk, in memory, and executing on the same app server, at least not as a security control.  That's where you'd want other controls, such as separate app servers, to help protect your data.

Please note that I've used weasel words like in practical terms, may more commonly be, should be, and not subtle/subtly.  I'm aware I may not be answering your direct question given the technologies you're listing; I'm recasting the question into a more theoretical bent so that you can try and map your options onto concepts and work back from there.

Good luck!


Why aren't IMSI catchers rendered ineffective by standard MITM defenses?

tl;dr - the protocols were developed prior to MITM being perceived as a threat; the deployed infrastructure now serving billions of cell phones worldwide can't easily be changed to add cell tower validation; and governments have no interest in fixing this issue.

Cell phone protocols differ from IP protocols in that they were never a peer-to-peer network of untrusted devices.  The original cell phones were analog, with only a small channel of digital data to carry call information.  These analog protocols were developed in the 1970s when the micro CPUs had almost no power or storage, and the only security thought was to ensure accurate billing.  Also working in the cellular companies' favor, the only equipment authorized to transmit on those frequencies was under full control of the cellular manufacturers; companies like Motorola had a virtual lock on all the equipment on both ends of the call.  The protocol they created was such that the cell phones implicitly trust the cell towers for all operational information:  signal strength measurements (for optimizing battery life), network IDs (for billing and roaming charges), and encryption requirements (which need to be turned off on a per-jurisdiction basis.)  The phone responds with its ID in order to register to receive incoming call information, and the phone company authenticates the ID to ensure proper billing.  But in all this, the phone never authenticates the tower.

Also, all this metadata is exchanged in cleartext.  When digital cellular protocols like GSM arrived, nothing much had changed in the security model.  In the 1990s, the main security threat was eavesdroppers, so laws were passed in the US prohibiting listening in on cell calls.  Digital voice data was easy to encrypt to protect the privacy of the calls, (supposedly a government agency ensured that weak encryption algorithms were selected.)  Otherwise, the existing cellular protocols continued to work without many security issues (security issues primarily being defined by the cellular companies as "people hacking our systems to make free calls".)

Stingrays and other IMSI-catchers violate the cell tower agreements by producing an illegal signal, pretending to be a cell tower.  They forge a signal strength response of "excellent", which causes the phone to not switch towers.  They identify themselves as various common network IDs, so the phones do not switch away to avoid roaming charges.  They control the encryption flag, which will cause a phone to downgrade security either to the least secure algorithm, or disable encryption completely.  As far as a MITM goes, they may pass along the phone call data to a legitimate tower, or they may simply send back an error code the user sees as a call failure.

Nowhere in the protocol designs was a thought given to malicious actors transmitting on their licensed frequencies.  Illegal use of airwaves has long been a felony, and their original approach was legal:  "if someone even tries to spoof a cell phone, we'll have them arrested and locked up for a decade."

But it turns out that not everyone is afraid of committing a crime, least of all police departments armed with warrants and Stingrays.  Private researchers have also exploited loopholes in the law, where they transmit cell tower signals legally on unlicensed frequencies (the ISM band). This same band happens to be allocated for cell use in foreign countries, so a quad-band phone in the US will happily receive the faked signals.


I don't have any good solutions, but I have a couple of bad ones:

Upgrade to premium to get rid of the adds. But pay to not get malware? Doesn't feel right.
Uninstall it until they fix the mess, then reinstall it and hope they don't mess up again.
Run it on a VM. Just a tiny bit unpractical to have to start a VM just to listen to music...
Harden your browser (update to latest version, uninstall Java and Flash, etc) and hope for the best. Not bulletproof exactly, but better than nothing.
Change your default browser to a program that does absolutely nothing. That way Spotify will not be able to open a browser, but on the other hand no other program using the default browser will either...

As I said, not very good solutions. Perhaps someone else has some better ideas?


Should I consider an Android Wifi sharing network as trusted?

This is a WiFi Access Point, not different from the one you may have at home, at an airport or at a café. It just bridges the GSM data capacities of the phone with its WiFi - allowing you to go from one to another.

This means that it is, from the perspective of your laptop, untrusted - like any other network before you make it trusted (because you own it (your case), know that it is correct, is a company WiFi, etc.).

It is yet another access point to Internet for your device, so you must decide how much trust you put in in (in your case, probably a lot).

From the technical perspective, you should protect this access point so that only entrusted users can access it. This means using WPA2 with a strong passwphrase and an up-to-date Android.


TLS 1.2 and enable only AEAD ciphers suite list

Don't do this.   At least, don't do this on any system where you don't know for sure that it's not going to break things.

AEAD stands for "Authenticated Encryption with Additional Data" meaning there is a built-in message authentication code for integrity checking both the ciphertext and optionally additional authenticated (but unencrypted) data, and the only AEAD cipher suites in TLS are those using the AES-GCM and ChaCha20-Poly1305 algorithms, and they are indeed only supported in TLS 1.2.   This means that if you have any clients trying to connect to this system that don't support either TLS 1.2, or even those that do support TLS 1.2 but not those specific cipher suites (and they're not mandatory...Only TLS_RSA_WITH_AES_128_CBC_SHA is mandatory, and it isn't an AEAD cipher suite) then those clients will not be able to connect at all.

It is true that these are the most secure options, and indeed the only options that will be supported for TLS v1.3, but for most systems today, this is not a realistic configuration.   You do certainly want to enable TLS v1.2 and these cipher suites if you have an option to do so (configuring them is going to be specific to your system, so check your documentation) but as a rule, you should not require them unless you really know what you're doing and understand both your environment and the effects.


The underlying problem is that you are effectively allowing a less critical system to initiate communications to a more critical system when really you want that communication to go the other way.

In other words, switch your backup process from Push to a Pull and ideally add a one-way firewall or firewall rule to protect the backup system.

Current

System --Pushes-Data--> Backup Share

Problem

An attack on the compromised system can pivot to attack the Backup system or damage it from the compromised system.

Suggested

System <--(one-way firewall)<-- Backup Server which does a Pull request.

Advantage

Compromised System, Attacker Pivots ---> XXX Packets Blocked -- (Backups unharmed)

You'll also want to have multiple backups or some kind of content versioning to protect against pulling bad data over good data but this will add a layer of defense between these systems.

Having your backup server only on-line at certain times does reduce the attack surface time-wise but it's even better if the attacker can't send packets to it ever. Maybe both controls would be ideal.


Is HTTP POST any more secure than HTTP GET for AJAX?

You should use POST for any state-changing action. If you save the content of the form, or use the form to send an e-mail, you should use a POST.

There are several reasons why this is more secure:

CSRF is easier with GET requests than with POST requests. With GET requests you can simply send someone a link. With a POST request an attacker needs to have a crafted HTML page. When your framework has CSRF protection, this is typically only active on POST requets.
The browser policy is different for POST requests. For example, you get a confirm dialog if you try to reload the page. One example of where this applies to security is same-site cookies. With the "lax" setting, POST requests are blocked cross-origin and GET requests are not.

See also this answer.


The image below shows how a packet is encrypted, and sent through the network.

Tor uses its own protocol to negotiate encryption keys.  Through this protocol the client receives encryption keys for Routers A, B and C.

From the Tor Project

  The client negotiates a separate set of encryption keys for each hop
  along the circuit to ensure that each hop can't trace these
  connections as they pass through.

Before a packet is sent, it is encrypted with C's then B's then A's encryption key.  When the message reaches router A it decrypts its layer, and forwards the rest to router B.  Router A only know that the message needs to go to router B, and that it came from the client. It cannot see any other IP information.

For Tor (and onion routing) to work a minimum of 3 routers are required.  So that no two routers will know both the source and destination IPs.  When a Tor client sends a packet out the Entry Node will know the source IP address, but not the destination.  The Exit Node will know the end destination, but not the real source address (just the previous relay).  The IP address the server uses for the first layer will be the Exit Node's.

To address questions in your comments
If an Entry Node is compromised then it can reveal the source's IP address.  But it will only know the next node in the circuit.  Without some type of relationship to the destination the anonymity stays intact.

The Exit Node never seeds the original source address, and uses its own IP for communication with the end destination.

For more info look at the original Tor design paper.


What is the difference between the different wiping methods used by DBAN?

For modern hard drives, the main difference is how long it takes -- the quality of the wipe is effectively constant between them.  A three-letter agency may be able to recover data from a zero-wiped drive, but if your opposition is a three-letter agency, you really should be looking into physical destruction instead.

DoD 5220.22-M seven-pass: I haven't been able to find a description of this, but I suspect it's a variation of the three-pass wipe, only with three values and their inverses.
DoD 5220.22-M three-pass: Overwrite the data with a value, then with the inverse of that value, then with a random value, verifying the write after each step.  The first two wipes theoretically pull the magnetic field fully one direction, then fully the other, eliminating any residue of the original value.  The problem with this is that the on-disk encoding is not simple binary data; the encodings of a value and its inverse may not themselves be inverses.
RCMP TSSIT OPS-II: Overwrite the data with zeroes, ones, zeroes, ones, zeroes, ones, and random data, and verify the final write.  The same basic idea as DoD 5220.22-M, but with only a single verification step.
Gutmann 35-pass: This writes a series of patterns that would randomize the residual magnetic fields of all hard drive technologies in common use 25 years ago.  It is totally useless on a modern hard drive, first, because low-level storage techniques have changed wildly since then, and second, because modern drives store data in such small areas that there's essentially no remnant magnetic field after even a single write.
PRNG: This over-writes the contents of the disk with pseudo-random data.  It's theoretically better than a zero-wipe, and is just as fast.


Ajax is just pasing data over HTTP - it's not magic - so you secure it in exactly the same way you do with your normal webpages -

check for authentication and authorization
Encrypt or add salted hash checks to data exported to the browser for resubmission
treat any data received in the request as potentially dangerous
use HTTPS where its appropriate
transform data leaving your PHP using the right method for were its going (htmlentities, mysql_real_escape_string
transform data entering your script using the right method based on its origin (e.g. json_decode)


Is the system bios and network card protected by the OS firewall?

Remote attackers have no direct connection with the BIOS. The only point of entry for a remote attacker is to send network packets. Network packets are interpreted by the operating system, and remote attacks work by exploiting a bug in an application or a component of the operating system itself.

Firewalls protect against remote attacks only if they block access to vulnerable applications. If you're running an Apache server and there's a vulnerability in your version of Apache, a firewall will not protect you since it has to allow HTTP requests to go through.

It is possible to have a bug in the network card's firmware. This is rare, but it has been known to happen. If the bug affects the way the network card handles packets before it transmits them to the operating system, the operating system's firewall will not help. One potential source of vulnerability is Wake-on-LAN and similar protocols if implemented incorrectly. In this particular instance, a machine is vulnerable only when it is plugged into the network but turned off! The way to protect against such attacks is to block wake-on-LAN packets from untrusted sources with a network appliance located between the machine and the hostile world.


If you ignore reverse engineering threat (you shouldn't), you can hide the encrypt/decrypt functions of your SO, and only let them be used from a trusted environment (see JNI_OnLoad()). E.g. you can check the package name of the application that loads your library. But just the same, you can run same checks in your encrypt() and decrypt().
Another trick is not to use the normal packaging process for the library, but unpack it manually from your APK to some location that can only be accessed from your application. This protection will not help on rooted devices. Update 2020: this trick won't work on Android API 29+ (a.k.a. Android 10), which revoked execution permissions from all writable directories.


Antivirus/DPI Solution with openvpn server

I ended up with snort2 in conjuction with pulled pork to automatically update the rules and a fork of BASE (for php7) as a web interface. Snort3 doesn't seem ready just yet.
To run snort inline I compiled with the NFQ daq and run it inline. It's all open source and seems to work well enough.


How authentication tag is calculated in AES-GCM-256

Yes, it is internally being done by the doFinal method. According to the Javadoc for Cipher class:

  doFinal(byte[] input)

  If an AEAD mode such as GCM/CCM is being used, the authentication tag
  is appended in the case of encryption, or verified in the case of
  decryption.

So, you don't have to explicitly append/verify the auth tag during the encryption/decryption process.


Self-signed certificates not working over Internet?

Even if you see a message saying the connection is not trusted does not mean it is not an HTTPS connection.

In order to display or not such error messages, browsers try to validate certificates using following criteria:

Does the certificate common name match the domain name entered in the URL bar?
Is the current date between validity start date and validity end date?
Is the certificate signed by a well known Certificate Authority (CA)? (This is something you don't have with a self-signed certificate)
Does the certificate have been revoked? (I'm not sure all browsers validate this point)

There are also other mechanisms but let's forget them for now.

In your case, if you want to avoid this error message (which does not mean you don't browse your website in HTTPS), you can:

Remember your choice with Firefox (and you should not be warned again)
Sign your certificate with your own CA and install your CA as trusted in Windows and Firefox (there is a quite good article here, but it is not up to date due to the use of SHA1 signature instead of SHA2)
Get a valid certificate signed by a well-known CA (StartSSL for instance which is free)


Yes: CSS can contain malware, though in my experience, its usually been tied to a vulnerability, e.g. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3971

As far as it containing JavaScript, that's certainly a vector, though successful exploitation should generally be limited by vulnerabilities within the Browser, the OS and the JavaScript engine.  Vulnerable ActiveX controls are a factor as well in such scenarios.


In SQL injections why do they put "-- -" at the end of the URL?

The last dash basically protects the trailing space. If you exploit SQL injection in a browser (e.g. via the URL), some browsers remove trailing space characters. Some prominent SQL flavors explicitly require the Space after Dash-Dash to treat the sequence as the start of a comment, so attackers often add a character after the Space to protect it against such browser optimization.

You could use any character to accomplish this. -- x would do exactly the same.


Including and storing the order of character entry in a password as an enhanced security measure

There are several reasons why this would be a sub-optimal security scheme.  Here are a few:

The biggest issue with secure passwords is our memory, or our limited capacity for remembering passwords.  We're pushing our memory limits as it is, and always working to devise new tricks to help better remember more secure passwords.  This scheme introduces new components that must be memorized, without any advancement in memorization technique.  That means that if we already at our memory limits, but now must remember entry order as well, something else needs to give, and given that entry order is not in and of itself particularly memorable, the sacrifices that we must make in the other aspects of the password are likely inordinately large.
Reduces or eliminates the ability to mask passwords.  For a non-trivial scheme (I.E., not just appending and prepending password segments) it would be nearly impossible to mask passwords during entry as we do today.  If we're going to be inserting character strings into the middle of the password somewhere, to do that with any reasonable speed and assurance of accuracy, we would need to be able to see what was already entered.  This means that you can't mask the password with a string of asterisks or discs, which allows for shoulder-surfing and photographic plain-text password capture.
Would require a new generation of password managers.  Currently, password managers have the ability to auto-enter passwords.  If order is important, you have to have the ability for them to auto-type in a specific order, or continue to live with sequentially ordered passwords if you use a password manager.  In the second case, which is the preferred mechanism today, and would likely continue to be preferred, you gain nothing from the entry-order scheme except for additional complexity.
This all has to be captured client-side.  In your specified scenario, (a web application) by the time the request is sent to the server, the password is simply a field value, and HTML forms don't support any way to associate the manner in which the value was entered with the request.   So, you need a way to both capture the entry order, and then submit it along with the request.  And it needs to work with every input mechanism, for every client user agent.
As a user, the added entry complexity can be a significant barrier.  Touch devices are one example of where this is going to be an issue.  It's hard enough as it is to do data entry on a phone, and that's becoming the most prevalent form factor for consuming the web.   Add having to move back and forth in the field as you enter a password, and it'll make you want to stab your eyeballs out with a stick.  And if you think this is hard, it would be essentially impossible for some clients, such as voice-to-text tools that assist disabled users by allowing them to speak the values they want to enter.

I'm sure there are others, these are just a few obstacles I thought of off the top of my head.   This scheme does add an element of complexity to passwords that doesn't exist today...That is true.  It is not however, an ideal scheme for improving passwords.   We're much better off promoting password managers and long, unique, random passwords that trying to find new gimmicks.


How many digits of my credit card number may be revealed on the merchant copy of the receipt (Europe)?

You're referring to the merchant copy of the receipt which should only be retained as long as the business is required to do so (vs the cardholder copy).

On a cardholder receipt the PAN (Primary Account Number) must be truncated (first 6 digits OR last 4 digits) for PCI compliance, if this is a cardholder activated terminal transaction and not an imprint, or some other kind.

PCI compliance does NOT forbid the PAN on the merchant copy, but does require they are stored securely.

There may be more restrictions for GDPR, but I'm in the USA and not familiar with those.


You can try pasting it into notepad, print it out, then enter it manually into android.

If its like 100 characters long, this is one good reason for why you may want to make it shorter.

I asked a question about how long is too long, and after 22 characters a password stop making sense.

I have the same issue. My windows account and iTunes passwords I intentionally leave somewhat weak because of this exact situation.

For a time I had facebook and gmail accounts with 100 character passwords, and it bit me in the bum in a situation similar to yours.

I've never had a problem where I wasn't able to paste into a password field, only copying out of a password field.


How to intercept XmlHttpRequest with OWASP ZAP

You need to remove the '#' and everything after it.
This is known as the 'fragment' (https://en.wikipedia.org/wiki/URL) and is not send by the browser, so its not present in the URL that ZAP sees.


Does server RAM count as storage for PCI Compliance?

It is not storage, but it is handling, processing and transmitting.

To qualify as SAQ A you must be able to state,

"Your company does not store, process, or transmit any cardholder data
on your systems or premises, but relies entirely on a third party(s)
to handle all these functions;"

You are however transmitting cardholder data, thus you do not qualify.

For SAQ C, you appear to not qualify due to:

Your company does not otherwise receive or transmit
cardholder data electronically through any channels
(for example, via an internal network or the Internet);

C only is intended to apply to companies that are entering the card information in to their site after taking the information via a non-electronic means (such as credit card information entered on a mailed in statement.)

You can check with a PCI-DSS specialist that can look at your situation in more detail, but you appear to fall under the SAQ D.

In order to avoid PCI-DSS requirements, you would need to never handle or touch PCI data in any way.  You would need to provide the amount to bill to a third party provider who would handle the entry of PCI and payment processing and then return you a non-PCI linked payment receipt code.


How can this input-sanitizer function be defeated?

I want to prove to management that this code isn't secure

You could spend the rest of your (perhaps short) career doing so, over and over as they add to the blacklist.  I suggest trying to educate them instead.

Read the OWASP SQL Injection Cheat Sheet and related sheets referenced therein, and then be able to present that to the decision makers and answer questions rationally - OWASP is a very reputable source.

Also read Why We Shouldn't Roll Our Own - in particular, the Phil Zimmerman example is an example, from a very well known cryptographer, of why "well, I can't defeat it" does not mean "it" is secure.

If you must try to provide an example, try playing around with various encodings; hexadecimal is clearly allowed, so pull up your ASCII Table for use with 0x and CHAR(), and perhaps also play around with HTML escape characters or Unicode (UCS-2, for SQL Server).

See if you can use 'set quoted_identifier off' as well.

As kiBytes said, try mixed case - the most common SQL Server collations are all case insensitive.

If anything works, you'll need to go back to educating them that just because you found N holes doesn't mean there aren't X holes remaining, some of which you will not find before attackers do.


What is the status of forced HTTPS everywhere (Strict transport security) via DNS? I only see the July 2010 draft

Click the link in the header: this draft dated Mar 2012 replaces the one you linked, and expires in Sep 2012.

See also the websec working group.


When is it appropriate to challenge with a secret word?

Personally I would never ever use any of those questions to reset a password. You are actually making your password scheme more vulnerable as finding out secret questions with easy to find answers is not  that hard.

Bruce Schneier had an an excellent blog post titled The Curse of the Secret Questions on this:

  The point of all these questions is the same: a backup password. If
  you forget your password, the secret question can verify your identity
  so you can choose another password or have the site e-mail your
  current password to you. It's a great idea from a customer service
  perspective -- a user is less likely to forget his first pet's name
  than some random password -- but terrible for security. The answer to
  the secret question is much easier to guess than a good password, and
  the information is much more public. (I'll bet the name of my family's
  first pet is in some database somewhere.) And even worse, everybody
  seems to use the same series of secret questions. The result is the
  normal security protocol (passwords) falls back to a much less secure
  protocol (secret questions). And the security of the entire system
  suffers.


Why is using [x] to generate random keypairs a bad idea?

rng-tools acts as a bridge between your computer's hardware random-number generator (if it has one) and /dev/random  If you trust your computer's hardware RNG, there's nothing wrong with using it.  If, on the other hand, you don't have a hardware RNG, rng-tools can be used to make the kernel think there's more randomness in its entropy pool than there actually is.

The problem with the suggestion in your first link (rngd -r /dev/urandom) is that you're feeding the output of the kernel's entropy pool back into it, and pretending that this represents new data.  Likewise, the "symlink /dev/random to /dev/urandom" suggestion in the third link forces gpg to use a source of not-necessarily-high-grade randomness when it's expecting a source of high-grade randomness.

The problem with using low-grade randomness when generating RSA keypairs is that if your keypair shares a factor with someone else's keypair, there's a trivial attack that can deduce your private key from your public key (use Euclid's algorithm to compute the GCD of the two public keys, which is one of the prime factors, then use simple division to compute the other prime).  This is particularly a problem with embedded systems that generate a keypair on first boot, when they don't have much if any entropy available.


What are the dangers with creating MySQL databases on the fly?

There's no inherent security issues with this architecture. Any risks will come from the implementation errors or vulnerabilities in MySQL.

It sounds like you are considering this method in order to provide separation between different networks' data, however it does sound a bit excessive. I know you tested for performance, however in a large scale this might use more resources, that's a different forum.

Remember, it's all about implementation, you could have all network data in one table and it would be secure as long as you design and code it well.


The openfisma site is pretty bad and there is little action in the forums, plus the last release is from June 2013, plus you cannot login to their demo. Putting all that together, I'd be cautious. However, it still might be worth looking at.

I can't see any glaring reason why you couldn't use it, provided you check it out well.

I've been writing a similar tool for my work environment as I found a similar problem. I can't share it with you (at least not at this stage). It is pretty specific to our needs and may not suit anyway.


When using FDE, is there any OS/software allowing to get back from hibernation without requiring the disk encryption key?

2 months later, there is still no evidence that computers in hibernation are less safe than shut-down computers, as far as FDE is concerned.

I therefore consider that the quoted comment was erroneous and mark this question as closed to avoid it to pop-up on SE front-page.

However, if anyone else has got such evidence or if there is any evolution of the situation, feel free to add a new answer, SE will notify me :) !


Encryption does not produce security, it concentrates security. Namely, encryption will help in keeping data confidential from people who don't know the decryption key. Your application, though, must know that key in order to decrypt the data again before pushing it to the database.

An important first step is to define your attack model. What are the attackers trying to achieve, and what can they do ? For instance, you may use the following:

Attackers want to learn the contents of some requests. This is a problem even if the request is old.
Attackers can recover old hard disks by practicing dumpster diving.

Then, in that situation, if you write the XML requests to files on your disk (even temporarily), attackers may obtain from an old discard disk some confidential data. Encryption may help, but only if done properly and, crucially, only if the decryption key is not itself written to the same disk. Alternatively, you might want to configure a RAM-based "disk" on your system so that the XML files never reach a physical medium in the first place.

If your model is more about attacker temporarily hijacking your server through some vulnerability, then encryption won't help, because the server must know the key -- thus, it becomes known to attackers as well.


open source software security rating -- 3rd-party authority

You will likely not find too many people or groups who will vouch for OSS product's security because it could put them at risk of being legally liable. While reputation is a part of a measure, it is hard to quantify and people like hard numbers. Here are some factors you could consider.

Has it been independently reviewed?

Ok here's your numbers. Coverity Scan is a list of Open Source projects that undergo static code analysis. It show the number of defects detected, density, and fixed, and Ruby is on it. Look on SourceForge for the projects development status. the development status is self evaluated, but it gives you at least an idea of how the project views itself.

How is it developed?
Are there people with security experience on the team? Do they do reviews before a release? What happens when the find problems before the release: do they release with a warning or hold the release until the flaw is fixed?

How good is their response to problems?

Most popular open source projects have a bug tracking system, and some have specific security issue systems. Check the bug or security tracker and see how quickly they respond to bugs or security issues.

Who else uses it?

If other companies like your client's use the software then you are assuming risk equal to your peers. If companies that have stringent security requirements use it then it lends credence to it's reputation (but of course it not a guarantee). Read Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense, however it is a little dated (2003).

What is it used for?

If you can say that the use is outside of anything security critical, and will be appropriately isolated then you don't need evidence of security robustness. Obviously this would need to be for use internally only, not on a publicly accessible server or computer.


Is a password protected PDF file safe for bank statement attachments?

No, the use of a password protected PDF file is simply not good enough for sensitive data.

As others have already stated, newer version of the PDF standard use much better encryption methods than they originally did, however, a password on a file (even a strong one) will always be susceptible to brute force attacks. At this point you're just hoping their computer is slow enough that by the time they crack your (hopefully strong) password, the information is irrelevant. That's a lot of 'hopefully-s.' Assuming monthly bank statements, and a password under 50 characters, the security of your documents is starting to sound almost laughably naive.

This could also create a security risk in other ways depending on where the bank gets the password. I know of a bank that does something similar to this and uses your account password to encrypt the document, so that you only have to remember one password. This means they are storing your account password on the server. It may be encrypted, and it may not be, but either way it's probably safe to assume that any attacker that manages to break into your banks server and get a database dump now has your password. There is no excuse for saving passwords as anything but salted hashes (the same bank emails you your password if you forget it... yup, in a plaintext email).

If you can, call your bank and ask them to start sending you your statements encrypted using a public key system. PGP and S/MIME are both great, and will put a bit more security in your hands (it will be your job to protect your private key, not your banks).

Many banks also provide RSA tokens (or equivalent technology) for relatively cheap. Although there have been some (serious) security breaches with RSA in particular lately, this is still a great addition to your account security if your bank offers it.


Differences between using Tor browser and VPN

TL;DR

Tor provides anonymous web browsing but does not provide security.  VPN Services provides security (sort of) and anonymity, but the anonymity might be more in question depending on the service.  Since you're depending on them not logging pieces of information that may or may not be able to be traced back to you.

VPNs

Traditional
A traditional Virtual Private Network does not extend your ISP.  A VPN extends an existing private network across a public network.  For example, let's say my company has a private network with email servers, web servers (intranet), and DNS setup for company related services.  It's a private network for company employees only.  However, some employees want to work from home.  A VPN is set up so that employees can securely connect to the private network remotely.  This provides two features:

Authentication - Users present their credentials to gain access to the VPN
Encryption - The entire tunnel between the remote user and the private network's gateway is encrypted.

Take that last statement: "The entire tunnel between the remote user and the private network's gateway is encrypted."  Once you're through the gateway, communication is un-encrypted. Unless the services within the private network itself use another means of secure communication.

Keep in mind that no anonymity is provided by this setup.  In fact, the company knows exactly what IPs are connecting to its private network.

VPN Services
Nowadays VPN seemingly takes on many meanings, and online/cloud/[insert Internet buzzword here] have complicated things.  We see questions now, "Which VPN takes your anonymity seriously?"  What has happened is that VPN Services have become a kind of "secure anonymity service".  A service will provide secure communications to a proxy server that will then dump your communication out into the clear to whatever your destination.

This is kind of like what a traditional VPN does, except now the statement of "a VPN extends your ISP" is kinda true.  Now you're just encrypting the first half of your communications.  It extends in the sense that you can access websites and services you might not normally be able to due to your geographic location.  But "extends" really isn't the right word to use.

Take ExpressVPN for example, it advertises the following:

Encrypt your Internet traffic and hide your IP address from hackers and spies.
Access any website or app without geographic restrictions or censorship.

Take out "Encrypt your Internet traffic" from the first statement, and you basically have an anonymous proxy.  But now that the tunnel is encrypted it's a VPN to your anonymous proxy (gateway) that then forwards your traffic on, into the public Internet.

Tor Browser

Onion Routing

Onion routing was designed to provide complete anonymity to a connection.  It accomplishes this with encryption.  Three layers of encryption.  When using the Tor Network a path is determined with a minimum of 3 nodes (can be more).  Encryption keys are setup and exchanged between you and all three nodes.  However, only you have all of the encryption keys.  You encrypt your data with each of the nodes' keys starting with the last node's (exit node) and ending with the first (entry node).  As your data moves through the network a layer of encryption is peeled off and forwarded to the next node.

As you can see the exit node decrypts the last layer, and forwards your data to its destination.  Which means your data is in "plaintext"1 at this time, but complete anonymity is accomplished.  With at least 3 nodes no node knows both the source and destination.

Anonymity not Security
Tor does not promise secure communications.  Encryption is only used to provide anonymity between nodes, your data is not encrypted otherwise.  This is why it is still highly encouraged to use HTTPS-enabled websites while using Tor.  As @LieRyan mentioned in another thread's comment, sending personally identifiable information through Tor without using other security measures will break any anonymity that Tor provides.

Traffic Visibility

As far as traffic visibility if there is an admin on the network they will be able to see your traffic. Let's take a situation with a VPN: you have your remote laptop R and your private network gateway/secure anonymous proxy (G).  Now you have a private network IP that is encrypted from R to G.  A network admin sitting on G can see your plaintext1.  As stated above if you are using another secure protocol like SSL/TLS through the VPN/VPN Service then the "plaintext" is really encrypted, and the network admin would not see anything but encrypted data.

So this really depends on where the network admin is sitting in the connection, and whether or not you use a secondary secure protocol underneath the VPN.  This same logic applies to Tor.  Because as I stated earlier encryption is only used for purposes of maintaining anonymity.

Both traditional VPNs and VPN services are to protect against external visibility into the network.  Neither of them will protect you from authorized administrators for the network you're on.  It's all about protecting your data from unauthorized eyes.  Even with SSL/TLS, a website that you're visiting sees your decrypted traffic.  It has to in order to process the request.  Admins on that website can see those same requests and/or log them.  It's the security protocols used initially and in between that make the biggest difference in the security of communication.

1 It's plaintext as far as the data that was sent is seen here.  If the data is encrypted with something like SSL/TLS before going through the onion routing then the encrypted data would be seen at this point.


Is Signal still more secure than WhatsApp?

There are still a couple of security functions, which may matter to you, which Signal does better than WhatsApp.
Client-Side Fanout
When you use a group chat in WhatsApp, you send your message to the server who in turn distributes it to all the group members. This way WhatsApp learns all the social structures and can in theory perform traffic analysis to deduce quite a bit of information from the message volume exchanged.
In Signal on the other hand, group chats are actually normal peer-to-peer chats with a special flag, which is set inside the end-to-end encrypted frame. So this way OpenWhisperSystems (the makers of Signal) doesn't learn your social group structures. However they can still see that three messages are going to three different people at once and can guess that this is due to a group chat.
The blog post for Signal. The server-side fan-out is stated in the white paper (PDF).
Private Group Metadata
Because the previously mentioned approach of everyone just directly sending the group messages to each other is messy with regards to privileges - as achieving consensus in an asynchronous distributed system is hard - Signal has deployed a new system to enforce access control and privileges in groups without learning anything about the group structure - only about the existence of a group and a guesstimate of its size based on the size of the server-stored ciphertext. See this blog post for details and this post for the deployment announcement and this post for how group links factor into this.
I was unable to find documentation on how WhatsApp handles this data. Though given they know the group membership to distribute messages, they may just store this in the clear.
In-App Encryption
Signal offers to encrypt the past communication at app level, which WhatsApp  lacks completely. Obviously this can protect your messages in case of theft however you probably won't gain that much security because most people will probably not choose good passwords here for usability reasons.
Use of the OS keystore
Modern mobile operating systems provide a place for you to store your keys so they aren't unencrypted in the filesystem. The OS will usually either encrypt them with some hardware backed mechanisms, like iOS's secure enclave or Android will use things like ARM TrustZone for increased difficulty of key extraction. Additionally Apple is famously known for doing a really good job at the security of the iOS keychain backups. Signal uses these security features (iOS, Android), whereas WhatsApp (likely) does not.
Optional Read and Typing notifications
WhatsApp notifies you when somebody is typing and it notifies you when somebody read your message - and you can't turn it off for group chats. This however allows WhatsApp to deduce app usage behavior and your habits. Like "Do you check your WhatsApp messages at 1am?", combine that with the other meta data WhatsApp is harvesting and you can make some useful guesses about people's lifes. Additionally the "typing" notifications can be used to deduce potential contents based on context and default keyboard suggestions and other factors.
Signal doesn't enforce this. Here's the original discussion on it on GitHub. As a more recent development, Signal adopted read notifications, but they're default-off (for pre-existing installations) and aren't forced-on in Group conversations. For groups I think they work indidually with each member, that is if a member and the sender have them both enabled, the sender will get the notification, which is much more privacy-focused than WhatsApp's solution.
Backup Security
WhatsApp offers you to backup your messages so you can recover them when your phone is inacessible or destroyed. However due to the very nature of this, the backup (which must (also) be hosted on Google Drive) cannot be encrypted / secured other than with your username / password for that account (which WhatsApp doesn't know). So as soon as that Google Drive account is breached or some government demands access, all the end-to-end security is gone if either party of the communication had backups enabled. As for iCloud (as opposed to Google Drive) a similar argument applies - especially as the kind of data WhatsApp is saving is not sensitive enough for Apple to use their stronger security mechanisms as they would e.g. for passwords.
Even though the backup feature of Signal isn't as convenient as the one of WhatsApp it doesn't automatically store (plaintext?) copies of messages on Google servers, but rather allows you to (automatically) create a local (encrypted) file and push this one manually around. It is unclear though of WhatsApp's backup feature profits from the recent security enhancements in Google's backup infrastructure (on android at least), so they might actually be secure.
Auto-deleting Messages
Automatically deleting your own old messages is good from a security standpoint. It means that if an attacker manages to break into your phone / backup that (s)he can't access all messages but only the recent ones. Auto-deletion is especially nice if you consider that you won't read all the really old messages anyways and that it will save you some storage. As of now, WhatsApp does not implement this.
Signal on the other hand does.
No meta-data storage
Signal was recently hit by a Subpoena. They complied (of course) but could only contribute very little, which confirms that they're holding true to their privacy policy.
At the same time WhatsApp is sitting on a large(r) amount of meta data and would be much more useful if hit (and if it's being disclosed). This is especially obvious if you compare what WhatsApp logs and what Signal logs.
Private Contact Discovery
WhatsApp uploades your entire adress book to their servers to compare which of the listed users have WhatsApp accounts. Obviously during that process WhatsApp learns your social graph, that is who you know, including people who don't use WhatsApp.
Signal now on the other hand, has somewhat recently deployed a much smarter solution, using fancy modern cryptographic techniques paired with Intel's SGX technology so that OpenWhisperSystems actually doesn't learn your adress book (only the SGX enclave does and that doesn't leak it), but only needs to keep on-record who their users are and thus they also don't learn anything about which users you may know but don't chat with using Signal and which people you know but don't use Signal (yet). The details of this can be read in their blog post.
Registration Locking
While both Signal and WhatsApp support registration locking which forces you to enter a pre-determined PIN whenever a new device is added to an account, it is unclear how security is enforced. That is, how many tries one gets for the PIN before hitting the lock-out and whether this lock-out can be overriden by the service operator. Signal is currently beta-testing using SGX to have a verifieable upper limit on the tries you get for this.
Private Link Preview
Signal goes out of its way to hide which URL you're accessing from Signal when generating link previews and hiding your IP from the server.
WhatsApp on the other hand has a less stringent stance on the topic though it is only "worse" than Signal in that regard by leaking the sender's IP to the service.
Sender Hiding
Signal has a feature that allows you to hide your identity from the server when sending a message. That is, the app can send a message to the server that will be delivered without revealing from who it is exactly. So what the Signal servers see is that somebody with a given IP sent a message to a well specified user.
From what I know WhatsApp doesn't implement anything similar and instead relies on user authentication for sending to prevent impersonation and similar issues.
Encrypted Profiles
In Signal your profile picture and chosen name are only ever transmitted using end-to-end encryption. Also see the introducing blog post. This means that the server doesn't learn how your picture looks or what string you use to identify yourself to others.
In WhatsApp however the picture is less clear. It seems highly likely that if you set these information to public they are indeed stored in the clear on the servers. However if you set it to contacts-only, it is much less clear whether WhatsApp uses its end-to-end encryption for the transport of the image or whether it's just an access-controlled API functionality on the server. At least this (unofficial) blog post claims that the end-to-end encryption is not used for profiles.
Ephemeral Messages?
They're a feature supported both in WhatsApp and Signal - messages that are deleted on the receivers end after some condition is satisfied. However there's no real security impact for their implementation as the rule "if you can see it, you can photograph it with a different device" applies.
So TL;DR:
The remaining security differences (after the protocol update) are mainly that WhatsApp generates a lot of meta data to be convenient while Signal tries to avoid meta data.


CoAP over DTLS duplication of epoch and seq no

The AEAD format, after the 13-byte DTLS record header you correctly describe, begins with an 8-byte explicit nonce (combined with implicit nonce aka 'salt' from key derivation to form the actual nonce); this may be (epoch+)seqnum.

Quoting https://tools.ietf.org/html/rfc6655 (which applies to both TLS and DTLS, remember):

  [...] The
     nonce_explicit is the "explicit" part of the nonce.  It is chosen by
     the sender and is carried in each TLS record in the
     GenericAEADCipher.nonce_explicit field.  The nonce_explicit length
     (SecurityParameters.record_iv_length) is 8 octets.  Each value of the
     nonce_explicit MUST be distinct for each distinct invocation of the
     GCM encrypt function for any fixed key.  Failure to meet this
     uniqueness requirement can significantly degrade security.  The
     nonce_explicit MAY be the 64-bit sequence number (as long as those
     values are assured to meet the distinctness requirement).

  In DTLS, the 64-bit seq_num is the 16-bit epoch concatenated with the
     48-bit seq_num.


Would the attacker get a valid CSRF token if the session token is stolen?

CSRF tokens aren't a defense against other users logging into their account. CSRF tokens are a defense against CSRF attacks only. If anyone logs into an account (including an attacker), then they should get the CSRF token (along with all of the other content that's normally served to the user).


How can I proceed with my research on applying machine learning in Cyber Security?

Here's some incomplete answer but that's all I can tell now.

Machine Learning today seems more of the programming framework so it's best suitable for developing new applications, so for this a bit of programming (scripting) is needed.

Machine Learning can solve existing  problems better than previous solutions for example, Spam Filtering, Image Recognition, Speech to Text, Natural Language Processing etc.

However, using machine learning in applications usually means either doing completely new products (design from scratch) or extending existing products.

Machine Learning works on data so there's some data required to do the test and the more of it the better. It can be voice, sound, images, videos, logs, texts, structured documents, tables etc.

Now the thing is since there are many Machine Learning frameworks and services there aren't many applications yet, so the functionality is already built-in into the product like IDS, or it needs to be applied programmatically.

Because programming Machine Learning itself is not the main point but rather using it, the good starting point on seeing how it works and how it can be used is to have a look on Google Cloud Machine Learning.

Google Cloud Machine Learning

However even simple algorithms can be used effectively for example as "log processor" but also database (memory) is also needed.

One of the interesting Machine Learning applications is observing the user on the PC - instead of using more cameras to observe the person, so in this case Machine Learning can be used to analyze the traffic on the net, the web browsing history, what is typed and even what the person can see on the screen.

For example using Machine Learning with the tape archive and regular storage it is possible to analyze the log and predict what data will be required and when so it can be retrieved from tape archive ahead of time (that's the real and tested application example).

Machine Learning could be also to orchestrate all sorts of jobs based on the predictions of the required load - this is the case for some very complicated workflows, loads of them and limited resources, for example the way Google optimized their power management in data centers.

To get the idea first is to get some data first. The log data is ideal point of start. Prediction API seems interesting.
However there are many other products offering similar functionality in machine learning, they usually facilitate real-time data streams like logs, it's good to google for them a bit.

The most popular languages for the job are Java and Python, but many other are used too including C, C++, C#, Go, Ruby, PHP, Perl etc.

So the main point is to invent the application and to do it is to have some data first.