dns reflection attack vs dns amplification attack

Full disclosure, I work for a company that develops DDoS mitigation and web application firewall services

DNS amplification is a Distributed Denial of Service (DDoS) attack in which the attacker exploits vulnerabilities in domain name system (DNS) servers to turn initially small queries into much larger payloads, which are used to bring down the victim’s servers.

DNS amplification is a type of reflection attack which manipulates publically-accessible domain name systems, making them flood a target with large quantities of UDP packets. Using various amplification techniques, perpetrators can “inflate” the size of these UDP packets, making the attack so potent as to bring down even the most robust Internet infrastructure.

DNS amplification, like other amplification attacks, is a type of reflection attack. In this case, the reflection is achieved by eliciting a response from a DNS resolvers to a spoofed IP address.

During a DNS amplification attack, the perpetrator sends out a DNS query with a forged IP address (the victim’s) to an open DNS resolver, prompting it to reply back to that address with a DNS response. With numerous fake queries being sent out, and with several DNS resolvers replying back simultaneously, the victim’s network can easily be overwhelmed by the sheer number of DNS responses.

To amplify a DNS attack, each DNS request can be sent using the EDNS0 DNS protocol extension, which allows for large DNS messages, or using the cryptographic feature of the DNS security extension (DNSSEC) to increase message size. Spoofed queries of the type “ANY,” which returns all known information about a DNS zone in a single request, can also be used.

Through these and other methods, a DNS request message of some 60 bytes can be configured to elicit a response message of over 4000 bytes to the target server – resulting in a 70:1 amplification factor. This markedly increases the volume of traffic the targeted server receives, and accelerates the rate at which the server’s resources will be depleted.

Moreover, DNS amplification attacks generally relay DNS requests through one or more botnets – drastically increasing the volume of traffic directed at the targeted server or servers, and making it much harder to trace the attacker’s identity.

My company provides various solutions to protect yourself against DNS attacks. Please read more about how you can mitigate these sort of attacks: https://www.incapsula.com/ddos/attack-glossary/dns-amplification.html


Can a mobile phone be induced to fall back to 2G comms?

Yes it's possible. Not sure if you know how IMSI catchers operates.

An IMSI catcher blocks the smarter 3G and 4G signals, forcing mobile phones in the area to switch to the unsecured 2G service — something that phones also do routinely in more rural areas, where 2G service is widespread.

The IMSI catcher then poses as a tower and "catches" signals.

The IMSI catchers take advantage of a vulnerability built into the system. Phones using 3G or 4G technology can authenticate cell towers, but phones on older 2G systems cannot tell between real and fake towers.

IMSI catchers hijack the phone's signal and intercept the contents of calls and texts.

The government agencies and law enforcement can use these, but you can always buy one on the black market or build one yourself.

You can find a lot of information on the internet about IMSI catchers


Theoretically, if there aren't any problems with the authentication mechanisms of the website and it is implemented securely (using an SSL connection, no flaws in the implementation that can be exploited, etc) then it doesn't matter.  That said, that is a BIG if.

It would be safer to remote in to the company through an already existing gateway, but if there isn't an existing gateway in, and depending on what the firewall is responsible for (if bypassing it wouldn't result in exposing the internal network from the outside, but only allowing things from the inside out), it could potentially be safer to administer the firewall this way than open up a gateway in to the entire network (since a VPN could potentially have a similar vulnerability.)

If the firewall being down would allow external attackers in, then it's no more safe than the VPN being added since a compromise would give access to the internal network.  A VPN probably has a smaller attack surface area, so it's probably safer in that case.

Either way, he better be sure to put a lot of security in to the credentials for remote access and have them lock out quickly if a brute force attack is attempted.  It would probably even be worth using a certificate based authentication as well since it is pretty much the keys to the kingdom.  I wouldn't personally want to put such functionality on the Internet, even behind a secure portal, unless I absolutely had to.


Privacy concern: Services requiring a phone number for signing up

As always, it depends on your threat model. What kinds of privacy intrusions are you trying to protect from, and by whom? It is true that because most people only have one phone number (and one email address), those are used as unique identifiers to aggregate seemingly disparate dossiers of your online and offline profiles, devices, locations, and behaviors. So having multiple identifiers that you use in some systematic way can be useful to reduce this kind of routine commercial (and political, etc.) tracking.

I'm not familiar with specific tools for European users, but having a spare phone number (or multiple) can be achieved by getting one or more virtual phone numbers (assuming you don't have to disclose much personal information to get them), or by getting as cheap a SIM as you can (if it's billed by usage and you only use it for some set of online accounts, you presumably would only be getting a few SMS or data notifications on it). But definitely do avoid sketchy companies, probably not worth the risk.

You may be able to set up VoIP numbers using a service like the 3rd option here, they appear to support EU customers:
https://source.opennews.org/articles/shields-using-signal-without-your-phone-number/


Creating a rainbow table with predefined text

You would have to either find a tool which already handles exactly this kind of hashing, or modify one to suit your needs. For instance, this project seems to contain an opensource rainbow table generation implementation.

Of course, such a table would be produced for specific values of "PredefinedText1" and "PredefinedText2" and would be useless to attack hashes which were computed with distinct text values. If you have only one password to crack, or if you have several but all in one go, then it would be more efficient to do a direct dictionary attack on the password. Rainbow tables, like all kinds of precomputed tables, are interesting only if you plan to attack several hashes at distinct times.


There is no way to cryptographically guarantee that a key will be useless after a certain period of time. The most you can do is digitally sign an expiration date, telling any potential decryption utilities to first verify the date before decryption. The utilities will then be in charge of either reporting the fact of the expiration, or refusing to perform any futher actions. As mentioned in a comment, the x509 format provides that ability, and compliant utilities will (or at least should) check the expiration date.

The reason for this is simple. If you have C = Enck(P) and P = Deck(C), where P is plaintext, C is ciphertext, and k is a secret key, it is logically impossible for the passage of time to change the behavior of a functional algorithm such that P ≠ Deck(C). You can of course have both parties agree to "forget" either k or C via mutually-agreed upon policies as other answers have described in more detail, but no matter how much time elapses, given C and k, you can always calculate P.


Is QUIC (Quick UDP Internet Connections) safe to allow through firewall?

QUIC by itself is no more dangerous than TCP, UDP, HTTP ... . What matters is the content transferred with the protocol. If you use your firewall only as a simple packet filter and don't do any content inspection (i.e. malware, URL filter etc) then it does not matter much if you allow QUIC or not. If instead your firewall is used to analyse HTTP(s) traffic than it might be a good idea to drop QUIC traffic so that the browser will continue to use HTTP(s) and not bypass the analysis with a protocol your firewall does not understand.


What are the basic certification course for beginners?

My employer required CompTIA's Security+ certification for entry-level positions.
It will give you the basics. Despite criticism for its form (multiple-choice answers), by actually doing the course and studying on areas where you lack knowledge, you will get a decent start about security. After that it may become a matter of choosing where you want to go next such as malware analysis, penetration testing, intrusion analysis, forensics, etc.

So start with Security+. It's the most basic and possibly the most common entry level certification.


How to prevent Windows Update from suspending BitLocker encryption?

UPDATE: as per comments, this answer does not fully explain the behaviour.

I am not an expert, but I recently encountered something similar.
First, note that there is a difference between "Suspending" BitLocker, and "Turning Off" BitLocker:

From your screenshots, your BitLocker is suspended, not turned off.

According to Microsoft:

The Suspend-BitLocker cmdlet suspends Bitlocker encryption, allowing users to access encrypted data on a volume that uses BitLocker Drive Encryption. This cmdlet makes the encryption key available in the clear.
...
While suspended, BitLocker does not validate system integrity at start up. You might suspend BitLocker protection for firmware upgrades or system updates.

Windows Update has a mechanism where it installs some of the updates now, and the rest on the next reboot. I assume that this is accomplished by booting into some lightweight OS that exists only to install the new files, and then calls the Windows bootloader when it's done.  It looks like Microsoft has decided that they don't want to bundle all the TPM drivers into this lightweight installer, so they disable BitLocker temporarily.
A suspended BitLocker should go back to full protection on the next reboot, so the answer seems to be when Windows Updates asks you to reboot, you should do it promptly. I know it's annoying, but unfortunately, that's how Windows works.


What cipher suites do Mail Clients (Thunderbird, Outlook, ...) support?

Thunderbird uses the NSS library like Firefox, so look at the Firefox report for the ciphers. Similar Outlook uses SChannel like IE/Edge so look at these reports. Apart from that you can simply find out what a specific implementation uses by running a packet capture and then look at the cipher suites offered by the client in the first record of the TLS handshake (i.e. ClientHello).


Can having certain restrictions/rules make passcodes less secure?

Assuming the policy on sequential numbers is very defensive and concerns the following digit, and assuming that 9 is followed by 0, this reduce the number of available passcodes to 10*8^5=327.680

Which reduce the possibility to a subset containing 32.76% of the original possibilities, which is not that much different on a scale.

However, such a rule prevent the user from setting trivial passcodes such as 000000 or 123456 which are incredibly dangerous to set on a corporate phone as these are very common passwords that a potential malware will try to input.

In conclusion, the risk of reducing the number of available passcodes to chose from is small compared to the impact of letting the user set a trivial password.


How to protect encryption key while application is using it

One solution is to use a Smart Card rather than the flash drive: these can be arranged to perform the cryptography without letting the key go out. This works fine if speed is not an issue.

For high volume of data, you can use a random key for each file, and preppend it to the to the ciphertext, after being enciphered using the long-term key in the Smart Card, so that the Smart Card is necessary to recover the key that will decipher the file. Next step is to use asymmetric crypto in the Smart Card, and move to hybrid encryption, with the benefit that one can encipher a file for a certain user, without knowing that user's deciphering key.


Website fell under the Google filters for inbound links

Just having your GA ID isn't enough to compromise the site. There is the chance that the spambot is sending fake referrer information using your domain name, but that doesn't have anything to do with GA tracking code, and furthermore, it's out of your control even if they do.

If this email didn't come from Google, like @Matthew said, I'd classify it as SPAM and carry on business as usual.


Open Source tool for analysing javascript for security vulnerabilities

You've mentioned that your app is written in JavaScript, and I assume you are talking about JavaScript that runs in the browser, and not in a Node.js server. That leaves me unsure about whether your app has any server side code (e.g. Java Servlets, PHP, ASP.NET, Ruby, etc).

If you don't have any server side code then your app is quite low risk: there is very little an attacker could get from attacking it. There won't be any database, so there won't be a risk of SQL injection. Can you elaborate on what you are trying to protect? For example, is there any sensitive information handled by the app?

This open source scanner looks for DOM based Cross site scripting, but I'm not sure how easy it would be to set up. You can also search Google for "xss detection plugin" to find other browser plugins that scan web apps.

If your app has server side code then leave a comment to say what language it is so I can suggest a scanner for it.

EDIT: If I understand you correctly, you need to create a web app where users can upload the source for their app, and your web app will tell the users what vulnerabilities are in their app. The uploaded app to be tested might contain Javascript. Have a look at this library, it might help you to scan Javascript for security vulnerabilities.


Checking the primality of numbers for use in RSA

RSA is guaranteed to use prime numbers. In fact, if the numbers were not primes, RSA key operations would simply not work (with overwhelmingly high probability). However, the OpenSSL command line utility has the ability to check the primality of a number using Miller-Rabin primality testing, the standard test algorithm for checking large primes for use in cryptography:

OpenSSL> prime
No prime specified
options are
-hex           hex
-checks <n>    number of checks
-generate      generate prime
-bits <n>      number of bits
-safe          safe prime
error in prime
OpenSSL> prime -generate -bits 256
315016830147073940139675761214468273143
OpenSSL> prime 315016830147073940139675761214468273143
ECFE08DCA281B26A5EDDE8DF7D2A33F7 is prime
OpenSSL> prime 10000000000000
9184E72A000 is not prime

I believe the default number of checks is 64, but you can increase this to improve accuracy using the -checks option. Each check runs one Miller-Rabin test round which individually has a 75% chance of detecting that a composite number is indeed composite. Specifically, the chance of failing to identify a composite number as such is 4-n, where n is the number of rounds used. With the default of 64 rounds, this is 4-64, or 2-128. To put that into perspective, if you put a composite number through 64 rounds of M-R primality testing, the chance that it is falsely labeled a prime is equivalent to the chance of correctly guessing a 128-bit encryption key on the first attempt.

I explained more about primality testing in OpenSSL in another answer.


How can I limit the information (metadata) that is being sent to Google from an Android Phone?

Doing the following would help in controlling the data being sent out.

Root your phone
Install a firewall (Eg: Comodo Antivirus, Avast Mobile Security)
Turn on firewall for applications which you don't want to communicate with the server.
Uninstall bloatware and unnecessary google apps using System app remover [ROOT] [ Make sure that the services you uninstall are absolutely unnecessary for the operation of the phone]


How to find what has been added to my hard drive

I would recommend the freeware called Recuva by Piriform, I have used this software with clients as well as in the past in organizations I have worked for in their IT Dept.

This software works to look at data on the hard drive that might be deleted

https://www.piriform.com/recuva


How to find the ip address of a wifi router while I have it's MAC address?

WLAN is in the OSI-Model at layer 2 while IP is at layer 3. You need to first have full access to the layer 2 before you can get the information from layer 3. This means that for a WLAN without encryption you can probably see the information by using wireshark, but for a WLAN with encryption you need to decrypt the data first because the encryption is at layer 2. According to the documentation wireshark is able to decrypt WEP and WPA/WPA2 traffic in pre-shared mode if the passphrase is known.


Why is it always `HASH( salt + password )` that we recommend?

Actually, "we" are not recommending any of what you show. The usual recommendations are PBKDF2, bcrypt or the SHA-2 based Unix crypt currently used in Linux.

If the hash function you use is a perfect random oracle then it does not really matter which way you input the salt and the password; only matters the time it takes to process the salt and password, and we want that time to be long, so as to deter dictionary searches; hence the use of multiple iterations. However, being a perfect random oracle is a difficult property for a hash function; it is not implied by the usual security properties that secure hash functions must provide (resistance to collisions and to preimages) and it is known that some widely used hash functions are not random oracles; e.g. the SHA-2 functions suffer from the so-called "length extension attack", which does not make them less secure, but implies some care when using the function in funky password-hashing schemes. PBKDF2 is often used with HMAC for that reason.

You are warmly encouraged not to feel creative with password hashing schemes or cryptography in general. Security relies on details which are subtle and which you cannot test by yourself (during tests, an insecure function works just as well than a secure one).


CSRF Testing. Validation Error 422. Locale Required

I see you want to send a JSON format; a HTML form builds a POST request taking the name and value attributes in the following way:

name1=value1&name2=value2

So, your POST request could look like this:

{"email":"testuser@gmail.com" ,"locale": "en"}=&locale=en-US

As you can see, it's an incorrect JSON format and the application could generate an error. Also, you are using the value applicatiom/json for the attribute enctype to specify the content-type header, but this could encode the body of POST request, something like this:

%7B%22email%22%3A%22testuser%40gmail.com%22%20,%22locale%22%3A%20%22en%22%7D=&locale=en-US

You have another incorrect JSON format.

So, if the application doesn't validate content-type, you could use text/plain instead of applicatiom/json and change your form in the following way:

<input name='{"email":"testuser@gmail.com" ,"locale": "en' value='"}'>

The POST request would be the following:

{"email":"testuser@gmail.com" ,"locale": "en="}

Now, you have a correct JSON format, the unique problem might be the character =.

If the application validates content-type, there is a technique about a Flash script and a HTTP Response 307, I share you a link about this technique.

CSRF Flash 307

I hope this information helps you.

Good luck.


Is there any way to determine the location of a laptop based on its MAC address or serial number?

If I have the MAC address and S/N of a Lenovo 3000 Laptop, is there some way for me to find exact street location of this laptop ?

No, there is not. You can get somewhat along the way if you pre-provision the system with software intended to "phone home" (the IP address will point to the ISP, and the ISP can determine which account was using that IP address at a specific time), but unless the perpetrator is specifically after your data, most likely among the first things they will do is possibly wipe the system clean, and then sell it to get some money. Or possibly just sell it. Alternatively, if they are after your data and have any reason to believe you have pre-provisioned the system with software intended to "phone home", they may simply remove the hard disk and use it in another system (which also completely bypasses operating system access controls).

MAC addresses are only used on the local network segment and are not routed, so never make it onto the Internet. The serial number might be accessible through some sort of remote administration software if you already know where and how to look, but it's not like the computer is likely to (should be) broadcasting that information across the Internet to anyone who merely asks.

The serial number will be useful for the police, since as pointed out by Brian Cain it allows them to identify the specific computer and the fact that it belongs to you, if it is found. Hence, if/when reporting a computer stolen, it is always good to identify it as uniquely as possible; the specific make, model and serial number will go a long way.

  I believe I have the 2 exact street locations where it could be, and an email address for each location.

If you have this information, you should be giving it to the police. They will be able to make good use of it, if you can show that it is reasonably likely to be correct. Using it on your own to try to get your computer back may actually itself be illegal in certain locales.

  Contained all my personal info prior to 2009, some of which I now desperately need.

Like I said above, the most likely thing that happened is probably that whoever took the laptop wiped it clean.

If you have a copy (backup) of the information that was on the laptop (which it sounds like since the stolen laptop was your "backup machine"), then restore the backup and use the information from there. If you don't have a backup from back then, at least start making backups now. Also, keep the backups physically separate from the computer itself, such that if one is able to steal the laptop they aren't also able to steal the backup.

Having a solid backup regimen in place will also protect your data from a number of other threats, not the least of which being disk crashes or user errors. Without having specific statistics, I believe it is safe to say that deleting the wrong file yourself is much more common than having your computer stolen.


I just happened to find this question here in 2018, and I want to warn those of you back in 2016 that this is completely insecure. Anyone holding your private key can indeed mint all of the JWT that they like. If this is an RSA key pair, it is almost certainly trivial to compute the public key, given the private key.

Given the public key, it is very, very hard to find the private key (hence, the strength of RSA). Given the private key, it is easy to find the public key. Just guess the typical exponent of a public key, and see if that works.


How to prevent sharing of document templates in Google drive that I didn't authorize?

It sounds like you've created a document-template & saved it to the template-gallery in google-docs. This would make your template public.

If you're using & paying for g-suite, you can (likely, I haven't tested this) make private templates.

But if you're using the public/free google-docs, your templates will be made public.

That's not to say your documents can't be private in google-docs, but that document-templates are made public. You may want to work around this by making copies of a document which stores the commonly used content, rather than using a template to store the content which is commonly used across your documents.

Templates are meant more for storing layout/functionality than for storing information.


Is it possible to tell if hard drive is encrypted?

We have two types of encryption here, "file based encryption" and "full disk encryption". There are documented forensics methods and software (e.g. EnCase) that help us detect the schemes and programs used to encrypt the disk.

I'm going to take a list of popular tools and standards and see if they leave any traces with which we can determine that they've been used:

Bitlocker
Bitlocker is a full disk encryption standard available on windows operating system from Windows 7 onwards; this tool uses AES256 to encrypt the disk. A disk encrypted by bitlocker is different than a normal NTFS disk. The signature of "-FVE-FS-" can be found at the beginning of bitlocker encrypted volumes.
These volumes can also be identified by a GUID:

for BitLocker: 4967d63b-2e29-4ad8-8399-f6a339e3d00
for BitLocker ToGo: 4967d63b-2e29-4ad8-8399-f6a339e3d01

DiskCryptor/TrueCrypt/VeraCrypt
DiskCryptor is based on TrueCrypt. For both DiskCryptor and TrueCrypt we can detect their presence with the following criteria:

size of file or collection of clusters object is a multiple of 512,
minimum size of object is 19KB, although by default is minimum 5MB,
contains no specific file signature throughout the entire object, and
has a high Shannon entropy or passes Chi-squared distribution test.
Note that since there's no specific signature or header left behind we can't tell for sure if TrueCrypt (or its siblings) were used, by combination of several methods we can try to make better guess about its presence.

FileVault
Filevault is Bitlocker's equivalent on Mac and offers full disk encryption. The signature of "encrdsa" or hex value of "65 6E 63 72 63 64 73 61" can be found at the beginning of FileVault encrypted volumes.
cryptsetup with LUKS
Linux Unified Key Setup is a disk encryption specification and can be used in cryptsetup on Linux which is a common tool for storage media volumes encryption. It is optional and users can choose not to use this format but if used we can detect its presence with "LUKS\xba\xbe" signature at the beginning of the volumes.
Check Point Full Disk Encryption
At sector offset 90 of the VBR, the product identifier "Protect" can be found. Hex value "50 72 6F 74 65 63 74"
GuardianEdge Encryption Plus/Anywhere/Hard Disk Encryption and Symantec Endpoint Encryption
At sector offset 6 MBR, the product identifier "PCGM" can be found. Hex value "50 43 47 4D"
McAfee Safeboot/Endpoint Encryption
At sector offset 3 MBR, the product identifier "Safeboot" can be found. Hex value "53 61 66 65 42 6F 6F 74"
Sophos Safeguard Enterprise and Safeguard Easy
For Safeguard Enterprise, at sector offset 119 of the MBR, the product identifier "SGM400" can be found. Hex value "53 47 4D 34 30 30 3A"
Symantec PGP Whole disk Encryption
At sector offset 3 MBR, the product identifier "ëH|PGPGUARD" can be found. Hex value "EB 48 90 50 47 50 47 55 41 52 44"

Measuring File Randomness To Detect Encryption

Methods discussed earlier may not be feasible for every disk/file encryption scheme since not all of them have specific properties that we can exploit to detect them. One other method is to measure the randomness of files and the closer they are to random, the more certain we are that encryption is used.
To do this we can use a Python script named file_entropy.py. The closer the entropy value is to 8.0, the higher the entropy.
We can extend this further and draw plots to visualize the distribution of bytes. (calculate-file-entropy)

One other pointer to detect encryption is that no known file signature will be spotted in the volume. (No jpg, no office documents, no known file types) And since compression methods (e.g. gzip, rar and zip) have known signatures we can differentiate them from encryption for the most part.

Sum up

Use known signatures to detect encryption (if possible)
Use special characteristics (minimum file size, high entropy, absence of any special file signature, etc.) to detect encryption
Rule out compressed files using their signature

So going back to the main question, "Is it that easy to tell?", this falls under forensics methods, we may be dealing with steganography techniques. In a normal case where user isn't trying to fool us, it is somehow easy to tell encryption is in place but in real world scenarios where user's may try to hide things and deceive us they may just pipe /dev/urandom to a file! It's not gonna be easy.


ELI5: What is the goal of the senders of the fake texts I receive

I think the way things like DocuSign work is that you can send files to people using a email and probably text by sending a key and then the person can securely access the files on DocuSign's website with the pin. This means if someone somewhere is trying to send documents to someone but have your number by mistake, they would keep sending you these texts. With the numbers of texts you are getting it probably means your number is mistakenly in a database somewhere as contact info for someone else.

You said that DocuSign only verifies emails but maybe some system in the middle will parse emails for some addresses and send a text to the user as well and this doesn't have anything to do with your telecom provider or DocuSign themselves. The system could also be reconfigured with the wrong timestamp application onto texts. I would have no idea why your telecom can't find the texts in this case.

Although it is possible your texts are compromised at your telecom and someone is using it to gain access to files posing as your number. Either way, your info isn't at risk.

Your number is public so anyone can text you. You should ask to block the number these texts are coming from if you wish to stop getting them.


What is the collision chance of a 128-bit hashing function if it is always fed with 256-bits of data?

The relevant principle here is the birthday attack. It roughly states that for a 2n algorithm, your probably of a random collision is between any two items is 50% once you generate 2(n/2) outputs.

When looking at a hashing algorithm, the naive consideration of the algorithm is that the odds are bassed only on the last iteration. In this way, a 128 bit algorithm doesn't care if you feed it 1 bit or a million bits: your odds of collision should be the same for a given number of unique inputs (as you can obviously only input 2 different one-bit values).

Thus, the answer for a 128 bit algorithm is that it has a 50% chance of a collision occurring between any two values after 264 outputs have been created.


In my opinion U2F lacks one thing at the moment:
The privacy of your secret key.

Each device comes with it's own secret key. A site specific key is derived from this secret key to do the challenge response when logging in to a site.
This is ment to keep you anonymous and easily register and authenticate at a site.

But! Each U2F device that is sold nowadays comes with a initialized not changeable secret key.
Thus you need to trust the vendors, which created this secret key.

I would like to have a U2F device, where the user can create his own secret key! As long as this is not available, this is the biggest drawback. My opinion.

Edit on February 25th, 2017

This was true for Yubikeys and Plugup devices and many other diveces OEMed  from these. In fact there are nowadays devices/vendors, that claim to really create and not derivce the key pairs for the registration. (I have not tested and verified this, yet.


Is a router without inbound firewall a security issue across the internet?

... a router without a firewall ...  using MASQUERADE

Masquerading is not a routing functionality because it changes the source of the packet. Instead you actually need a stateful firewall to do the masquerading. Which means that if masquerading is involved you must also have a firewall there. This of course says nothing about the configuration of the firewall, but it contradicts your assumption that you have a router without firewall.

  ... since Alice's router will happily forward

Since the router/firewall is doing MASQUERADE for traffic from inside (Alice private network) to outside (i.e. network B and further) it can only forward traffic from outside to inside for which an active NAT rule exists. Any packets from outside for which no such rule exists will be discarded. Thus no happy forwarding will be done and no forwarding will be possible.

In theory you could probably define rules where packets from a specific subnet will not go through the NAT but go directly into the other network but this would be some unusual non-standard configuration.


Why is iPhone's internal storage so hard to crack/decrypt?

I don't think that you interpret the rule you've heard in the right way. If an attacker has physical access to an encrypted but switched off device he cannot simply break the encryption provided that the encryption was done properly. This is true for an iPhone as much as it is for an fully encrypted notebook or an encrypted Android phone.

The situation is different if the device is not switched off, i.e. the system is on and the operating system has access to the encrypted data because the encryption key was entered at startup. In this case the attacker might try to use an exploit to let the system provide him with the decrypted data. Such exploits are actually more common on Android mainly because you have many vendors and a broad range of cheap and expensive devices on this system vs. only few models and a tightly controlled environment with iPhones. But such exploits exist for iPhone too.

With physical access it would also be possible to manipulate the device in a stealthy way in the hope that the owner does not realize that the device was manipulated and enters the passphrase which protected the device. Such manipulations might be software or hardware based keyloggers or maybe some transparent overlay over the touchscreen which captures the data or similar modifications. This can be done both for switched off and switched on devices but a successful attack requires that the owner is unaware of the changes and will thus enter the secret data into the device. Such attack is also often called evil maid attack since it could for example be done by the maid if one leaves the device in the hotel room.


If we can no longer trust NIST, what are viable alternatives?

You could try trusting the past. When Feistel and Coppersmith created Lucifer at IBM back in 1973, the NSA helped them strengthen it by providing better values for the S-boxes and adding the staggered bit shifting between rounds. They did this before IBM released it and it became DES.  The NSA later acknowledged improving DES was a big mistake. (At the time, we thought the bigger mistake might have been the revelation that the NSA understood differential cryptanalysis 20 years before the civilian mathematicians figured it out.) While the key length of DES is still too short and attacks over the years have significantly weakened it, 3DES remains a sound implementation built on solid theory, even if it is a bit slow.

Keep in mind that most attacks described in the articles published so far appear to be on the end points, where security is weakest. Even the NSA must follow a budget, and wouldn't expend the resources to brute force every SSL session key ever used; at least not when hacking a target's PC is so much faster and easier.


Upgrading to latest software version for security reasons

There is no absolute, consensual and systematic convention for versioning. Every vendor numbers his successive product versions as he sees fit. I mean, even Microsoft decided that the next version after "2000" was "XP", followed by "Vista", then "7", then "2008". I do not know what logic this follows, but I doubt it is from Earth.

Usually, vendors try to adhere to a scheme where products have releases (each new release possibly making some substantial changes with regards to the previous release) and releases have sub-versions which are limited to bugfixes, including (most importantly) security fixes. Hence, my wild guess is that upgrade to version "2.6.7" of your software should fix security issues which are known to impact version "2.6.2" (if there are any), but not bring any new feature, and should (hopefully) be easy to apply. On the other hand, upgrading to version "2.8" is switching to a new product line, with new features, and this may break compatibility with the rest of your system, which has been configured to talk with version 2.6.

Note that some vendors of widespread software do not follow such a scheme. In particular, Web browser vendors (in the case of, at least, Firefox and Chrome) tend to follow the simpler scheme known as "use the latest version or die". Version numbers are then meaningless integers whose only merit is to be bigger than the version number of the competitors (fortunately, there is no shortage of natural integers).

But you really should see what the vendor documents about his versioning system, since each vendor has his own conventions. As @RoryAlsop explains, this documentation can take several forms, including changelogs; and, of course, testing is paramount: don't upgrade any critical system until you have some good indications that the new version actually does the job...


I understand online PDFs are prone to malware.

Do you have a reference (or some background) for this statement?

As discussed in this question, a PDF certainly can be made to include malware, but I am not sure they are any more prone to malware than other file formats, e.g. flash, or Word/Excel/etc. Or .exe, .js, or other files you find online.

A big question here too is where your files come from: if they are from users, then you have the generic issue of dealing with arbitrary file uploads (see e.g. Should text files or image files be virus scanned during upload?).

If you are generating these PDFs yourself, then I would instead ensure that users can verify the integrity of what they download, for example by making a checksum available, and possibly by using GPG signatures.

I think the answers to your questions would require you to give a bit more background about your situation, and if possible, some idea of what risks you are specifically trying to guard against.


Is there a way to safely exchange two different informations like a sliding door?

I'm not sure what "security jabba jabba" is, but in terms of exchanging physical or virtual goods when your medium of communication is the Internet, typically exchanges like this are arbitrated by an escrow service, of which there are dozens.

There are certain special cases which can be automated in a fashion, but you'd have to come up with a specific usage case if you wanted more specifics.


What does a HTML filter need to do, to protect against SVG attacks?

I am one of the authors of this paper you linked. And I noticed, that some of the advice given in this thread is well-meant and well thought but not 100% correct.
For example, Opera is not providing reliable safety when dealing with SVGs embedded via <img> or CSS backgrounds. Here's an example for that, just for fun, we created a SVG embedded via <img> that would contain a PDF that would open a skype: URL that would then call you:

http://heideri.ch/opera/
http://www.slideshare.net/x00mario/the-image-that-called-me

We created the SVGPurifier - a set of rules that extend the HTMLPurifier to be able to deal with cleaning SVG. Back when we wrote those rules (you can have them if you want - let me know and I'll put 'em on Github), every browser we tested treated SVG differently. Also strongly dependent on the way it was embedded: inline, with <embed>/<object>, <applet>, <img>, SVG in SVG, CSS background, list-style and content...
It turned out that it was possible, to find a harmless subset in SVG if you threat model mainly involved XSS and beyond. If your threat model nevertheless also includes for instance mitigation of UI overlaps, side-channels, history stealing attacks and what not it gets a bit harder. Here's for example a funny snippet showing, how we can cause XSS with very much obfuscated JavaScript URI handlers: http://jsbin.com/uxadon
Then we have inline SVG. In my personal opinion, this was one of the worst ideas W3C/WHATWG ever had. Allowing XML documents inside HTML5 documents, forcing them to comply with HTML5 parsing rules and what not... security nightmare. Here's one gripping example of inline SVG and contained JavaScript that shows, what you'd be dealing with: http://pastebin.com/rmbiqZgd
To not have this whole thing end up in a long lament on how terrible SVG might be in a security/XSS context, here's some advice. If you really and still want to / are working on this HTML filter, consider doing the following:

Give us a public some-test where we can hammer that thing.

Be flexible with your rule-set, expect new bypasses every day.

Make sure to know what the implications of filtering inline SVG are.

Try to see if the HTMLPurifier approach might be the best.
White-list, don't black-list.

Avoid reg-ex at all costs. This is not a place for regular expressions
to be used.

Make sure that your subset only allows those elements, that have been
tested for security problems in all relevant browsers. Remember the
SVG key-logger? http://html5sec.org/#132

Study the SVG-based attacks that were already published and be prepared to find more on a regular basis: http://html5sec.org/?svg

I like the idea of someone attempting to build a properly maintained and maybe even working HTML+SVG filter and I'd be more than happy to test it - as many others as well I assume. But be aware: HTML filtering is damn hard already - and SVG just adds a whole new layer of difficulty to it.


How are hashing algorithms useful if the implementation is public?

Being public is exact the point: you show everyone how it's done and how difficult it is to reverse it. It's like showing you a ginormous jigsaw puzzle with a trillion pieces, but with every piece in its place, and shuffling everything down. You know all the pieces form the puzzle (you just saw it), and you know it's very, very difficult to put everything back. A public hash shows you how it's done (the result) and how difficult is to do everything in reverse.

A public hash function is just a set of mathematical operations. Anyone can (but only a few will) do the operations by hand and prove that the algorithm works as expected. Anyone can reverse it too, but it takes so much time (trillions of years with all computing power of our planet combined) that the most cost-effective way to reverse it is a bruteforce.

Unless it's a pretty basic insecure hash function.


In addition to your list:

Uncontrolled subdomain

Your site runs on example.com although the attacker controls bob-usercontent.example.com. This could either be through poor design or a server admin has created a subdomain for a user unaware of the vulnerabilities this opens with cookies.

Attacker sets their website to output the header:

Set-Cookie: sessID=1234; Domain=example.com

and then entices their victim to visit bob-usercontent.example.com. This could be any resource, including an image embedded on another site.

When the user then goes to example.com and logs in, the cookie will log in the attacker.

Insecure subdomain

Similar to the above, but this time there is no design flaw.

static.example.com contains a DOM based XSS vulnerability (for example).

Attacker entices user to visit

http://static.example.com/page.html?name=<script>document.cookie = "sessID=1234; Domain=example.com";</script>

(Of course the name parameter would be percent-encoded, but left as is here for readability.)

When the user then goes to example.com and logs in, the cookie will log in the attacker.

Lack of HTTP Strict Transport Security policy

User visits arbitrary websites over HTTP.

Man-In-The-Middle attacker intercepts one of these requests and redirects it to http://example.com. Attacker also intercepts this request and responds with their own page that sets the following header:

Set-Cookie: sessID=1234

When user visits https://example.com, the cookie is already set and upon login the attacker is logged in. More on HSTS here.


If anything, there are several different types 'prey' you can attract.  First, there are tons of bots out there automatically running port scan on different ip ranges to enumerate vulnerable services.  So, to attract bots and such, it's important to look like a "old and injured prey."  Run as many vulnerable services as possible to attract attacks from those bots.  One caveat is some providers to upstream blocking.  So, if you're running your honeypot on such a provider network, you may not see these scans.

If you want to be subject to "script kiddie" type attacks, then posting your IP on boards as well as a massive flaming campaign on boards/IRC rooms will help you attract attention.


Steganography concept - How to check my implementation?

To test your software you need to be able to recover your hidden message.  The essence of an effective steganographic method is that it be consistently reversible.  You should be able to remove the masking image in your case.

This answer on detecting steganography may provide some insight into testing approaches:

  To detect Steganography it really comes down to statistical analysis
  (not a subject I know very well).    But here are a few pages that may
  help you out.

  Steganography Countermeasures and detection

  Wikipedia page worth a read to cover the basics.

  An Overview of Steganography for the Computer Forensics Examiner - Has
  quite a long list of tools and some other useful information.
  Steganography Detection - Some
  more information about Stegonography.
  Steganography Detection with Stegdetect - Stegdetect is an
  automated tool for detecting steganographic content in images. It is
  capable of detecting several different steganographic methods to embed
  hidden information in JPEG images. Tool hasn't been updated in quite a
  while but it was the best looking free tool I could find with a quick
  search.

SOURCE: https://security.stackexchange.com/a/2145

There are a few common strategies for performing steganography:

Least significant bit insertion
Masking and filtering
Algorithms and transformations: taking advantage of the native format's own compression algorithms

SOURCE: http://www.infosyssec.com/infosyssec/Steganography/techniques.htm

There are several papers on this topic including Hussain, Mehdi, Mureed Hussain, A Survey of Image Steganography Techniques which discusses different techniques and introduces terminology:

  Cover-Image: Original image which is used as a carrier for hidden information.
  Message: Actual information which is used to hide into images. Message could be a plain text or some other image.
  Stego-Image: After embedding message into cover image is known as stego-image.
  Stego-Key: A key is used for embedding or extracting the messages from cover-images and stego-images


What is the main difference between Wireshark and Network Miner?

NetworkMiner is a great tool for automatic extraction of files from a packet capture. It's also surprisingly useful and good at extracting messages such as emails. What it isn't any good for is manual packet analysis, which is where Wireshark shines.

See here.

Within that link, it's a short post from reddit with someone who asked a similar question. I feel that was the best answer on there for you, and I have some personal knowledge to include.

Wireshark is a very good tool to analyse packets between your network and a specified network that you're monitoring. It's especially powerful if you know how to identify network protocols such as TCP, DNS, SFTP etc. It's filtering system is also very useful, and as stated in the above quote, NetworkMiner is especially good for message extraction and I also believe it is good for MITM network monitoring.


Ransomware-resilient Linux Samba file server

I think backups are your only sure bet. What you suggest as a solution basically consists of making a special backup; I'd suggest you just keep several (at least two) full backups around. The problem is then reduced to detecting ransomware working on your files and recovering from the last good backup. You can use deduplicating backups to save space. The advantage of going the backup route is that

you introduce less complexity (no additional system just for ransomware)
you improve the quality of your backup routine - once you're automating alerts and recovery, you've put in place a lot of stuff to make backup recovery a breeze. That's good for a much broader category of failures than just ransomware.

As for detecting ransomware, that's easy: Encrypted files all look like random data, so you can simply do statistical tests for each file (equal distribution of bytes? not compressable using zip? etc) and count the number of files that look random.


In the perspecive of online-attacker, then FDE is nothing. FDE is designed to protect against a offline attacker who copies your drive or steals your computer. Once the FDE is "unlocked", it will be accessible, regardless of if the computer OS is locked (Win+L) or whatever. The only thing that can protect against online attacker is good security in the form of firewalls, IPS and anti-virus software.
The only way you can "lock" a FDE is to shut down the computer fully. Even Bitlocker wont "lock" when your inside Windows, only bitlocker does, is to ensure the boot path is uncompromised Before allowing decryption (secure boot + TPM), thus preventing circumventing the windows login process. If there security holes allowing online access to your data while your computer is logged off or locked, then your'e busted anyways.

Also encryption of indivual files is a good protection, provided you dont get a keylogger. Then you are smoked anyways. The most secure way you can protect a file against online-access, is to store it on a USB memory that is normally NOT connected to computer. Of course, you need to check everytime your computer is NOT compromised Before connecting this USB-drive. For the paranoid, I would suggest booting in a known secure OS, for example a OS that is placed inside a USB memory with a physical read-only button, or a live-CD. You dont need to encrypt the file if your threat scenario does not include offline attackers.


If HTTPS only runs on a single port, why is SYN flooding an issue?

Sending to every port is overkill; to quote the same article,

[The server] responds to each attempt with a SYN-ACK packet from each open port.

So it is only open ports that matter, because if they receive a SYN they will wait for an ACK response to their SYN-ACK.  It is the resources consumed by such a "half-open" connection which get exhausted.  And in fact, with enough SYN packets, it is possible to SYN flood a server even if the only open port is the web port.  So limiting traffic to that one port is not enough protection if the attacker can pump enough SYN packets in.


Books on Cryptography, with a focus on application to Network Security?

Check out Practical Cryptography:
http://www.amazon.com/Practical-Cryptography-Niels-Ferguson/dp/0471223573/ref=sr_1_1?s=books&ie=UTF8&qid=1304454787&sr=1-1

  Written by Niels Ferguson, lead cryptographer for Counterpane, Bruce Schneier's security company, and Bruce Schneier himself, this is the much anticipated follow-up book to Schneier's seminal encyclopedic reference, Applied Cryptography, Second Edition (0-471-11709-9), which has sold more than 150,000 copies.


nvd json database without vendor and product info

Welcome to the messy of InfoSec community! :)

Unfortunately, when dealing with NVD data feeds only is common to get frustrated with either issue like that or any of the entry CVE update delay such as CPE and Status process (i.e., Analysing; Confirm; Rejected; and, Reserved).

That's why companies and nonprofits organizations, create their vulnerability identifications. The IBM X-Force (without acronym prefix) and SecurityFocus as BID (Bugtraq ID) are the greatest examples respectively.

  What is the supposed correct way to find corresponding product and
  vendor information for such cve's [sic]?

Answer: Add the CPE manually. You can contribute with NVD CPE Dictionary as well mailing to the NVD CPE team (the e-mail is in 2nd paragraph).

If you need more details about the vulnerability information:

According to the MITRE vulnerability report3, every CVE entries firstly raise from the MITRE's platform(s) when you request a CVE ID from a CVE Number Authorities (CNA) member, commonly MITRE CVEForm unless you contact with others CNA affiliate.

Usually, before a CVE-ID get CONFIRMED status, the Window Vulnerability must be completed. That is a concealed process which summarized in:

Vulnerability Found;
Vulnerability Reported;
90-days to whether the vendor answer back;

If the vendor doesn't answer the one who discovered the vulnerability in 90-days, the discoverer can do whatever he wants, including publishing the security issue information along with the exploit. Ordinarily, this sort of report happens on the SecList, PacketStorm or any other of the social platform such as Twitter and Blog post;
After vendor responding within 90 days, there is no predictable date for a vulnerability coming to the public from a foreign perspective because the communication is between the one that discovered the vulnerability and the vendor;

Assuming that the vendor answered, the final step is the release of the patch and the vulnerability detail.

MITRE Corporation is an American organization affiliated to Federally Funded Research and Development Centers (also known as FFRDC). The CVE-ID is a system provided by FFRDC that is operated by MITRE Corporation, and as you can see, their deeds are commonly chosen to standardize across the entire spectrum of security tools and services (Information Security Communities).

The NIST National Vulnerability Database (NVD) is a United States America government repository database to provide vulnerability management data for Security Content and Automation Protocol (SCAP) supplying. One of their products is the CPE dictionary, and their "CPE Dictionary Search" is the same as what he's providing in the XML file.

Have you noticed that each vulnerability information regardless of MITRE Corporation tends to a piece of miscorrelation?

Notwithstanding a CVE-ID can take a while to CONFIRM a reported vulnerability if a vendor does not confirm first. The other sticky situation, if you monitor MITRE CVE publishing entries and recognize when a CNA member release a CVE, you can note that the utmost occurrence of until a vulnerability becomes publicly.)

So, as I aforementioned: This miscorrelation tends to happen every time. That's is the principle of why working with only public information always dealt with a false positive and false negative.


What are the enhancements of SHA1 compared to MD5?

Cryptographic hash functions are objects which try to fulfil some properties (namely, resistance to collisions, preimages and second preimages). An algorithm which fails at offering these properties is said to be "broken" and, by definition, should not be used in protocols where the unfulfilled properties are needed.

MD5 is broken (for collisions). SHA-1 is not (at least, not as much). If your protocol requires resistance to collisions, then don't use MD5. E.g. some researchers have managed to make fake certificates by using MD5 lack of resistance against collisions.

Right now, SHA-1 is "slightly weakened" with regards to collisions, but not sufficiently so that producing an actual collision has been done. It would take a substantial amount of time and computers (months, thousands), hence quite some money. A contrario, MD5 collisions can be generated in less than one second on a basic PC.

SHA-1 is slightly slower than MD5 when processing bulk data, which does not matter as much as is usually believed. When a basic PC (again) hashes big files, the hashing part is actually three times faster than the reading-from-disk part when using SHA-1. That MD5 is about 40% faster than SHA-1 won't actually matter, since the bottleneck is the disk, not the hashing.

SHA-256 and SHA-512 are the currently recommended general purpose hash functions. They are slower than SHA-1, but still "fast enough" for most purposes. They don't have known weaknesses (even theoretical weaknesses).


Are there any simpler ABAC implementations available for big data systems?

Yes there is at least one.

Disclaimer - I work for the company, Axiomatics, that provides it.

Axiomatics has a solution called ADAF MD (Axiomatics Data Access Filter MD) which currently supports Oracle, DB2, MS SQL, Terradata, and others will be added soon. The solution builds on top of XACML, the eXtensible Access Control Markup Language, which is the de facto implementation of ABAC.

You can check out the demo on YouTube. You can also watch this webinar on ABAC and this webinar on data-centric access control.


How to know if my router has been hacked?

There is a good chance that your router itself has not been hacked. By default, ISP routers usually heavily restrict inbound connections from the Internet.

  but I keep seeing accesses to my social medias by devices who seem to be mine but I
  nor everyone else in my family used lately

All social medias? What kind of access are you seeing?

My advice would be to change your social media passwords immediately and wait to see if the mysterious accesses stop.


One problem you could have with this kind of setup is, from what you've said, it looks like the session token would be static (ie for a given user, it never changes, until they change their password).  As such if an attacker manages to get access to a token for a given user (trojan, keylogger, packet sniffing (if SSL isn't used) etc), they will have persistent access to the application.

Also you'd need to be more careful than usual to ensure that session tokens aren't logged anywhere server-side as they'd essentially be as good as passwords.


Do I need a salt when hashing a randomly generated password?

The purpose of salting when hashing passwords is to prevent identical passwords from resulting in the same hash values.   If your passwords all are, as you say, long and   generated by a CSPRNG, then you will not have identical passwords in your database for different users; they will all be unique, and salting adds nothing to the security of these passwords.

However, there may be a caveat.  And that is, if you have some passwords that are non-random.  I.E., if the random passwords you generate are initial passwords, but users have the ability to choose a different password.  If this is the case, then you should more certainly salt your passwords, including the randomly generated ones.   There are two reasons for this.

Adding branching logic to salt some passwords but not others is unnecessary complexity, and unnecessary  complexity is expensive and evil.  By salting everything you're neither reducing nor increasing the security of the random passwords, but simplifying the application logic and reducing the chance for bugs, security or otherwise.
This could drastically reduce the security of the non-random passwords.  If your scheme is known and the hashes and salts are extracted by an attacker, they will immediately be able to determine which passwords (the salted passwords) are not random generated, and should be attacked.   If all passwords are salted, the random passwords will be indistinguishable from the user-defined passwords.


Authorisation Request & Authorisation Grant In OAuth 2.0

The OAuth2 RFC is extensive and covers numerous use cases. Since your question is pointed towards the most common use case, that is the 'Sign in with' button, we will just talk about that.

Let's get the roles right first:

User: The owner of the resource. For instance, user owns an email amey@example.com.

Client: The application requesting information owned by the user. This is the application hosting the button 'Sign with XYZ'

Resource: The information that is being requested by the client. The client may want access to your email, your date of birth and your profile picture.

Authorization Server: The server responsible for authorizing client's request to access a user's resource.

Resource Server: The server which holds the user's resource and will transmit it to the user when presented with a valid credential.

The OAuth2 setup:
An application that wishes to access user information or resources hosted on a resource server should first register with the authorization service of the resource. The pieces of information that are necessary for this step are:

Client FQDN
Client's callback or Redirect URL

On successfully registering with the authorization service, the client receives a clientId which it will to send to the authorization server during the authentication process.

The Authentication Process:

Let's say user wants to prove to a client (say, client.com), that they are the rightful owner of the email amey@example.com.

Step 1: User clicks on "Login with example.com" on the client website. Let's call it client.com.

Step 2: This spawns the OAuth2 authentication flow. The resource server's OAuth2 URL will be called with the following paramters:

clientID
Redirect URL
state (randomly generated nonce, not mandatory as per OAuth2 but commonly used)
type (code is most commonly used, and that is the least you need to know to get started. More on this below.)
scope

The URL will look something like this:
https://example.com/oauth2?state=018aed36-8f70-4fcb-a49f-0eba5cee22ff&redirectURL=https://client.com/oauth2/callback&scope=email+profile.info&type=code

Step 3: The authorization server performs the following checks on the request before presenting an authentication dialog to the user:

The referrer header in the request correctly corresponds to the clientID as registered by the client during setup.
The redirect URL correctly corresponds to the clientID as registered.
The scope of information requested is acceptable to the authorization server. This may be based on information provided during registration or some other factors.

Step 4: The authorization server presents the user with an authentication dialog. On successful authentication, the authorization server generates a random code. Remeber, the type paramter in step 2 above? The type=code parameter tells the authorization server that the client expects a one-time authorization code for the current OAuth2 authentication request. This is not the final authorization token. Authorization codes are short lived and they provide a layer of additional security to protect the authorization token that will honored by the resource server. The code by itself will not be of any use to the an adversary.

Step 5: The Authorization Server redirects users browser to the redirect URL of client.com that was included in the first OAuth2 call in Step 2 above and attaches the code parameter along with the state parameter with the request (typically in the URL query)

The redirect URL will look something like this:
https://client.com/oauth2/callback?state=018aed36-8f70-4fcb-a49f-0eba5cee22ff&code=3b9d8826-55b5-4e0a-b441-3137c2e9f864

Step 6: When the client.com server receives this request, it makes a call to the Authorization Server and sends the authorization code received from the user's browser. The Authorization Server responds to this request with an Authorization Token which can be used to request information for a user as per the agreed scope.

Step 7: client.com's server makes a call attaching the Authorization Token to the Resource Server for fetching the user's email address. The Resource Server in turn sends a request to the Authorization Server again to verify whether the token is correct and the requested resource is within the scope of the authorization. Once authorized by the authorization server, the resource server sends the requested resource, in our case, the user's email address (amey@example.com) to client.com's server. Once, the client.com server receives this information from the resource server, it can happily conclude that the user is the rightful owner of the said email address. The server sends a cookie or any other token it uses for maintaining the client session and allows the user to use client.com's application.

Steps 6 & 7 are hidden from the user. The communication takes place directly between the client's server and the resource server. So, it can be confusing at first to imagine what is happening on the backend while you are waiting for a response from the client.

You can take a look at the below image, to get a descriptive flow of the process:

Image Attribution: https://medium.com/@darutk/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85

Would also help to read this blog post for even better clarity.


Is salted MD5 or salted SHA considered secure?

MD5 and SHA-1 are emphatically poor choices for storing passwords. The problem is not their collision-resistance; it's that they're designed to be extremely fast. A modern GPU can attempt upwards of billions of passwords per second when brute-forcing through a list of hashes. This can shred through every possible eight-character alphanumeric password in at most a few days; that's with just one GPU.

The advantage of bcrypt and scrypt is that they can consume arbitrarily many resources; bcrypt has configurable CPU requirements, scrypt has configurable CPU and memory requirements. By increasing these work factors, you can dramatically increase the amount of effort it takes an attacker to attempt even a single password in your database.

As to the length: it's 2014. Storage is essentially infinitely cheap. Saving 40 bytes per record is simply not an acceptable excuse for selecting known-poor password hashing algorithms. In whatever project you're working on, surely there are more worthwhile tasks to spend your limited development resources on than this.


Unauthorised access to admin area of a rails app, from the company's IP

With respect to the IP address logged in your apache log, there are a number of possibilities that do not necessarily indicate that it came from somewhere within your network.

Firstly, if an external attacker has complete control of your server, it is possible that they could fake the log entries.  Secondly if an attacker has control of a local PC, they could use that to make it look like an internal attack. Finally how do you know who was on the local PC at the time?

Real attribution is hard, and as a result you will need more evidence to determine what really happened.  If you have other network traffic logs that are time synced you could start to build up a picture of what was happening at the time of the attack.


SSL TLS renegotiation vulnerability - current situation in clients

All current versions of the major browsers (IE/FF/Chrome) are actually patched with the fix for secure renegotiation.

The ssltls.de site has some problems it seems, as I went to it using different browsers, different network connections, and I got inconsistent results. Wireshark shows the browsers sending the extension and server replying to it, so it seems the test can be improved to better detect the extension.


How to sniff Bluetooth traffic using Android?

I'm not aware of something that would turn your Android bluetooth radio into a sniffer. I think you would need to invest in an Ubertooth to accomplish what you're looking for.

http://ubertooth.sourceforge.net/
http://hakshop.myshopify.com/products/ubertooth-one

With the ubertooth you'll be able to sniff the bluetooth packets between your arduino devices.


Does using the Google Maps client-side Javascript API leak data?

According to Google maps API's Terms of Service agreement, Google has a right to obtain information from  you, when you use Maps JavaScript API. Basically, when using the JavaScript Maps API, the following information is sent to Google:

  Map size and location for retrieving map tiles and copyrights
  Addresses for geocoding
  Direction and Elevation requests
  Locations around which to search for Places
  KML when using KmlLayer

Source: Google Maps FAQs


Onus and user experience
Extensions with NPAPI mean that the browser and it's extension ecosystem are the source of malware, and are then responsible for combating it. Did extensions using this feature even need to disclose it?
On the other hand, launching a protocol handler is a very straightforward UX... it requires a user gesture each execution unless the user explicitly chooses to permanently allow. Prompting "Open something.exe?... example.com wants to open this application" signals to the user that they're making a choice right at this very moment to allow the browser to launch a different program.
Additionally, the custom protocol handler had to be installed on the machine outside of the browser ecosystem, which means it had to gain user trust on its own accord, not thru the app store where people might be lulled into a false sense of trust (e.g. "...it's on the Chrome web store so it must be safe...").


Security risk of letting someone else setup an account for me using an email address I own?

Let's start with the general case...

The email in usually the main verification point for an account, so since you control the email address it would be difficult for someone else to reset the account or take action without you knowing. However, there are a few possibilities:

Poor session management by the service: If your friend logged in with the account and never logged out, even if you changed the password he could still remain logged in. A best practice for the website would be to invalidate all active sessions when a password is changed
Account recovery which can bypass email: Some services allow you to reset and regain control of the account with a backup email, a phone number, or by answering challenge questions
Social Engineer Support: If there is a human element there is always the chance that via email, live chat, phone, etc. someone could social engineer their way into gaining access to their account if they know enough information

In the case of steam, you can review their account recovery FAQ. From an initial read it looks like you may be able to recover an account with key information and without email access, but I have not gone through the process to try it out.

Steam offers a 2-factor authentication option, which could help to prevent these types of attacks, but I am not sure how they would handle attempted social engineering when the attacker claimed they lost access to the 2-factor solution. Check out Steam's guide to securing your account.

In general, I would not recommend having other people setup your account on your behalf.


What is the different between CMP and SCEP protocol?

CMP is a generic protocol which aims at covering most (if not all) network exchanges involving a Certificate Authority; e.g. it includes messages for a CA who wants to announce that it has a new key pair. The protocol is rather complex, and has been around for quite some time (first published version is from 1999).

SCEP is a specialized protocol which has a smaller scope; it concentrates on enrollment and CRL obtention, and is definitely client/server (all messages are requests sent to the CA, and responses from the CA, while CMP allows for CA-driven exchanges). SCEP is not a formal standard; it is not even a RFC but still a draft which is 1. expired, and 2. destined to become an "historic" RFC. SCEP, though, is a big de facto "standard" by being what Cisco hardware tends to do.

The second paragraph of the latest SCEP draft says it all, so let me quote it in extenso:

  This specification defines a protocol, Simple Certificate Enrollment
     Protocol (SCEP), for certificate management and certificate and CRL
     queries in a closed environment.  While widely deployed, this
     protocol omits some certificate management features, e.g. in-band
     certificate revocation transactions, which can significantly enhance
     the security achieved in a PKI.  The IETF protocol suite currently
     includes two certificate management protocols with more comprehensive
     functionality: Certificate Management Protocol (CMP) [RFC4210] and
     Certificate Management over CMS (CMC) [RFC5272].  Environments that
     do not require interoperability with SCEP implementations SHOULD use
     the above-mentioned, PKIX-standard certificate management protocols.
     In light of the functionality gap between this specification and the
     two IETF standards track protocols, this specification is being
     published as Historic.  Even when interoperability with the installed
     base of SCEP implementations is needed, implementers are encouraged
     to support one of these comprehensive standards track certificate
     management protocols in addition to the protocol defined in this
     specification.  This implementation strategy balances near-term
     requirements for interoperability with longer term security goals.

So there you have it: you are encouraged to support and use CMP, and you should envision SCEP mostly for compatibility with legacy deployments, and even then you know that SCEP won't do everything that can be done with CMP.


If so, are they due to host architecture ...

Yup.

From the talk: "times three, because there are three combinations between endianness and bitness".

From the Debian wiki (archived here): (text reformatted by me)

  The broken version of OpenSSL was being seeded only by process ID.

  Due to differences between endianness and sizeof(long), the output was architecture-specific:

  little-endian 32bit (e.g. i386),
  little-endian 64bit (e.g. amd64, ia64),
  big-endian 32bit (e.g. powerpc, sparc).

  PID 0 is the kernel and PID_MAX (32768) is not reached when wrapping, so there were 32767 possible random number streams per architecture.

  This is (2^15-1)*3 or 98301.

.

  Can they be generated from the known set of 32768?

Dunno. Don't think so. Debian has packages for them: (text reformatted by me)

  Scope of the blacklists

  The current official blacklists (in openssh-blacklist) cover RSA-2048 and DSA-1024 keys as generated on 32-bit little-endian, 64-bit little-endian and 32-bit big-endian systems. That's sufficient to cover users who used the default key length, but not if some of your users decided they wanted a longer keylength.

  For non-default keys, see openssh-blacklist-extra which contains RSA-1024, RSA-4096, and (an empty) DSA-2048 for all three architectures.


AWS IAM policies that differentiate between console & access key access

Apparently I can't.

AWS does not differentiate between access key and console password authentication. There are some temporary credentials and 2FA IAM policy conditions, but they do not fit our use case.

One can use some IAM conditions to fit my or similar use cases, but not the way I planned;

the UserAgent condition to differentiate between cli, browser and sdk users. BUT BE WARNED, it can EASILY be tampered with, this is NOT an airtight control.
the sourceVpc condition
(apply a global 2FA policy and exclude anything from your VPC, that way applications running with AWS IAM user access keys aren't disrupted. Yet I know they shouldn't be, but they are);

"Condition": {
         "StringNotEquals": {
           "aws:sourceVpc": "vpc-111bbb22"
         }
       }


You should not plug a washing machine into the same power strip as your computer or put a large number of switches in series unless you want to burn down your house. With that said...

Mitigating power analysis attacks can be easy or hard depending on the adversary. If they are simply measuring power usage, you can mitigate it by using an online double-conversion UPS. That is a UPS which simultaneously charges and discharges a single cell to ensure zero latency during blackouts or brownouts. They are less efficient than standard line-interactive UPSes (which simply pass through power from the wall and switch to internal power when the voltage drops below a threshold), but they will mitigate simple power analysis attacks because the power you are getting comes directly from the inverter, not mains. If your adversary is outside of your house, it's unlikely that this is necessary anyway, as sensitive power usage information tends not to pass through the first large transformer, if memory serves. Even abusing a compromised smart meter right outside of the building is quite unlikely to be useful for power analysis.

If your adversary is particularly advanced or will have a probe connected very close to the computer, you will unfortunately not be able to mitigate a sophisticated attack with COTS hardware. You would need to have special hardware designed for EMSEC. In particular, you would likely need to have a NATO SDIP-27 (TEMPEST) certification for any hardware you are using in order to ensure that no compromising emanations are released.

  Therefore it will become undetectable from poweranalysis, because the power waves overlapse and the spikes (caused by crypto operation) will become undetectable from the spikes other devices do.

This unfortunately does not work. It's the high frequency domain (300 MHz and above, typically) that is relevant for EMSEC. It will not at all become undetectable simply by turning on other devices. In fact, it might actually make it worse by effectively creating antennas. Even a dozen other computers using the same power source can't mask a single 8051 microprocessor in a cheap PS/2 keyboard when subject to power analysis attacks. EMSEC is complicated. You can't mitigate it just by plugging in other devices and simply hoping they mask the high frequency domains.

The above animation demonstrates how the addition of multiple sine waves in different frequency domains can add up to a seemingly chaotic pattern. In truth, it's easy to analyze such a waveform and extract each and every frequency domain. Plugging in other machines adds to the low frequency domain. It's then a simple matter of performing Fourier analysis on the waveform to extract the completely undamaged high-frequency information being leaked.

Even when you have absolute control over the frequency you add, it is still extremely difficult to mask an existing signal. Just ask anyone who has tried to jam a DSSS signal without being able to predict the sequence. And in your case, you aren't even creating high-amplitude interference. You are turning on another machine which is designed not to cause interference and undoubtedly does not send a strong jamming signal in all the right frequencies!


Is it safe to have a DNS record pointing to 127.0.0.1?

Is it safe to do this?

I see no security problem with this.

  Is there anything that can go wrong?

Possibly, though I am not sure I understood this correctly:
Has each developer their own development server and does each one work on their own local copy? Then this will work fine.

However if there is only one dev. server and you use this as your workstation then this might not work as expected since 127.0.0.1 is local host. As in each developers own localhost.

In ASCII graphics:

                                           Assigned IPs:
Your own computer                          127.0.0.1
(with dev.server)         -----------      ::1
                                           'Normal' static or DHCP assigned IP

Other developers computer                  127.0.0.1
(Just a workstation)      -----------      ::1
                                           'Normal' static or DHCP assigned IP

If the other developer tries to access dev.mydomain.com then DNS will successfully translate that to 127.0.0.1. No need to add anything to the hosts file. But the other developer will not arrive at your dev. server. Localhost for him or her will be local.


Apache Mod_Proxy Remote Negative Content-Length Buffer Overflow Vulnerability

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


Bypass with wrong cvv of debit card and getting OTP

But shouldn't it suppose verify before I get the OTP? What's the
  reason, Isn' it a security issue?

This is absolutely NOT a security issue! quite the opposite it's a protection.

Lets go through the steps.

You put in card details.
You put in CVV
You put in the OTP.

The payment is processed if and only if the combination of all of it are correct.

Now assume a scenario where it tell's you the CVV is wrong before the 2FA that is just going to simply give the attacker a chance to better attack.Now the attacker knows the CVV is wrong and can simply change that.While in the correct scenario attacker will have to break 2 Factor authentication to gain that information


Where to get/buy a CSR generated S/MIME certificate

The theory is that as long as you keep your old keys, your email software will still be able to decrypt your received emails. That the certificate is expired means that other people won't accept to use your old public key to send you new encrypted emails, but reading your mailbox on your side does not entail using your public key or your certificate, only the private key. In other words, certificates expire, but private keys do not. Note that usual email software indexes keys by certificate (they have a certificate, and the certificate links to the corresponding private key) so you'd better keep the certificates around, even if expired.

Under this theory, there is no problem in generating a new key pair whenever you want a new certificate, except maybe storage space for accumulated private keys. One RSA private key would take less than 2 kB, so once key every 3 years will not fill your disk up any time soon. However, this may be an issue if you keep your private key on a smart card: smart cards are not eternal and not easy to backup, so they imply a risk of key loss (and thus data loss). Reusing the same key pair for a new certificate, instead of generating a new one, will not help for that, anyway.

Professional CA are supposed to follow their Certification Practice Statement which often requires new keys for certificate renewals. This requirement can be there for a lot of reasons, not necessarily good ones. One argument, for instance, goes thus: key cracking algorithms take time; by using a long-lived key (key life extending over many years and certificate renewals), you are giving more time to the attacker to break your key. This is not a very good argument because breaking an old key is already interesting for an attacker (it grants access to old emails), but that's a nonetheless widespread argument. Forcing new key pairs is also an easy way to enforce longer keys on a regular basis. Therefore, many CA will not easily accept a pre-made CSR.

Of course, you can potentially alter your browser's code (assuming it is open-source) to pretend to generate a new key, but actually reuse the previous one. The CA cannot really prevent that, unless it checks explicitly that your new key is distinct from the previous one.

Another facet of the issue is that encryption keys should be escrowed (i.e. backupped somewhere). Indeed, losing your private key implies using access to old emails encrypted with that key. So the storage policy for your private key is already complex, out of necessity. Enlarging that policy so as to be able to cover a dozen keys instead of one seems unlikely to be that much an issue.

Summary: while this does not answer your exact question, I would recommend that you do not insist on keeping the same private key across certificate renewal. Generating a new key pair ought to be fine, and it is at least arguable that changing the key is "A good thing". A one new certificate per 3 years, or even per year, it won't be "a mess" before your own demise (which we wish you to be as far in the future as possible).

Key life cycle management is a hard problem. Though simplicity is, all other things being equal, a good thing, there is a point at which too much simplicity begins to degrade usability or security.

("One Ring to rule them all" looked like a good idea at the time.)


Is there any alternative beside sending One-Time-Password via SMS?

Why can't you use TOTP or HOTP which is standard and supported by most authenticator apps?

When people register for your service they need to enroll their authenticator app by scanning a QR code which contains the secret seed used to generate codes.

On subsequent visits the site prompts them to enter codes generated by the app, without any network access since codes are generated locally on the device.

As a bonus, since you're using standard protocols your users may already have a compatible authenticator app installed, and if not, could nudge them into using the app for more services (their Google account, etc). In the end, users are more secure and everyone wins.


oAuth2 scopes and filter conditions in url

In Oauth2, you restrict the redirect_uri that can handle the login request the user is sent to after logging in at the authorization server (AS).

So you would register two clients with the OAuth2 admin, each with its own redirect_uri.  But this is a defense against someone stealing the authorization code as it is passed from the client to the API.

Restricting the data each client is server, is handled by using scopes, as you suggest.  I is usually best to have distinct API resources that serve the different types (restricted/unrestricted) data, and only give the unrestricted client the scope necessary to consume the unrestricted API.

Something like this:

/v1/api/basicdata - available with a "basic_data" scope which both clients get.
/v1/api/restricteddata - available with a "restricted" scope.


That looks to me like it would alert if it receives traffic from the defined external network ($EXTERNAL_NET) to your defined home network ($HOME_NET) where the TCP fin flag is set on it's own.

This could be taken to indicate a piece of scanning software, as in a standard TCP communication FIN isn't sent on it's own, it goes along with an ACK flack (there's more information here)


Why not use same certificate for webserver TLS and Signing in SAML?

There are a few different reasons. There isn't any one single answer, but they can all be grouped together as: because you're not supposed to use the same key for multiple things.

In this case it's more of a practical issue.

You have to time rekeying the TLS cert with the SAML cert, which can be painful.
Revoking one key means revoking the other.
If someone steals the key they can then impersonate both TLS and SAML.
If someone misconfigures the SP to validate the chain instead of the cert then anyone with a valid cert signed by that authority can impersonate.
etc.


Why do most ip camera manufacturers set an easy default password?

Cost.

Configuring a random password per device, and including this in the documentation (e.g. a sticker or similar) costs money. People don't check such things as security before they buy; the main bullet points for ip cameras tends to be video quality and things like cell phone apps.

Thus security doesn't really give an advantage to a manufacturer, and they ignore it. In essence they externalize it - the customer has to pay the price of poor security.


How robust is duplicity encryption when the backup server is untrusted?

From a strictly cryptographic sense, the Duplicity model does not have any weaknesses.

Duplicity is designed specifically for a threat model when the destination server is untrusted. It drastically improves incremental backups, because rather than transferring a diff of the already encrypted data, it sends new encrypted files, with a new key. There is no way to tell that one given incremental snapshot and another from a later date have any similarities. Each snapshot is a fixed size (25 MiB by default). From the perspective of an attacker, a new snapshot could hold 25 MiB worth of entirely new files, 25 MiB worth of incremental changes, or even 25 MiB worth of metadata (file deletion records and such). This is in contrast with a block device using XTS mode which tends to leak information when changes over time can be monitored.

Duplicity additionally signs files using GnuPG, which provides an integrity guarantee. XTS mode is often considered "poor-man's malleability resistance", but it really is very poor at that, allowing modifications with 16 byte precision. Duplicity's digital signatures ensure that even a single changed bit will be detected, even when using CBC mode.

Duplicity's backups are done in several stages:

rsync is used to compare differences between a cached record of files and your filesystem
tar is used to archive 25 MiB worth of incremental changes into a single file
gpg is used to encrypt and sign the tarball
the encrypted tarball is sent to the destination server all at once

While XTS mode provides a lot of information when changes over time are observed, all the destination server can see with duplicity is the amount of data changed. Say you take a 50 MiB file, back it up, then you modify half of it before backing it up incrementally again. If this is done with XTS, the precise areas which have been modified are visible. With duplicity, what you see is 2 encrypted 25 MiB files, and then later another encrypted 25 MiB file. You cannot compare the first backup with the second incremental backup to see what data changed. All you can see is how much changed.

The precise information the untrusted server can observe with duplicity is very limited:

the total amount of data stored
the amount of data transferred in each backup (roughly corresponding to the number of changes)
the approximate size of the total stored data (due to periodic non-incremental full backups)


When pasting sensitive links or text on Google Chrome bar - does Google store it?

The simple answer is "yes". Search engines store whatever is typed in the search bar. It has no way to determine what is sensitive or a password. It is all just text to the search bar.

In Google, not only will it be stored in their logs, but what people put in the search bar (not attributed to specific people) can be queried by other people.

In Chrome, whatever you put in the URL/search bar is stored locally in your account so that it can be provided to you as a short cut if you try to search for it again.

To help answer this question, I searched "what do people search for?" in Chrome, then started typing that search again:

So, as you can see, whatever is entered is stored, sorted, and categorized for later retrieval.


Is it possible to determine router firmware version as a Wi-Fi client?

The only way to interrogate in detail something like that would be to connect to the router using CLI, which for many routers is actually possible, but that would require the credentials of the router (or back-door credentials). This does not help much since the firmware version is most of the time displayed in the management GUI of the router also. Note that on some routers you do have access to the general information page without credentials, so this would be the only scenario where you could see a firmware version without admin login.


What is the real danger of not putting a login password in Windows in a small company except that of allowing anyone to go physicaly on your computer?

In a nutshell, besides physical, local access - there is no more of a risk of not having a password than having one. Besides, the obvious risk of anyone being able to walk up to your computer and log in.
There are a number of risks however that come from fraud and fraud prevention. Since anyone can walk up to any computer and log in, if anything malicious were to happen (and it does) you would have no way to prove who it was.
EDIT: if you're on windows 7 you can use autologin: https://technet.microsoft.com/en-us/library/ee872306.aspx
FRAUD AND FRAUD PREVENTION
Typically, an organization would have controls in place to prevent fraud from occurring in the first place. The idea being that the more difficult it is to prevent fraud, the more unlikely it will be that it will occur. I'll outline a rough scenario at the end if that helps clear it up for you.
A common control method is proper passwords, so that someone couldn't walk up to a computer, use it for some malicious activity, and then walk away. Keep in mind that this person may be from outside the company as well - ie. could be a repairman, could be an auditor, health inspector, etc. depending on your line of work, not just someone from inside the company.
SCENARIO
An organization has no passwords on their computers - An employee, Jane, was one of three employees let go due to work force reduction from a budget cut. Her job was to manage the company account for making purchases from new suppliers.
A few weeks after she was let go, her replacement noticed some irregularities in the accounts that she was in charge of. An internal investigation was launched, which found that almost $5000 had gone missing over the past 18 months. An external auditor was called in to assess the situation and a fraud investigator acquired them to find out what happened.
They discovered that the Janes computer was used to move the money, however it was always during her out of office hours. They also discovered that no-one in the company uses passwords on any of their computers, meaning that it could be anyone who would've had physical access during those 18 months. They also found from conducting an interview that Jane left with no issues, and left them with little reason to think it was her.
So who could it be?
SCENARIO 2
Same as above except employees use passwords -
They discover that Janes computer was used to move the money, and it was always during out of office hours. However it was not her login details that had been used, but rather the hiring manager for the floor.
An investigation was launched and found that he was having some issues at home with his spouse, which could be a potential motivator.
etc. etc.
The point being that in each of these situations, even with passwords being used its difficult to say who it was that committed the crime. However, in the case of scenario 2 - the hiring manager would have to explain why he logged in with his details outside of normal hours, or how his credentials had been potentially 'hacked'.
Hope that clears things up a bit. I can expand further if not.
EDIT: Just to add since @Sayan's point - it is known in security as non-repudiation - or being able to prove that something happened by whom


All of the recommendations start by telling you to disconnect the server from the Internet, something that might not be possible here. The problem is, a determined attacker can get round any changes you make "live" faster than you can change things.

One of your biggest problems is your reliance on 3rd party software such as CPanel. This shows regular vulnerabilities that would allow attackers to gain remote access and elevated privileges. Unless you can move your DNS and domain management functions out of CPanel and disable them there, I'm not sure you are going to be able to totally fix the problem.

I'd perhaps recommend moving that part of the service to a secondary server that doesn't use CPanel and has an absolutely minimal server install. Make sure all accounts have long passwords and don't connect the two systems until you have fully hardened the new server. You need to ensure that you have IPTABLES configured correctly and have moved any remote access to non-standard ports (don't leave SSH on port 22 for example or you will never be able to spot real problems in your logs from the constant hacking attempts.).

You also need to make all of your users aware of the ongoing problem. Keep them informed.

Also, did you change all your account passwords and certificates after you updated after Heartbleed?


In what situations can element.setAttribute allow XSS?

setAttribute() is safe in that it does nothing more than setting the attribute's value. Even by using special characters in the string you cannot inject an additional attribute (as you attempted in your third snippet), let alone escape the HTML tag.

Some attributes are dangerous for some elements.  As you demonstrated, on* attributes are vulnerable because they let you specify script event handlers. Similarly, src and srcdoc are dangerous on <iframe> elements, etc.

The technique of injecting JS via url() as proposed by @Anders has worked in the past for CSS attributes but is not possible anymore in major browsers. Back then, a payload such as <rect fill="url('javascript:alert(1)')"/> could have worked. That might also be the reason why Burp flags it as a potential vulnerability. It's not an attack vector in recent browsers, though.


What is the most valuable file you can get using a directory traversal hole

There are many things you can do with that. Check the web application source code for settings configurations like databases, then check for a way to connect with the db.

Keep looking at the source code and you might find more vulnerabilities (rce,sqli) or misconfigurations that can lead you to database dump, or some old backups, passwords disclosures, etc.


Is WPA-PSK of IEEE 802.11 insecure if PSK is exposed?

I have no knowledge about the details of WPA implementation, but what I can tell from basic knowledge: if you expose the Pre-Shared Key, then anyone can simply log on to your network, without needing that other handshake data. And if he actually wants these, he'd do a wireshark monitoring of the logon.