Does Nmap use only one of the DNS servers specified in the --dns-server flag per host?

From simple experimentation, I can tell you:

If you give it two addresses, and one isn't a DNS server, it gets full responses from the other server (but has to wait for a timeout).
If you give it two addresses of viable DNS servers, it gets about half from each.
When one DNS server reports NXDOMAIN (i.e. no records), it does not try the other one.

The raw data: I used your scan for 256 hosts.  I captured, with tcpdump, at a router, packets for one of the DNS server.  It reported:
237 packets captured
257 packets received by filter
19 packets dropped by kernel

which would be 128 requests and 128 replies.  (I'm not sure why the "received" is +1).
So half the queries went here when the other DNS server, and no requeries where performed when the first server reported no name.
For the record (a debian build on a Raspberry PI):
$ nmap --version
Nmap version 7.80 ( https://nmap.org )
Platform: arm-unknown-linux-gnueabihf
Compiled with: liblua-5.3.3 openssl-1.1.1g libssh2-1.8.0 libz-1.2.11 libpcre-8.39 libpcap-1.9.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select


Do network packets capture what gets encrypted in a device?

We can see (in the hexdump) that the POST request payload is urlencoded, and contains two values: signed_body and ig_sig_key_version.  The former contains a string which is composed of 64 characters (which are likely a hex representation of 32 bytes) followed by a dot and a JSON, the later is an integer.  And that is the payload.

TLS transports this payload over an encrypted (and trusted, unless you're in a mitmproxy and you force-trust it) connection.  And that is all that TLS does.  In simple words, you're confusing OSI layers, TLS protects the transport layer but the payload is on application layer.  TLS will transfer any payload in the same way, i.e. had the payload contained clowns= instead of signed_body= TLS would not care at all.

Whatever signed_body is (apart from being a JSON containing your username, password and device info) depends on the instagram app design, yet it definitely is completely unrelated to TLS.  They may or may not use some form of crystallographic hash to generate the first 64 characters from the JSON content plus some random number.  Or (more likely) they use those 64 characters as a CSRF protection token, which is exchanged with the server on each request.


Is it possible to decrypt Telegram messages from a private chat?

The data is encrypted using a random AES key. The AES key is then encrypted using the receiver's public key.

The encrypted data along with the encrypted key is transmitted to the user, who uses their private key to decrypt the AES key, which in return is used to decrypt the encrypted text.

  Is it now possible to use the proxy to record a message and manually decrypt it with the private key?

Since the private key is never transmitted during the communication process it is not possible to sniff them using a socks proxy with a root certificate in place on the device.

I think it's a good idea to get a better understanding of how asymmetric encryption works. The following link breaks it down quite nicely using a simple way of explaining it: https://hackernoon.com/asymmetric-encryption-explained-using-chocolate-boxes-5a329ea6813e


Giving different passwords to the app servers to access the same database. Pros and Cons?

A scenario with three different applications

If you have three different applications in most cases they should not all have full access to the database in the first place, just the data each needs. If they all need the same data, that is already a setup that reeks of misusing the database as a synchronization mechanism. If that's the database's main purpose, okay, but in most cases this scenario has its own problems and indicates a design issue. But let's assume that's a given for some reason.

You still should use different access credentials (username and password) and here is why:

At some point one app might actually start having data only it cares about and only it should access, then the initial assumption breaks and you should set up separate passwords anyway. But now you are already in production with a heavy user load and risk doing some small typo mistake that affects live users. You want to avoid that, so do it right initially
If someone breaks in and compromises your app such that your database gets accessed, you want to pinpoint that breach. If you know the credentials that where used you can identify the application. That cuts out 2/3 of your search space already with a very simple and cheap preparation step.
If one of your applications' security is broken and you need to change the credentials, you want to minimize the impact. If they all have the same credentials they all need to get an update of their credentials. Immediately. Now you have three apps that you need to hotfix at the same time and you risk doing a minor spelling mistake and giving your users some issues instead of just one.
2) also holds for other problems, like an app generating awesomely slow queries that drag down the database, knowing wich app did it is essential, so you want separate credentials (at least separate user id, but then you can also use a separate password).
If someone breaks in and compromises your app, you will likely need to shutdown that access immediately. That means all three of your apps stop working because they cannot access your database anymore instead of just one. If one of the other apps is so important you don't want to shut down the database access immediately, that means you give your attacker a larger window of opportunity to misbehave.

A scenario with the same application on three different servers

This is indeed a relatively common scenario, so the preamble of the other scenario (that three apps accessing the same db with the same rights is a design smell) does not apply!

Using different credentials here indeed does mostly not add security but adds maintenance cost. With rare exceptions (see below).

In this case most of the issues pointed out above vanish or are diminished to the point where the convenience in maintenance of using the same credentials on all servers typically trumps the gained security. One point that still remains though is compartmentalisation for high availabilty. This would mainly apply if the three servers are reachable in different ways, such that it is likely that one is broken into without the others being compromised. Say one covers Asia, one Europe and one America, they are hosted in different places and perhaps even the OS version is different. In such a case, if one host is compromised, you could shutdown that host's access without affecting the others. If they serve the same API/region the same might apply in principle, i.e. if one is compromised you could first exchange that hosts credentials while the others could still service requests. However, typically all hosts would share the same tech stack and environment in that setting - and thus in most cases where the security of one is broken the security of all is broken and maybe just not yet exploited. So this will only apply in rare cases. If you need to ask about it, it likely isn't the case for your application setup.


Does accidentally pasting password into browser URL field send it over the network?

In most browsers, yes. This happens because the browser sends the address bar text to a predictive service (commonly Google's) for search suggestions. Some browsers (eg, Firefox) ask before doing this (just the first time).

How dangerous is this?

Depends on where your browser is sending this suggestion text and how paranoid you are. Eg, Google should use:

https://www.google.com/complete/search?client=chrome&q=%s

And you note that this uses HTTPS, so no one else on the network can see your password. I can't imagine that any browser would be configured by default to use a suggestion service that doesn't use HTTPS, but if any did, you'd have to worry about your password thus being visible to anyone listening on your network.

But even with HTTPS, your password can certainly appear in server logs at Google and employees could potentially see it. That said, realistically, there's not a great deal of risk. Google's got far too high of a volume of requests to pay attention to any in particular, nor is there any way to know that any given query is a password. So it's very understandable that you might pass it off as so low risk that it's not worth changing your password (although it is a non-zero level of risk). I talk about Google here specifically, but the same applies to other major search engines, too.


Does installing more programs result in higher chances of being exploited?

One can not fully trust any program one has installed because it might have unintentional bugs which can be exploited, intentional backdoors, features one is not aware of etc. It is practically impossible to determine what the program really does just be reading the description of the program - the real functionality will probably overlap with the claimed functionality but they might not be equal. Programs might also unintentionally replace libraries used by other programs and thus cause instabilities or even security issues in the other programs. Many programs also phone home to get updates and often the updates are delivered in an insecure way and can be hijacked for malicious reasons. Or the update server of the software author got hacked in malware is delivered to the system instead of updates.

And the more programs one has accumulated on your system the larger the risk is, especially if these programs are complex, no longer maintained or of questionable origin (like downloaded somewhere from the internet).


Is HTTP secure within a WPA2-PSK connection?

It would definitely add an additional level of security that would keep communications confidential if your WPA pre-shared key is leaked.
Check this: Can other people on an encrypted Wi-Fi AP see what you're doing?

"So if you know the PSK for the network, and your sniffer catches the "4-way handshake" another client does with the AP as it joins, you can decrypt all of that client's traffic. If you didn't happen to capture that client's 4-way handshake, you can send a spoofed de-authenticate packet to the target client (spoofing it to make it look like it came from the AP's MAC address), forcing the client to fall off the network and get back on, so you can capture its 4-way handshake this time, and decrypt all further traffic to/from that client."


Sniffing traffic on a secured wifi connection

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.


Service traffic hijacking, how does cloud make it worse?

I don't think that the impacts of account or service hijacking are necessarily worse when using cloud providers, but that does depend on what you're doing in the cloud.  Because you're using a service provider instead of hosting the application yourself you can sometimes incur unexpected usage charges due to fraud (i.e. someone charging a bunch of server time to do bitcoin mining).  If you don't catch the fraudulent use in time it can cost you thousands of dollars.

Due to the urgency some providers have had to quickly deploy solutions and start making money they don't all make security a priority.  That can result in bugs or architecture flaws that make vulnerabilities easier to find.  Again, this isn't unique to cloud applications, when compared to internal applications, but attackers may have more incentive to find a vulnerability in a system with a lot of customers instead of a system used by a single customer.

It's also possible that by moving applications to a cloud provider you are exposing data or services that were previously better protected inside your organization's network.  While attacks against internal systems do happen, they tend to be less frequent and more difficult for an outsider to carry out.  The added accessibility of a cloud-based system may make it easier for an attacker to obtain credentials and carry out theft or fraud.


Forensics comes down to how well trained and trustworthy the person doing the forensics is and is unrelated to the design of hardware.

If your router's software is compromised, there's no book of things that can be changed since anything the mind can conceive, can realistically be done. The processors on routers these days can run compilers, interpreters and once you get a shell and root access, they are small computers that always run, have access to all traffic, are connected to the internet and most people don't even think are a security risk.

If you actually want to make a case, get a dis-interested professional to do all the work. Any Judge or defending lawyer would quickly dismiss as biased the input of someone pressing action based on "evidence" they collected themselves. You only have to show how you came to suspect a problem and called in the experts - anything you do past that would probably work against your interests.


What lies behind this complicated shellcode on linux?

If you have tried shellcode before which relies on absolute addresses, then that
could explain the crashes. This shellcode survives because it uses call to
obtain the absolute stack pointer address and then modifies the buffer in-place
without other stack modifications.

For a full understanding, it might be illustrative to see what is happening,
linearly:

8048060:    eb 1f                   jmp    0x8048081

Do a short, relative jump (eb) forward (current instruction pointer after
executing instruction is 0x8048081 + 2, adding 0x1f to that gives 0x8048081
as next instruction).

8048081:    e8 dc ff ff ff          call   0x8048062

Call (e8) with an offset of -36 (signed integer of 0xffffffdc) relative
to the next instruction at 0x8048081 + 5, yielding 0x8048062. Note that
call pushes the next instruction (0x8048086) as return address on the stack.

8048062:    5b                      pop    %ebx
8048063:    31 c0                   xor    %eax,%eax

Remove the return address from the stack, storing 0x8048086 in the ebx
register. Then it sets eax register to zero. Now, let's have a look at a
hexadecimal dump of the data following that return address:

00000000: 2f2f 2f2f 6269 6e2f 6361 7423 2f2f 6574  ////bin/cat#//et
00000010: 632f 7061 7373 7764 2341 4a49 5448 414a  c/passwd#AJITHAJ
00000020: 4954 484b 50                             ITHKP

Clearly, these are not instructions, but the disassembler did not know that.

8048065:    88 43 0b                mov    %al,0xb(%ebx)

al is the 8-bit lower half of the eax register which contains zero, so this
instruction overwrites the 11th position in the above data, replacing the # by
a NUL byte (after ////bin/cat).

Why not encode the NUL byte directly in the data? Well, often the buffer is
copied up to the first NUL byte, so if the shellcode contains a NUL byte, then
it would not be fully copied. By encoding a dummy value and then overwriting it
later, this limitation is avoided.

8048068:    88 43 18                mov    %al,0x18(%ebx)

Likewise, this sets the # in the second line to zero (after //etc/passwd).

804806b:    89 5b 19                mov    %ebx,0x19(%ebx)

This overwrites AJIT in the above data (at offset 0x19) with the address of
the buffer (starting at ////bin/cat). Note that ebx is a 32-bit register, so
indeed it overwrites four bytes.

804806e:    8d 4b 0c                lea    0xc(%ebx),%ecx
8048071:    89 4b 1d                mov    %ecx,0x1d(%ebx)

This loads the address of //etc/passwd (at offset 0xc) into the ecx register
and then overwrites HAJI (at offset 0x1d) with this value.

8048074:    89 43 21                mov    %eax,0x21(%ebx)

Overwrites THKP (at offset 0x21) with four zero bytes.

Now, assume for the sake of the argument that our data (pointed to by the ebp
register) is at the 32-bit address 0xffff0000. With the above modifications to
the stack, our data now looks like this:

00000000: 2f2f 2f2f 6269 6e2f 6361 7400 2f2f 6574  ////bin/cat.//et
00000010: 632f 7061 7373 7764 0000 00ff ff0c 00ff  c/passwd........
00000020: ff00 0000 00                             .....

or, written in a more readable form with absolute memory addresses:

0xffff0000: "////bin/cat"
0xffff000c: "//etc/passwd"
0xffff0019: 0xffff0000 (address of first string, encoded in little-endian)
0xffff001d: 0xffff000c (address of second string)
0xffff0021: 0x00000000 (a NULL pointer)

Hmm, this looks like some arguments for the execve system call
(sys_execve(char *filename, char **argv, char **envp)). For the
x86 architecture, parameters are passed through the registers ebx, ecx, edx
while the system call number is passed through the eax register. So our first
argument (ebx) points to the ////bin/cat string (at 0xffff0000).

8048077:    b0 0b                   mov    $0xb,%al

Sets syscall number to 11 (sys_execve for x86).

8048079:    8d 4b 19                lea    0x19(%ebx),%ecx

Sets the second argument to the address of the arguments list (at 0xffff0019),
in our case it contains two strings and a NULL pointer. (////bin/cat,
//etc/passwd, NULL).

804807c:    8d 53 21                lea    0x21(%ebx),%edx

Sets the third argument to the address of the environment variables (at
0xffff0021), in our case it contains just a NULL terminator.

804807f:    cd 80                   int    $0x80

And finally invoke the syscall! Effectively, this code did the same as this C
snippet:

char *argv[] = {
    "////bin/cat",
    "//etc/passwd",
    NULL
};
char *envp[] = {
    NULL
};
execve(argv[0], argv, envp);


Accidentally accessing a business's computer through public wifi

You had no right to scan their network, and any decision now is up to them. They could try and sue you (I doubt that), simply scold you or even thank you, and it very much depends on how you told them.

  I brought it up to the staff as soon as I found it and showed them, that they had two company computers unsecured on the public wifi they offered.

I do think that telling them they had unsecured computers wasn't the smartest move. You could have simply told them you happened to see their computers on the network when you were connected, and ask if they were aware of that fact and if they had taken the measures to secure them (justify this coming forth by being a security enthusiast maybe). If you really wanted to make them aware, you could have waited a bit and sent an anonymous message telling them about the situation.

But first of all, don't go scanning infrastructures that are not yours/which you are not permitted to scan, it can get you in trouble no matter what your intentions are ("I'm just a security engineer" is every black hat's first excuse).


Are Password Strength/Entropy test web sites safe?

Since you already came to the conclusion that it would be possible, it is safe to assume, other people might have had the same thought. It's also safe to assume, people might have had those thoughts with a different intention than you had.

So: Most likely there might be one site or more that actually do exactly what you would think they do. It's even worse than you think: A quick check of some of those sites shows that - besides their own JS - they include third party javascript e.g. for ad-placement and so on. So even if they do not log your passwords, a third party might decide to do so.

You can (if it is implemented purely in JS) read though the code and decide if it is "clean" or not. However this could change with every call you make to the site so I suggest not using them. By the way: at least http://www.passwordmeter.com/ does give you all the calculations in plain text. You can simply do it by hand or write a short script, that tests everything for you.

BTW: I just realized, that very site does not even use transport layer encryption. That's my facepalm of the day.


Found Wildcard AlphaSSL Cert Private Key of large Webhoster - what now?

Send the a signed message to the issuer of the certificate. They will be forced to revoke it when you prove that you have the private key.

This can be done with the following command:

openssl dgst -sha256 -sign keyfile -out signature text-file-to-sign.txt

Send the signature and text-file-to-sign.txt to the issuer. Ask them to verify with

openssl dgst -sha256 -verify public-keyfile -signature signature text-file-to-sign.txt

In this way you prove that you have the private key, without revealing the content of the private key. Any issuer that adheres to the rules should revoke the key when they learn that a third party has access to it.

Another way would be to send the key itself in e-mail to the issuer. This should only be done if you can send encrypted e-mail to the issuer, to avoid more compromise of security than needed.


What is the effect if a Cisco router is transmitting PDUs to an ISP?

I think what they mean is BPDUs, or Bridge Protocol Data Units, not PDUs. PDUs are just Protocol Data Units, ie layer 2 frames or layer 3 packets. The ISP seeing BPDUs means that the interface that connects to your ISP is likely set as a trunk port, and it is transmitting more than one VLAN's frames to it. If this is an actual router it won't do this unless you've configured more than one subinterface and you are tagging the packets with those vlans, but I think it is more likely you are using a switch not a router. If that's the case you need to ensure that the interface is not set as a trunk, or dynamic (the default). Do a "show run int " to see. If you see no switchport mode statement then it is set to dynamic, if it says switchport trunk then it's a trunk. I think it's probably set to dynamic in which case you need to change it to mode access:

Arrange for an outage, and get your ISP involved in case you need some help from them. Make sure you have a console connection to the device available in case you lose connectivity. Don't do this without having a console connection! During the outage:
do a "copy run start" and then copy the running config to a notepad
Set the port to switchport mode access
conf t
interface
shut
switchport mode access
no shut
ping across the connection, and ensure you have internet access. If not check the config to make sure the change took
Have the ISP confirm that they no longer see BPDUs
If there are no more BPDUs and internet access works then "copy run start" and monitor for awhile. Then go home.


VeraCrypt/TruCrypt - I can't understand why you'd want to create a "hidden" volume...?

Your first question is really a legal one, and you seem to be assuming two things:

The attacker is a government of some sort.
That government actually respects citizen privacy and requires some sort of reasonable suspicion before it can force people to give up encryption keys.

Neither of those assumptions are necessarily true. For all you know, some random thief could grab your laptop while you are using it, notice a VeraCrypt file sitting on the desktop, and pull out a gun and force you to decrypt it. It's not super realistic, but definitely possible.

And even if it is indeed a government, not all countries have privacy protections or require reasonable suspicion. Even in ones that do (e.g. US and many European countries), there have been lots of cases where courts have forced people to supply their decryption keys because it is deemed relevant to an investigation. Whether they have the authority to do so is a subject of current debate, especially in the US where there is supposed to be protection against self-incrimination. Here is one such case:

http://www.cnet.com/news/judge-americans-can-be-forced-to-decrypt-their-laptops/

For your second question, try it out yourself: Create a 500mb outer volume, containing a 300mb hidden volume. Completely fill the hidden volume with files. Then mount the outer volume. The outer volume will still show 500mb of free space.

How does this work? The idea is that you're never supposed to write to the outer volume once you have created it, as doing so could corrupt your hidden volume. If you open the outer volume, even veracrypt does not know that the hidden one exists. There is no way to tell that a hidden volume exists because the hidden volume is indistinguishable from free space (which is why veracrypt still shows 500mb free space when you mount the outer volume). That's the whole idea of plausible deniability; there is no technical way to prove that there is more encrypted data.


Why does COMODO have 5 root certificates on a new Apple laptop?

In my browser (Chrome on Windows) I have certs for both of those CAs. I'm not entirely sure what your question is getting at (Why a CA would have more than one cert? Why a CA would issue off a non-root cert? Why OS X doesn't ship with the root cert?). If you could update your question with more detail, that would be great, but in the meantime I'll try to answer the most general question.
Why a CA would issue off a non-root certificate?
It is very common for a public CA to use a non-root CA for issuing customer certificates. As far as establishing trust, it only matters that the customer certs can chain back to the root that's in your browser, which intermediate CA actually issued it is mostly irrelevant.
There are a number of reasons for setting up a CA hierarchy like this, some are security-related, some are IT-related. Let's look at an example CA setup (not the best image, but let's go with it):

Reasons that you might want to set it up this way:
IT / Administrative
A CA may have multiple marketing departments that all issue SSL certs. Maybe these departments are in different physical locations, maybe they're subject to subject to different laws, or maybe they're just in different departments of the company. Either way you probably want the admins for each department to not have access to the CA for other departments.
Security
What happens if your Root CA gets compromised? How do you recover from that? You don't, your company goes bankrupt, it's happened before.
If instead, it's a intermediate CA that gets compromised you have options. If each intermediate CA is on a different network with different admins then chance are good that you can shut it down without compromising any other CAs. You have to be careful with both the technical and PR aspects, but it's possible to move customer certs on the compromised CA over to another CA without people losing trust in you. It's not easy, but you have options.
Offline Root CA
For these reasons it's common for commercial CAs to have their root be a machine that is never, at any point, connected to a network. Its only job in life is to issue certificates for the CAs immediately below it, then you turn it off and put it in a vault. Good luck hacking into that.
My guess from looking at those two certs you linked is that
C=SE, O=AddTrust AB, OU=AddTrust External TTP Network, CN=AddTrust External CA Root

is an offline root, and
C=GB, ST=Greater Manchester, L=Salford, O=COMODO CA Limited, CN=COMODO Certification Authority

(which is subordinate to the first one) is a regional departmental CA (though clarification of your question would help).


Pre-hash password before applying bcrypt to avoid restricting password length

Using a secure hash function to preprocess the password is secure; it can be shown that if bcrypt(SHA-256(password)) is broken, then either the password was guessed, or some security characteristic of SHA-256 has been proven false. There is no need to fiddle with the salt at that level; just hash the password, then use bcrypt on the result (with the salt, as bcrypt mandates). SHA-256 is considered to be a secure hash function.

The point of a salt is to be unique -- as unique as possible, so that no two hashed passwords use the same salt value. 32 bits are a bit low for that; you should use a longer salt. If you have n bits of salt, then you will encounter collisions (two hashed passwords using the same salt) as soon as you have more than about 2n/2 hashed passwords -- that's about 65000 with n = 32, a not too high value. You'd better use 64 bits or more of salt (use 128 bits and you can cease to worry about it).


website - infected by malware and if yes, how can I treat it?

I've taken a look at the website and I couldn't find any evidence that it has been hacked - however, this does not necessarily mean that the site is clean.

Norton claims that your site is a Web Attack: Mass Injection Website and has therefore put the site on a blacklist. This blacklist seems to be used by other services (like sucuri and maybe the company firewall you mentioned).

But Web-based tools can never be as exact as searching for malicious content by yourself. Therefore, it is better to have a closer look at the server and the files stored on it than wasting much time with online tests.

For you, the next steps could be:

Skim through all the files of your website. Find out if there are any suspicious PHP or JavaScript files. Open them in a text editor and review them: If the source is obfuscated like in this example, it is quite probably a backdoor:
$sF="PCT4BA6ODSE_";$s21=strtolower($sF[4].$sF[5].$sF[9].$sF[10].$sF[6].$sF3.$sF[11].$sF[8].$sF[10].$sF [...]
You should also check the log files (if your hoster provides them) and search for any php files accessed.
If you are not sure whether a file is suspicious, compare them with the files in a new Wordpress installation. You can download a zip file from wordpress.org for comparison.
Oh, and always keep Wordpress and its plugins and themes up-to-date. The website is currently not running the latest available version.

If you find a backdoor or other malicious code - then check out the thread How do I deal with a compromised server provided by Stephane.


What are the risks posed by "pass-through authentication" and how are they mitigated?

Here's the tricky part about the problem in your question: It doesn't exist.
No no, I'm not being snarky. Hear me out.

You have a Domain administrator account with the password password (or any password of that sort), and the attacker created a local account with the same username and password. Without needing to create a local account, the attacker can simply user the username MyAdmin and the password password to login and use MyDomain\MyAdmin.

The problem has nothing to do with the pass-through authentication scheme, the problem is with using such passwords. Even if you, for example, disabled the whole functionality, the attacker can still use the username and password combination.

If it makes you sleep better at night, you can completely disable incoming NTLM authentication traffic by setting the following security policy in Group Policy \Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Incoming NTLM traffic to Deny all domain accounts.


Your hashcat appears to be working correctly.  30 seconds is about how long it takes mine to run through every password in rockyou.txt

It looks like the password is not in rockyou.txt which only contains a few hundred thousand passwords.

I suggest you use some rules to make it guess some variations on the passwords in rockyou and/or find a larger dictionary.

d3ad0ne.rule will take a nice long time...

a command might be

hashcat -m 300 -a 0 -r rules/d3ad0ne.rule hash rockyou.txt


Get client ip address that is not spoofed

This obviously only applies to HTTP, as it is a HTTP header.

It furthermore relies on a proxy server that doesn't attempt to hide that it's a proxy server. It will not work with clients using VPN. It will not work for clients using a proxy that doesn't reveal itself. It will not work for clients who establish a TLS session using CONNECT through a proxy.

In short, it provides no real security, but may be useful for statistical purposes or similar. It's like politely asking the client who they are, and expecting them to answer truthfully.

You can rely on that REMOTE_ADDR is the host that actually sends you the traffic. That's basically ensured by the three way handshake of TCP/IP.

You cannot be sure who asked the remote address to initiate the connection. You cannot be sure if that remote host is a VPN terminator. You can't know if it's a proxy. You can't know if it's part of a botnet.


Are "man in the middle" attacks extremely rare?

My favorite current resource for cold, hard, real world data is the Verizon 2011 Data Breach Investigations Report. An excerpt from page 69 of the report:

Actions
The top three threat action categories were
Hacking, Malware, and Social. The most common
types of hacking actions used were the use of
stolen login credentials, exploiting backdoors,
and man-in-the-middle attacks.

From reading that, I infer that it's a secondary action used once somebody has a foothold in the system, but the Dutch High Tech Crime Unit's data says it's quite credible for concern. Of the 32 data breaches that made up their statistics, 15 involved MITM actions.
Definitely don't stop there, though. That entire report is a gold mine of reading and the best piece of work that I've come across for demonstrating where threats are really at.
For fuzzier references to MiTM attacks and methods, see also this excellent answer to MITM attacks - how likely are they? on Serverfault.
I would go further in saying that any instance of a SSL root coughing up a bad cert is a sign of an attack, otherwise they'd be pretty useless compromises. Finally, because I'm that guy, I would definitely try to splice into your network box outside the building if I were doing your pentest. One can do amazing things with a software radio even on a wired connection.


Is it OK to use the same password for a Linux login and the SSH private key?

Summary: using the same password for different things is a generally bad idea. However, in this case, where the two uses of the password control access to the same asset, it's not too bad.

So if someone can eavesdrop when you unlock your ssh key (for example by looking over your shoulder, or if they've managed to install a keylogger), they'll know your password on your server. If the only way to log in on that server is to have physical access or through ssh (which has passwords disabled), then having your password compromised doesn't matter.

That is, assuming that your password is only a login password. In fact, it is pretty common that your password doubles as an authentication token to become root through sudo. If that's the case, then an attacker who obtains your ssh key file's password as well as the key file can immediately escalate his access to the root account. If you're the only administrator on the server, it doesn't matter much, because the attacker can inject malware into your account that will let him piggyback on the next time you become root. If there are other administrators (or other ways for you to access the root account, such as a remote administration panel), this removes an opportunity for your colleagues to disable your compromised account.

Conversely, if someone can find out your password on your server, they can unlock your ssh key file. That's not a concern if you only use that ssh key file (or more generally that password) to access that one server. But if you use the same ssh key for other servers, then the attacker can gain access to these other servers given your key file and that server's password. This only represents a gain if you aren't using that same password on the other servers.

All in all, using the same password won't make much difference in typical situations other than a multiple-administrator server where you can sudo to root.

  Public/private key authentication is more secure than password authentication

That's a bit simplistic. Public key authentication uses two factors (the key file and the password to the key file); this is good in that it takes more work for the attacker to compromise both factors. However, you also need to take the risk of a compromise into account. For example, for an ssh key, an active attack on the client will reveal both factors. If the attacker obtains a copy of the key file, he can try to brute force the password offline, so password protection on a key file requires a strong password, stronger than a password that can only be brute-forced through online attacks (though note that an online-only password can be brute-forced offline in some circumstances, for example if the attacker gets hold of a system backup).

Using a password for ssh is not wrong per se, if you can guarantee that it's unguessable. Typical users are bad at choosing unguessable passwords, that aren't a simple variation on their birthday or their girlfriend's name. If you have a good password (randomly generated with an amount of entropy that you can evaluate and that satisfies you), it's ok to enable password authentication if you don't type your password in a place where it'll be eavesdropped.

So if your login password is only a login password, you might combine an ssh public key for convenience and resistance to shoulder surfing, with a strong password that you don't remember keep in a safe and can use in private in emergencies (such as the loss of your client machine and difficulty to access its backups quickly). If your login password doubles as a sudo password, you will need to remember it.

If you only ever keep the key file on an encrypted volume (that only you can access), you don't need to encrypt the key at all. Remember to encrypt backups too.


How can I hide a program from another program?

Yes, it's possible.

This kind of behavior is seen on a class of programs called rootkit. A rootkit employs a number of techniques to avoid detection.

Some of those techniques:

Thread injection

In this case, Program B injects a thread on another running process. If Program A is searching for program_b.exe, it will not find it.
Kernel Process Table manipulation

In this case, Program B manipulates the kernel process table, removing itself from the list of running processes. It renders Program B invisible.
Polymorphism

In this case, Program B will create lots of copies of itself, each one different from the another. This is called polymorphysm. As there is lots of different ways to execute the same action, it can create virtually infinite copies of itself. If Program A is searching for the signature of Program B, it will fail to detect the variations.
Behavior change

Program B can have 2 modes of operation: safe and unsafe. Safe mode is how it will behave when it detects Program A running. As soon as it detects that Program A is not running, it loads anything it needs and enters unsafe mode, doing anything Program A would detect.

There's a lot of another techniques, those are just a few samples. A quick search for Detection avoidance  will give you lots of pointers to research.


How can I get my SSL certificate signed by an CA for web application that runs on localhost

You can create your own CA certificate, add that as a root CA on your machine then use that CA to sign your SSL certificate. http://msdn.microsoft.com/en-us/library/ms733813.aspx

Alternatively, assuming you own a domain name of some form, you could probably create an A record for localhost.yourdomain.com and point it to 127.0.0.1. You should then be able to get an SSL certificate signed for localhost.yourdomain.com, which you can then use instead of localhost (albeit only from your machine).


Technical realization of fraudulent credit card cash withdrawal

You are correct that a thief needs a physical card and pin to make a withdrawal. Chips cannot be fully cloned (yet, that may change), but magnetic strips can be cloned or created from intercepted chip data. Brazilian hackers have come up with a way to create working cards which allow any pin and bypass card data authentication:

  The card-cloners created a Java application for cards to run. The
  application has two capabilities: First, it tells the POS terminal
  there is no need to perform data authentication. That means no
  cryptographic operations, sparing them the near-impossible task of
  obtaining the card’s private cryptographic keys.

  But that still leaves PIN authentication. However, there’s an option
  in the EMV standard to choose as the entity checking if the PIN is
  correct…your card. Or, more precisely, an app running on your card.

  You read that right: The cybercriminals’ app can say a PIN is valid,
  no matter what PIN was entered. That means that the crook wielding the
  card can simply enter four random digits — and they’ll always be
  accepted.

However, it's unlikely that's how your card was compromised. While there are attacks against credit card chips which can break encryption and retrieve PIN and other data, they aren't used in the wild so that representative was. What's likely happened to you is you've been hit by one of the mainstream credit card attacks:

Skimming: a device reads the magnetic strip of your card as it's put into a machine while another device gets your pin by videoing your fingers or reading the key input
Compromised ATM: a hacked ATM gives the strip and pin data to attackers
Shimming: a device is put between your card's chip and a card reader, it intercepts the communications between the device and your card, allowing the magnetic strip to be re-created. Your pin would need to be gained separately using the same methods as skimming
Compromised Point of Sale System: some major retailers' point of sale terminals have been hacked in the past, handheld credit card readers have as well, where your card data and pin are sent to a malicious third party


Why are downloads of Mac updates redirected to plain HTTP?

It's common practice to offer large file downloads over plain HTTP and rely on other means to ensure file integrity. Since your MacOS checks signature before installing the update (or anything else) and thereby verifies that the file has not been altered, you don't risk installing malware.

This procedure compromises confidentiality (an eavesdropper can see what you're downloading), but it is somewhat faster since it skips the TLS encryption/decryption parts.

Edit: Turns out we have already discussed this in-depth: Why aren't application downloads routinely done over HTTPS?


What is the exact problem if a website has an SHA-1 certificate?

The issue is caused by the unavoidable phenomenon of "Hash Collision"

The dangers of trusting certificates that use  SHA1 starts from the technique used by Certificate Authorities (CA) to sign them and how the web browser verifies them.

As you may know the entire certificate is not signed, instead only the hash of the certificate gets signed.

Lets assume a certificate with the following data inside A with value A produces a hash 7d157d7c000ae27db146575c08ce30df893d3a64.

Now if a third party is able to create a certificate X with arbitrary value *************** such that the sha1 hash is 7d157d7c000ae27db146575c08ce30df893d3a64 then it can be used as a replacement and the browser would not be able to tell the difference as the hashes would be same and hence the signatures would match.

The villain in this story is no one else but our trusted Moore's Law

A sha1 hash is a 120 bit (20 bytes) one way hash algorithm. Which means it can produce 2^120 = 1329227995784915872903807060280344576 unique values.

This was more than enough years ago when all this story began but computers have become so fast that the computing power that is needed to produce a collision is dropping every year.

In 2012, Jesse Walker wrote an estimation of cost to produce a collision. Based on the estimates, collision would cost $2M in 2012, $700K in 2015, $173K in 2018, and $43K in 2021 ->https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

That means that many companies, organizations and governments today has sufficient computing power to produce a fake certificate that will pass through the test.

You are right, if there is a site using sha1 there is a great chance it can be broken. Not yet by small time hacker but it is better to close the holes before water starts seeping in.


can web application disable browser's password manager's remember feature for that application?

So first a little bit of information:

Auto Complete is not filling in the login form, a password manager is. Modern browsers will NEVER have auto complete remember a login form!

Password managers are NOT a security flaw or point of attack. An unprotected/poorly designed system, bad users, and bad policies are.

Most browsers these days implement a password manager into their browser(NOT auto complete) that keeps things in a safe and secure location(for google chrome, it's actually stored in your google account cloud). In google chrome, firefox, and edge you can disable the password manager and it will not affect auto complete. This is because auto complete and password manager are two separate sub programs running in the browser. autocomplete=off on a form does not say "Don't Fill In A Form", it says "Don't Remember This Form". However a browser will still probably fill in a login area and ask to remember it because password managers are not auto complete, and thusly ignore this. If the password manager is turned off and you go to a login page, it will not automatically fill in the form even if auto complete is turned on. This is because of the way most modern browsers implement auto complete and their built in password managers. What does this mean? Well it means you, as a web developer, have NO CONTROL over a users browser program itself, just the web page. As such you cannot prevent the password manager form remembering the password, just the same as you can't prevent the user from writing the password on a sticky note or in the mud.

So what can you do to prevent this? Nothing. That's not a bad thing though. You just need to build your website, applications, and services as secure as possible so that if something gets compromised, as little damage as possible happens to your service.

If a security expert tells you a password manager is a security flaw, ask them how they manage their randomly generated, routinely updated secure login credentials and private keys. Then find a new security expert!!!

That being said, a password manager is not something to be feared. It can actually be a GOD send for storing randomly generated, routinely updated enterprise level passwords.


Quoting https://stackoverflow.com/a/32166210/569976,

  The default for OAEP is to use SHA-1 for MGF1. Note that the hash
  chosen doesn't have that much impact on the security of OAEP, so
  mostly it will be left to this default.

  We can easily test this by testing it against "OAEPPadding" and
  OAEPParameterSpec:

// --- we need a key pair to test encryption/decryption
KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA");
kpg.initialize(1024); // speedy generation, but not secure anymore
KeyPair kp = kpg.generateKeyPair();
RSAPublicKey pubkey = (RSAPublicKey) kp.getPublic();
RSAPrivateKey privkey = (RSAPrivateKey) kp.getPrivate();

// --- encrypt given algorithm string
Cipher oaepFromAlgo = Cipher.getInstance("RSA/ECB/OAEPWITHSHA-256ANDMGF1PADDING");
oaepFromAlgo.init(Cipher.ENCRYPT_MODE, pubkey);
byte[] ct = oaepFromAlgo.doFinal("owlstead".getBytes(StandardCharsets.UTF_8));

// --- decrypt given OAEPParameterSpec
Cipher oaepFromInit = Cipher.getInstance("RSA/ECB/OAEPPadding");
OAEPParameterSpec oaepParams = new OAEPParameterSpec("SHA-256", "MGF1", new MGF1ParameterSpec("SHA-1"), PSpecified.DEFAULT);
oaepFromInit.init(Cipher.DECRYPT_MODE, privkey, oaepParams);
byte[] pt = oaepFromInit.doFinal(ct);
System.out.println(new String(pt, StandardCharsets.UTF_8));

  The code will fail with a padding related exception if you substitute "SHA-256" for the MGF1 as parameter.

  The reason why the extended algorithm is needed at all is compatibility with other Cipher algorithms. Code written for e.g. "RSA/ECB/PKCS1Padding" doesn't use any parameters, let alone OAEP parameters. So without the longer string OAEP cannot function as drop in replacement.

  The mode of operation "ECB" doesn't mean anything in this context, it should have been "None" or it should have been left out completely. You can only encrypt a single block using the RSA implementation of the SunRSA provider.


Should I report to abuse@ about network scans?

You could try to use ipset and just drop everything:

ipset create BlockTheRussians hash:ip

Next

ipset add BlockTheRussians <IP Address>  <-- Repeat for each IP

Finally

iptables -I INPUT -m set --match-set BlockTheRussians src -j DROP

Another thing worth installing is Fail2Ban.


I suspect channel contention. It could be that a neighboring AP on the same frequency is transmitting or receiving large chunks of data on the same channel or channel group as the one your hotel AP is using. All I can suggest is using a different channel, which, as far as I know, is not an option if you don't control the AP. The AP you're using is probably set to the common default of channel 6, as are many other, possibly nearby APs.

There are 11 channels, each overlapping with adjacent channels by 5Mhz. According to Wikipedia, "There are 14 channels designated in the 2.4 GHz range spaced 5 MHz apart (with the exception of a 12 MHz spacing before Channel 14). As the protocol requires 25 MHz of channel separation, adjacent channels overlap and will interfere with each other. Consequently, using only channels 1, 6, 11 is recommended in the US to avoid interference."

The "jamming" you're seeing is probably unintentional, since radio transmissions by nature are RF interference to other devices on the same frequency, assuming those other devices are not "wanting" to receive that signal.

If you've got an ethernet cable, that might be better in this case.


Does PCI PIN Security allows keeping the PIN in-memory for a short period of time?

Storage in PCI terms refers to data being written to disk and generally not to data which is stored in Volatile RAM. The reference to storage for store and forward is to disk and is to allow devices store cardholder validation information pending a device being able to connect or reconnect to a Payment Service Provider or acquirer for the purposes of authenticating the cardholder to allow authorisation of the transaction. In PCI, this data cannot be stored subsequent to the transaction i.e. once its purpose is fulfilled, it must be deleted.

The process you're referring to must include PIN storage in the back end which is permissible for issuers only and that data must be securely stored. You're also describing storing the data in Volatile RAM which is permissible.


What implementations are possible for dual control?

One approach is to use temporary passwords, and a password management application. The process could work like:

An admin submits a request for access to a server for a particular time window
A separate admin approves this request
With the request approved, from the start of the time window the first admin can now access a temporary password for the server
The admin logs in as normal, using the temporary password
At the end of the time window, the temporary password is automatically reset to a new value

I have seen systems like this, but they all used some bespoke scripting, based on an existing request management system. I don't know anywhere you can just download such an application.

Of course, once the admin has the temporary password, they have single-handed access to the server. If you need the two-man rule the whole way - that there have to be two admins sat at one computer to perform the work - this approach won't work.

A variant on this I have seen is that a secure ID token is held by ops staff. When the admin needs to login to the server, they provide a password (that only they know) and also phone the ops desk to get the code from the secure ID token. I'm not convinced this arrangement is a good idea, but it does get used.


Kali Linux SHA1 checksum changed during and after download

The official hash sum is the one of the complete file. During the download the file is not complete, so the calculated hash sum, represents the current state of the file (e.g. 50%; 1GB/2GB).

It simply is not possible for a file to have the correct hash sum, whilst downloading.

For example:

If the complete file was a simple text file containing 10 as and it's hash sum is 2ee3ace5cfab0b5dee7ba84fc09dc3c459c34f0b.

An incomplete file, for example only containing 5 as, differs from the complete file and therefore the hash sum differs as well (5cafdebe4e78588628681c0fa5fda8a410ccd966).

If they were the same, that would mean that the complete file is available for you locally, to calculate the hash sum.


What sort of security method is this called (if it has a name)?

Edit 2: Since this has been migrated to Security.SE, I should probably preface this with with: I'm not a professional cryptographer, and there are many, many reasons why you should never roll your own security.  Having said that:

It's a form of challenge-response authentication (with different challenges being sent each time).  The algorithm to find the correct answer is essentially the "secret" or "password".  You are open to a number of attacks, but essentially, anyone who can figure out your algorithm can break this security, and it is relatively trivial to reverse engineer executables.

Edit:  To put this into perspective, consider Wikipedia's summary of Kerckhoffs's principle and Shannon's maxim:

  In designing security systems, it is wise to assume that the details of the cryptographic algorithm are already available to the attacker. This principle is known as Kerckhoffs' principle — "only secrecy of the key provides security", or, reformulated as Shannon's maxim, "the enemy knows the system".

In your case, you've come up with a secret algorithm, but have no real "key" (there is no shared secret between the two endpoints, other than the algorithm).  Once someone figures out the algorithm, the security is broken; so at best you've raised the bar slightly for people trying to figure it out.  Rest assured though that anyone who really wants to break it, will do so.  In that situation, you've also got a difficult problem of having to replace the compromised algorithm (as opposed to simply switching out the compromised key).

There's a reason why modern cryptography prefers large keys over complex algorithms - no matter how complex the algorithm is, it can (and will be) reverse engineered.


How safe is a standard wireless keyboard from a MITM attack?

Here is something interesting from Bruce Schneier's blog:

  Many wireless keyboards have a security vulnerability that allow
  someone to hack the computer using the keyboard-computer link.
  (Technical details here.)

  An attacker can launch the attack from up to 100 meters away. The
  attacker is able to take control of the target computer, without
  physically being in front of it, and type arbitrary text or send
  scripted commands. It is therefore possible to perform rapidly
  malicious activities without being detected.

You can find on market secure wireless keyboards, which are using 128-bit AES encrypted wireless connection back to your computer, so you can check for that.

Another useful information from Logitech whitepaper:

  Encryption

  Computer keyboards process very private or sensitive information like
   passwords, credit card numbers, or personal messages. Since the range
   of an Advanced 2.4 GHz device may reach several tens of meters in an
   open environment, it is critical to take adequate measures to prevent
   eavesdropping.

  Advanced 2.4 GHz applies state-of-the-art encryption to
   the keyboard reports. Since the displacements of a mouse would not
   give any useful information to a hacker, the mouse reports are not
   encrypted.

  Encryption is limited to the wireless link between
   keyboards and the receiver. Encryption is totally transparent to the
   software which receives clear data from the receiver over the USB.
   This means that the Advanced 2.4 GHz encryption provides no protection
   against hackers who are able to get physical access to the PC, or who
   are able to remotely install spy software on the PC.

  The encryption
   applies to all standard keyboard keys (a, s, d, f...) and modifiers
   (Shift, Ctrl, Alt...). The multimedia keys (Play, Pause, Mute...) that
   may be implemented in some keyboards are transmitted in clear text.

  Encryption Algorithm

  The encryption method consists of hiding the wireless messages with a
  cryptogram. The selected algorithm is the AES 128-bit cipher, which
  has been adopted as an encryption standard by the US government. As of
  today, the only known way to crack it is to try all possible keys.
  Even if it was possible to test 1 billion keys per second, billions of
  years would be necessary to try all combinations.

  AES is based on symmetric 128-bit keys, “symmetric” meaning that the
  same key is used to encrypt a message in the keyboard and to decrypt
  the message in the receiver.

  Generation of Encryption Keys

  When a device that requires encryption is paired to a receiver, the
  pairing process includes the generation of 128-bit encryption keys.
  The same unique key is constructed both in the keyboard and in the
  receiver based on random values exchanged during the pairing
  procedure.

  Note that the encryption keys are never transmitted over the air. By
  spying the packets exchanged during the pairing process, a hacker
  would not be able to find the encryption keys without knowing the
  secret algorithm implemented to construct them.

  The initial encryption keys are programmed at the factory when the
  devices are paired to their receiver.

  The encryption keys are stored in a non-volatile memory area of the
  keyboard and receiver. As this is hardware encrypted, software cannot
  access the keys.

I'm not promoting Logitech keyboard, I just took an example of how they implemented AES encryption with wireless keyboard.


the registry key is the result of some kind of encoding error.

This.

  潓瑦慷敲卜湹潣敶祲

encoded in UTF-16LE (Windows's usual encoding for Unicode strings) is the byte sequence:

53 6f 66 74 77 61 72 65 5c 53 79 6e 63 6f 76 65 72 79

Which represents the ASCII string:

Software\Syncovery

So it would seem Syncovery called a Win32 Unicode API to write a registry value, but passed strings that were actually ANSI. Whoops!

No indication of a security issue, unless you weren't expecting Syncovery to be running...


How to know which secret key to use to create and verify JWT

All of these details have been worked out in OpenID Connect. I would strongly suggest implementing that (or using an existing implementation) rather than inventing your own protocol.


Can programs see your windows account name given admin rights?

Programs can get the current username using GetUserName() and the path of profile directory e.g. using GetUserProfileDirectoryA(). They use API calls instead of deducing something from directory names. And no administrative rights required for these.


Security risk of encrypting the same data with many public keys

Depending on the used implementation, using RSA with the same input and different keys could be a problem. If all your keys have the same exponent e, a variant of the coppersmith attack (Håstad's broadcast attack) is applicable: https://en.wikipedia.org/wiki/Coppersmith%27s_attack


Has a plaintext password ever been used in a court of law as evidence to a crime?

Technically this could happen. Although I couldn't find any recorded cases.

Under key disclosure law several countries can obtain your decryption keys, if those keys were incriminating or a confession, there is nothing barring them from using it against you in court.

In the US, the 4th (edited as per comment!! my bad.) amendment protects you from giving up an encryption key until it is ruled you have to by judge and jury. If the key is obtained before the ruling it can be thrown out and not used against you.

As for the identical hash thing - if you have identical hashes - your password scheme sucks and can be easily cracked with a rainbow table or john the ripper. If the password is cracked/guessed and contains incriminating evidence it can be used against you or the FBI will not hesitate to boast that they guessed it and did not require a ruling.


Is it possible to extract secret key in compiled code automatically?

This depends on how is manage the private key on the binary, and probably you will need to do reverse engineer to figure out the correct private key. I have seen keys split-ed in two parts: one on the text segment of the binary and the other component was opcodes on the execution segment as well as some keys can make mathematical operations on the assembler to be tricky to discover.

By the way, ask this question on https://reverseengineering.stackexchange.com/ probably you will find better responses


I am not talking about password compromise, but if somebody gets my
  phone, he just needs to turn it on to get data decrypted, so what’s
  the point? For what cases is this encryption designed?

I'm not sure from where you are quoting this statement, but it's false. Physical access to the device does not guarantee automatic decryption of the disk.

From the official Android documentation:

  Upon first boot, the device creates a randomly generated 128-bit
  master key and then hashes it with a default password and stored salt.
  The default password is: "default_password" However, the resultant
  hash is also signed through a TEE (such as TrustZone), which uses a
  hash of the signature to encrypt the master key.

  When the user sets the PIN/pass or password on the device, only the
  128-bit key is re-encrypted and stored. (ie. user PIN/pass/pattern
  changes do NOT cause re-encryption of userdata.) Note that managed
  device may be subject to PIN, pattern, or password restrictions.

In the comments I've also referred to this question that answer a similar (if not equal) question.


Does signing of HTTP requests have any benefit when using TLS?

TLS only protects the communication between the TLS endpoints, i.e. some client certificate will only be checked by the TLS server. With signed request the authentication and integrity is bound to the request and not the communication channel which means that it will be kept and can still be verified by the final recipient even if TLS terminating proxies like load balancers or other reverse proxies are involved.


Is there a way to save a file from the network printer queue?

The printer administrators can see the content of your files in the queue because it is their job and they have been authorised to have that access.

A secured print queue is supposed to block other people's access to other people's files. If it works or not depends on how it is implemented.

It is normal for the queue to list the username, file size and file name in the queue so that if a file is causing a problem, then the users can track down the file owner to fix things. The common scenario is that someone sends a huge file that fills the queue and blocks everyone else. I can then look at the queue, see that Ray has sent a massive file, and I can contact Ray to remove the specific file from the queue.

So, as you have described it, there is no security issue, but you are correct that the owner, file name, and file size discloses a lot of information to potentially unauthorised people. This is a training issue in the use of printers.


Are there commercially available hardware encryption devices over USB?

As Bruno Rohée wrote, it's likely that you want some form of smartcard packaged as USB key. This smartcard could either contain a ready-made application that integrates with PKCS#11 or an application that is specific to your specific needs. In the latter case, you could use some Java Card technology based smartcard and write your own Java Card applet that manages your key and cryptography.

Regarding your requirement list:

Smartcards -- if accessible through PC/SC -- integrate quite well with Java on Windows (and mostly also on Mac, though this could be a bit more painful) through the Java Smartcard IO API.
Most smartcards (particularly Java Card-based ones) have built in functionality for PIN codes but I guess if you write your own applet you could build pretty much any known-secret based user authentication.
Smartcards usually do support on-card symmetric encryption/decryption. If it's feasible to do the whole symmetric encryption/decryption on-card (or if you only use the card to encypt/decrypt keys for symmetric cryptography) would typically depend on the amount of data that you want to encrypt/decrypt. Performance of and communication with a smartcard is typically very slow compared to doing this on the PC side.

One product that comes to my mind is Yubikey Neo. It comes in USB key form factor (with additional contactless interface), can be configured to be accessible through PC/SC, comes with various pre-loaded crypto applications and you can load your own Java Card applications onto it. As far as I found out it should support RSA-2048 and at least 128-bit AES.


Is the "same registrable domain" a sound security basis for cookies?

All browsers use the "Public Suffix List", at https://publicsuffix.org/

Besides TLDs, it lists all suffixes "under" which people can have their own domain (for free or not).

This is also called the "eTLD+1" policy, eTLD being "effective TLD", so not necessarily a real "Top" Level Domain, but any suffix that works effectively as a TLD, hence allowing registrations under it.

  Is there one definition of what constitutes a "registrable domain" universally accepted?

Maybe not, but at least for now everything has converged on Mozilla curated Public Suffix List aka PSL.

Note that there was (and still is) various attempts to do the same thing, typically by storing in the DNS itself data about "relationships" between domains.

Latest attempt was DBOUND: https://datatracker.ietf.org/wg/dbound/about/

Its charter had:

  Various Internet protocols and applications require some mechanism for
  determining whether two domain names are related. The meaning of
  "related" in this context is not a unitary concept. The DBOUND working
  group will develop one or more solutions to this family of problems,
  and will clarify the types of relations relevant.

  [..]

  The current way most of this is handled is via a list published at
  publicsuffix.org (commonly known as the "Public Suffix List" or
  "PSL"), and the general goal is to accommodate anything people are
  using that for today. However, there are broadly speaking two use
  patterns. The first is a "top ancestor organization" case. In this
  case, the goal is to find a single superordinate name in the DNS tree
  that can properly make assertions about the policies and procedures of
  subordinate names. The second is to determine, given two different
  names, whether they are governed by the same administrative authority.
  The goal of the DBOUND working group is to develop a unified solution,
  if possible, for determining organizational domain boundaries.

The working group was closed in April 2017, by failure of finding a real working solution (people agreed there is a problem, but the work seemed too big and hence no offered solutions were convincing people enough to make it a working group document and advance it as a standard).

There are still some work by individuals, like:

https://datatracker.ietf.org/doc/draft-brotman-rdbd/ "Related Domains By DNS"
https://datatracker.ietf.org/doc/draft-levine-dbound-dns/ "Publishing Organization Boundaries in the DNS"

  Is it precise and decidable in all cases?

Yes, if you use the PSL.
It is not perfect, because the PSL is humanly curated. So some entries are missing on it, and some entries in it do not even resolve anymore so should be cleaned. However the problem is on authorization: which party should be authorized to change which content on this list?

  Do all browsers agree on what counts as a "registrable domain"?

Browsers use the PSL, yes.
You can find on https://publicsuffix.org/learn/ a (non-exhaustive) list of software using it, like libraries.

Note how it is used also:

by the DMARC specification (for email filtering)
by the CAB Forum requirements, to require CA to issue certificates only if they validate properly per the PSL
in HTML5
by Let's Encrypt to apply rate-limiting


There are some better explanations here, below is an educated guess : ARP poisoning between a wired and wireless network

The spoof should work almost immediately if it is working properly. New devices will see the gratuitous arp from the attacker and automatically update their cache. A victim will not detect duplicate IP, they should just update the mapping. The problem is likely at the router.

Arpspoof works through a switch because the switch has no way of knowing which port the legitimate IP address/MAC mapping is, so without any form of port security/DHCP snooping/Dynamic arp inspection, it has to trust that a device is who it says it is when it claims "192.168.1.1 is at aa:bb:cc:dd:ee:aa" in its arp reply/gratuitous arp.

I'm not sure about wireless networks but it seems to me that a router, even if it is operating at layer 2, switching traffic within the network, would likely analyze arp packets, just like a switch does, so that it could also update its own arp table. It may be dropping these gratuitous arps from the attacker because its plain for it to see that they are not legitimate, because they are using its address and advertising a different mac than its own.


Actually, your larger companies like Google or Facebook do, in fact, have a certificate. This is a CA-level certificate (able to sign other certificates and thus vouch for those holders' identity) which is either issued by an external CA, or whose public counterpart is registered as being implicitly trusted by OSes, web browsers, etc. Call it the Golden Key.

From this certificate, the company will generate additional "intermediate" certificates. These are also CA-level certificates, which are then used to generate end-level certificates that identify individual servers, endpoints and even internal workstations within the company's "private key infrastructure". Such an infrastructure allows the sysadmin to drastically reduce the amount of his network that has to be "trusted" (in reality such internal communications are only "trusted" because it's considered infeasible to secure them).

If an intermediate certificate is stolen, it's disruptive but usually not the end of the world. An attacker can do a lot with any CA certificate that has an unbroken "trust chain" up to a globally-trusted root. However, as soon as reports of a certificate for Google, signed by one of an unrelated company's intermediate CAs, becomes known, the jig is up; the company will issue a "revocation" of the signed certificate, and if it's believed that the CA has been fully compromised, will revoke the intermediate CA itself. A revocation is kind of an anti-certificate; it's signed in much the same way as a normal certificate, but tells any computer to which it is distributed not to trust certificates with a given signature, or that have been signed with a particular CA certificate. Now, this will revoke trust in all the legitimate certificates as well, which as I said is disruptive, but the company can recover, typically by re-issuing new certificates to all known legitimate certificate owners.

This happens from time to time. Notably, it happened to Comodo, a company whose primary business is issuing certificates to other companies. One of its CA certs was compromised and used to generate fake certificates for Google and other major sites for phishing and other nefarious purposes. As soon as it was clear that only one CA was affected, Comodo revoked that CA, transitioned legitimate certificate holders to new certificates signed by other non-compromised CA keys, then generated a new intermediate CA from its Golden Key to replace the revoked one, and it was back to business as usual.

If the Root Certificate, the Golden Key, of a company is stolen, that's the end of the world, for the company holding it at least. Root CA certificates are among the most valuable things in the hacker underworld. As such, there is usually an extreme level of security inherent in the storage of any device which holds the Golden Key (typically a Hardware Security Module). You can watch this video, showing just some of the rigamarole behind the generation and storage of the Root CA certificate for the DnsSec extensions to DNS, which add proof of origin and denial of existence capabilities to the standard DNS framework. If a Golden Certificate is believed to be compromised, everything underneath it in the hierarchy is suspect; there's no way to prove or disprove the legitimacy of any certificate signed by it. Therefore, the only thing you can do is revoke trust in that root certificate completely and deal with the fallout.

This is much rarer, but it has happened. DigiNotar, a Dutch root CA company similar to Comodo, was the victim of multiple attacks that compromised the company's trusted root certificate; the private key was then used to generate fake certificates for a number of major websites. DigiNotar could not reliably identify all the fakes, could not therefore guarantee they had all been revoked, and could not even guarantee that its root private key had not been copied offsite. As a result, the major OS and browser writers responded by simply revoking trust in DigiNotar's root certificate altogether. Hilarity ensued, as DigiNotar was the root CA for several Dutch Government websites, including the counterpart to the U.S. IRS. Imagine going to www.irs.gov and being told by your browser that the site may be fraudulent; that's exactly what happened to visitors of the Dutch Tax and Customs Administration website. The Dutch government quickly assumed control of DigiNotar's intermediate CAs, and transitioned all their sites to other certificate authorities. DigiNotar had filed for bankruptcy by the end of the same month.


Can a magical packet traverse thru a NAT?

Common NAT* as implemented in SoHo routers (i.e. DSL, FTTH, cable etc) maps multiple internal (local) IP addresses to a single external (public) IP address. Reaching an internal system from outside  requires a way to translate a packet coming in on the external (internet) interface (i.e. using the external IP+port as destination) to a packet on the internal network (using an IP+port on the internal network as destination).
With port forwarding, there is a predefined and fixed translation to a specific host and port.

Any other translation in NAT needs an outgoing packet from the internal to the external (internet) network first: the necessary translation from internal IP+port to external in the NAT table is only created if an outgoing packet creates a new state, like in a stateful firewall. If an incoming packet matches such a state/translation then the external IP+port can be translated back into an internal IP+port. If there is no state/translation then it is unknown how the packet should be translated and thus it gets discarded.

In other words: there is no magic packet that can pass through NAT because it is unknown which internal system this packet should be sent to.

But note that this does not mean that no direct access to internal systems can be initiated from outside. With IPv6 it is possible that the ISP assigns a customer a range of IPv6 address with the same prefix and the router makes these addresses usable in the internal network. Unless the router specifically blocks direct access an internal system could be reachable from outside by its public IPv6 address. But this is not traversing NAT since no NAT is involved here.

Additionally some routers erroneously make UPnP accessible on the external interface. This could allow an attacker to create explicit port forwardings on the router in order to access internal systems. But, this is still not a magic packet traversing the NAT.

* Note that there are also other type of NAT, where some set of public IP addresses gets translated to a set of local IP addresses. This might for example be used to map a range of local IPv4 addresses into a set of publicly accessible IPv6 addresses with the same prefix. I don't know of any SoHo router which offers this functionality.


How to determine whether an SSL certificate is single-domain or multi-domain

It will be considered as Multi Domain. Multi Domain also called as Multiple Domains. Now your details are like under:

Subject Alternative Name

DNS Name=thedomain.com
DNS Name=www.thedomain.com
DNS Name=mailer.thedomain.com
DNS Name=links.thedomain.com
DNS Name=landing.thedomain.com

Here every domain name will be count as an individual domain. Multi Domain SSL certificate gives you facility to protect more than one domain under the one shelter. Whether it has same TLD or different TLDs. In terms of SSL Certificate the alternative names you have provided while getting your certificate called as Subject Alternative Names or SAN. That understands every alternative name as different domain name. So in my suggestion your hosting provider is telling you right.

I do agree with point made by @INV3NT3D that Wildcard SSL Certificate would be better choice for you. You have to issue certificate on *.thedomain.com and everything in place of “ * ” (asterisk) will be covered.


Wordpress: a Virus detection plugin is necessary?

Yes.

Hosting a Content Management System (like Wordpress, Joomla, Drupal, and moslty all other CMS) means permitting users* to upload arbitrary files.

(* As users I mean: your authorized - but not necessarily experienced - users. Thanks to Jan Doggen for this precision)

So even if

your server doesn't try to execute this files,
your server is up to date and doesn't hold any known vulnerabilities

Uploaded files could be downloaded by other users and website visitors, who could use vulnerable systems.

In order to prevent this, if you hold arbitrary shared files, you have to check new uploaded files... And recheck them everytime your virus database will be upgraded (thanks to Steffen Ullrich for warning me about this)

But no.

If you

are the only authorized user on the box (or you really trust each other users)
don't care about what's happen outside your box,
keep your box up to date finely

Wordpress work fine without anti-virus


The ClientHello message determines what methods of SSL/TLS are supported by the machine, which can include TLSv1 (encoded as SSLv3.1), so after the ClientHello message the machines determined that TLSv1 would be the protocol to use and started the handshake process for TLS.


Is it possible to track a missing brand new phone?

First things first.

Since your package was tampered with, I do not expect you to have any details of the phone like the IMEI number, etc. Register a complaint with the website that you purchased the phone from. Even if you go to the police, they are going to ask you to talk with them first anyway. I suggest you talk to a senior customer care executive, which would be more efficient than just sending complaint mail.

Dive right in to the What Next? category. Follow the instructions given by the responsible people. Then file a police complaint if necessary. If you happen to know the vital details such as an IMEI from them, you have some base to search on.

There are many options available online to track a lost mobile phone by its IMEI number. If possible try it with your mobile company. They might have an advanced option to find it.

Failed Delivery:

But honestly, how did you even accept anything that has been tampered with? Even if something like this happens, isn't it a failed delivery and the website holds responsibility for it?

I hope you did not sign the received receipt. If you have, I am afraid that you have no assurance for getting genuine help from the website, or worse, anyone.


Packet-filtering firewall evasion (Scanning)

There are some academic papers on the subject, but they don't tend to address evasion.

The reason you keep seeing the caveat "old and poorly configured" is because it holds pretty true - there is a limited set of 'valid' connections and connection types, and it's entirely possible on modern firewalls, properly configured, to enumerate them all and simply ignore all other types (even if that's not what the user did explicitly).

Cisco IOS, to take the most famous example, is decades old, and TCP/IP just hasn't changed all that much; so there's been an awful lot of time to harden it against unwanted traffic (especially since that's a firewall's core competency).

Additionally, devices are also fast enough now that even very complex rules don't cause much overhead in most installations and so some of the old "packet X takes 50x longer to process than packet Y" indicators just don't work because 50x slower is still faster than the clock on the wire.


I suggest that you take a look at the results and procedures listed here

Copied verbatim:

Install openssl-utils (with its depencies this will require about 790KiB of storage)

opkg install openssl-util

Then run:

openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048 dsa2048 | tee /tmp/sslspeed

echo "|" `awk 'match($0,/r[0-9]+/) {print substr($0,RSTART,RLENGTH)}' /etc/banner` `awk -v FS=": " -v ORS="" '/(Processor|BogoMIPS|Hardware|machine|cpu model|system type)/ { print "| " $2 " " } END { print "" }' /proc/cpuinfo` `awk -v ORS="" '$1 ~ /OpenSSL/ {print "| " $2 " |"} $1 ~ /(md5|sha)/ {print "  " $5 " |"} $1 ~ /(des|aes)/ {b = b "  " $6 " |"} $1 ~ /(rsa|dsa)/ {print b "  " $6 " | " $7 " ";b=""} END { print "|" }' /tmp/sslspeed | sed 's/\.\(..\)k/\10/g'`

echo


Why don't mobile operators blacklist stolen phones using their IMEI?

Mobile operators already use this feature. By reporting the IMEI number of your stolen handset it will be recorded in the Equipment Identity Register (EIP) to prevent the use of the stolen handset in the network. After ensuring the device is stolen, the IMEI is transfered to Central Equipment Identity Register (CEIR) which is a database of handset on a blacklist and it will render the device unusable on all other network providers as well.

Many carriers, including AT&T and T-Mobile, are now using this shared database inside the U.S and Canada. As Rory mentioned, most European carriers are Europe-wide so this feature will work across Europe

I would also like to add that the killswitch is different than IMEI blocking. The main goal of the killswitch is to render the phone completely useless by remotely erasing all data from it and therefore turning a phone into "paperweight". As for the IMEI blocking, it only prevents the handset from connecting to the network (IF the specified network is using the shared database for blacklists)

The terms "paperweight" or "bricked phone" refer to a handset that has lost all operating system data, partition data, and bootloader data; preventing someone from re-flashing the OS on the phone. The handset is completely unusable, even for offline tasks such as taking pictures or running apps. In such a case the phone turns on, but constantly displays the manufacture logo screen. It literally has the value of a "paperweight"

Apart from rendering your phone completely useless the killswitch makes sure your sensitive data does not fall into the wrong hands.


How to quickly find out what the threat nature of a password protected archive is without getting infected?

I am wondering about how to find out the exact nature of the threat in a secure way

Doing malware analysis yourself is pretty hard - malware is often designed so that it can't easily be reverse engineered. Your best bet is searching for the VirusTotal results - unfortunately, there may not be any definite information on what your specific malware does exactly. Also, if malware connects back to a server and downloads additional pieces, it might be impossible to tell, as those pieces could change at any time, or depending on the specific target.

  Do previewing and extracting the archive impose any security risk

Unlikely, but possibly. Most run-of-the-mill malware relies on the user actively executing a file that contains code. There are several common ways to do that:

The simplest way is to just provide a .exe. There are some ways to hide the file extension so that it seems less suspicious (Windows has a bad habit of just hiding them)
Using a less-known file format, like .bat or .vbs, that are executable files too
By embedding macros in a Word document (or similar format). If you were to open such a document, Word would ask you if you wanted to execute the unsafe macro contents. Many users are trained to click "yes" on such a prompt, which would lead to executing the malware.

Likely, the encrypted zip is just a way of hiding the malicious contents from automated scanners that might detect a known malware.

But there is another possibility: the Malware might contain an actual exploit for a weakness in the software that you are running. That might be a known vulnerability relying on you using an outdated version (more likely) or even an undiscovered "zero-day" vulnerability (less likely). In that case, just viewing a "harmless" format like a .zip might lead to system compromise (although targeting a much more complex format like .docx or .pdf using a document inside the zip that would have to be opened is probably much more likely).

In any case, using a VM was definitely the safe choice - just make sure to not connect it to the Internet and dispose of it afterwards. By contacting your security department about it you definitely did the right thing - they might have the resources to further analyze the threat, or at least block those specific mails from going through.


That's the usual confusion of "signing is like encrypting with your private key".

Just forget it. It is a terrible explanation which does not work. It just seemed to work in days of yore, when the very first digital signature algorithm (based on asymmetric cryptography) was first described (I am talking about RSA and it was in the Disco era); but even for RSA it is not correct since it fails to take into account padding, which is critical for security.

Have a look at PKCS#1 to see how RSA is used. In particular, when encrypting data with RSA and a 1024-bit key, the most you can encrypt in one go is 117 bytes, but the encryption result is always 128 bytes, and that's what a decryption engine expects. Regardless of how much you try, 128 bytes will not fit in less than 117 bytes...

What must be remembered is that a private key is what is used to do something that should not be doable by everybody. This means data decryption (anybody can encrypt a message to Bob, but only Bob should bee able to read it) and signature generation (everybody can verify a signature, but only Bob should be able to produce a signature that everybody can verify as being from Bob).

Although there are asymmetric encryption algorithms which can use the same kind of key as digital signature algorithms (there is RSA encryption and there is RSA signatures, and both use "RSA keys"), using the same key for both is not a good idea.


How to perform a security test/review/penetration testing of Ethernet ports?

This is a broad question, as there are several different ways to assess the security of Ethernet ports. However, there are a few things that are usually covered in this type of scope.

The first (and most straightforward) thing to test is whether any sort of Network Access Control is in place. If you're being asked to assess the security of a port, there is presumably some security control that the client wants tested. It might be a good idea to ask the client what, specifically, they want assessed.

The easiest way to test whether Network Access Control is functioning correctly is to simply plug into the Ethernet port and see what happens. Are you given an IP? If you set a static IP (vs. using DHCP), does that work? Or is there some agent-based access control that's stopping you from connecting? Is there a "walled garden" once you connect to the network?

Once you're connected, what can you see? Can you port scan (nmap) the local network? Are you in some sort of a segregated environment? What else is running nearby on the network? Is the network controlling your DNS, or can you resolve anything you want? Is there egress filtering to the Internet?

Lastly, there's always the physical security element: is the port in question in a public area, like a lobby or waiting room? Is that intended? Do untrusted actors have physical access to the port?

From the answers to these questions, you should hopefully be able to determine how secure the Ethernet setup is -- and hopefully write recommendations to improve security based on what you find. Like I said earlier, though, you should definitely check with the client before doing any of this stuff -- they'll know what their goals are, and should be able to tell you what they want to learn.

Good luck!


Maybe you're just looking for the best RSS feeds for the latest info? In that case consider https://packetstormsecurity.com/feeds

More specifically, for your needs, I recommend following:

https://rss.packetstormsecurity.com/news/tags/goverment/
https://rss.packetstormsecurity.com/news/

Or just follow http://world.einnews.com/news/europe-security 's RSS feed.

EDUT: In regard to the first part of your Q - I do not know about the proceedings. I just gave you a list of feeds to follow if you'd like to stay updated. If anyone is able to give you a better answer, pick the other one.


Has the WPS brute-force cracking issue been fixed?

The three major problems with WPS are: (1) it requires only an 8 digit pin (10^8 is a small keyspace), (2) one digit of that pin is a checksum (hence 7 independent digits and 10^7 pins to check), and (3) the first group of four digits is checked independently - that is you need to only check at most 10^4 ~ 10000 pins to break the first group of four digits; and then 1000 to check the second group (since you know one digit due to the checksum).  And really the expected number of attempts is half that; so on average only ~5500 attempts are needed.

WPS slightly mitigates this by mandating that you are locked out for 60 seconds after three consecutive bad attempts.  Originally, not all WPS routers enforced this timeout (very bad even without vulnerabilities 2 and 3; checking at a rate of 10 per second; means you can break your neighbor's router in a few months).  Some manufacturers will increase this timeout on subsequent failures, which is good.  Note the three attempts = 60s timeout is not a panacea; e.g., will take 3.82 days on average (and at most 7.64 days) to crack into your neighbors WPS enabled router.  Granted exponential timeouts could mitigate brute forcing; however how these timeouts are implemented is important.  (E.g., if the attacker changes their wifi mac address on each attempt will they continue to be blocked out?  Otherwise can you use this to DoS WPS connections?).

Now to answer your question: CERT (last updated May 2012)  is "currently unaware of a practical solution to this problem" and recommends disabling WPS.

Also while there are rumors of a new WPS 2.0 standard eventually coming out, especially in the responses to this vulnerability.  Hopefully, this fix would not let an attacker know if they've found a portion of the key and hopefully would require all digits to be independent instead of having a worthless checksum.  However, the wifi alliance page on WPS doesn't mention this at all (e.g., the last press-release on WPS is from Feb 2008) unless its in one of the standards that cost $100-$200 to purchase.  Standards tend to change slowly as it requires both the software and hardware end of the client and router to be fully compatible (and backward-compatible).

Granted, I'd expect nowadays more WPS enabled routers to implement the 60s + exponential timeout, but still would never recommend for anyone to use WPS.


Does apt-get enforce cryptographic authentication and integrity validation by default for all packages? (debian, ubuntu)

There are two types of cryptographic validation here:

Apt supports that each developer signs the package with its own key, and to validate that on package install. This is what this file refers to and is not used (currently) by Debian, Ubuntu, etc.

The repository manifest is cryptographically signed with a repository key (see apt-secure(8)) and that validates the referred packages. That is used by all of them.

So, there is a cryptographic validation, just not the one that file refers to.


Methods of determining if a software bug is a security risk?

The methodical approach  to this is to go through a standard software security framework such as  OWASP Software Assurance Maturity Model (OWASP SAMM Project) or BSSIM or any other other standard Software Security Maturity model. You need to properly identify the things such as Threat agents, Attack vectors, Security weakness, Security controls, Technical impacts and Business impacts of your identified bug in terms of security.

Then you need to model it using a Threat model framework and rank your identified bug. There are numerous threat models such as CVSS , DREAD, STRIDE. Finally you need to identify the ROI of the effort you need to put to resolve this issue. The business would use the values returned by your model analysis and give a go or no go to fix the issue.


Can a user have a certificate or does only a machine have a certificate?

Personal Certificates are very common in a PKI infrastructure. And I would say that most often it's stored on the computer of that user/person.

It would of course be preferable to have the certificate and private keys stored on a smart card as mentioned in another answer but there is limited support for smart cards in for example smart phones.

One way to do this is to have unique keys and certificates (with the
same DN) on several devices. Then you can easily revoke a certificate
if a device is stolen. The problem with this approach is for example
encryption. If there was an email encrypted with the public key
corresponding to a certificate on your smart phone, that email cannot
be read on your laptop and vice versa.
One middle ground would be to have different certificates on every
device but with the same private key, with this approach you can
still read encrypted messages on all units. But if one unit becomes
compromised you will need to revoke all certificates.
And the simplest solution is to have the same certificate and keys
distributed to all your units. This have the same drawbacks as the
option above.

These certificates and keys are stored differently depending on OS and application. MacOS stores them in the key ring for most of the applications. Firefox can stored them in its own key ring, and so on.