Using Different Algorithms in Single PKI

As per X.509, no problem. You can mix algorithms at will. Each signature is independent.

(X.509 includes a special provision for when a CA uses DSS and issues a certificate that also uses DSS with the same group parameters, in which case the issued certificate may omit the group parameters. This is called "parameter inheritance". This is never used in practice, and was not ported to ECDSA, even though it was a possibility and was apparently envisioned at some point. This is the only case, to my knowledge, where the signature algorithms at various levels in the chain have any relationship together.)

However, you must understand that by using several distinct algorithms, you force "relying parties" (systems that must validate these chains) to implement all of them. While this is normally not a problem for desktop systems and servers and smartphones, this could be an issue for small, embedded devices that want to save on code size, and would prefer not to include code for RSA and for ECDSA.

This kind of problematic is incarnated e.g. in SSL, where client and server tell each other what kind of algorithm they support for validating signatures on certificates (see for instance the Certificate Request message). This is meant to better support small devices with little code space. Making a mixture of RSA and ECDSA in your certificate chains puts you a bit at odds with that principle. Depending on your context, this may or may not matter (it will probably not matter).

In any case, that kind of mixed chain is expected for a transition. Suppose that you start with a full-RSA world; the root CA has been distributed to all client systems (possibly at a heavy cost). Now, you take the decision to switch to ECDSA, because client software is up to it (e.g. it came with normal OS / browser updates), but creating a new ECDSA root and pushing it onto all clients will take a lot of time. So, to begin using ECDSA without breaking things for the installed base, you make cross-certificates:

oldRoot uses a RSA key.
newRoot uses an ECDSA key.
To allow people to validate certificates issued by newRoot even if they do not know newRoot as a trusted root, a cross-certificate is issued, containing the name and public key of newRoot, but signed by oldRoot.

This cross-certificate allows systems that know newRoot as a trusted root to validate a certificate with a path "newRoot->cert", and systems that only know oldRoot will use "oldRoot->newRoot->cert" (in the latter case, going through the cross-certificate). In other words, newRoot has two certificates, one self-signed (with ECDSA), the other signed by oldRoot (making newRoot an intermediate CA).

This is a fairly standard method to handle renewals with key changes, but it necessarily implies, in the case of a RSA-to-ECDSA transition, mixed-algorithm chains. Thus, the situation that you describe is not only supported but expected.

To sum up: using completely separate PKI allows for single-algorithm PKI, which may help embedded devices (only one algorithm to implement). However, mixed-algorithm PKI are a normal thing, well supported, and expected in case of PKI-wide transitions to new algorithms.


Is it possible to brute force a card reader lock?

No it isnt possible. Cards do send a Another signal to the wiegand controller than the code, so the wiegand controller wont accept a card entered as a code, or a code entered as a card.

You could ask the landlord or administrator of the building to add the tag for the different lock, into the "authorized list" of that reader or controller. Then the tag on your keychain, which is EM4102, will then work both for the lock where it originally works, and for the lock on your building, so you have one single tag for both locks. Thats not a security risk since nothing is stored inside the tag except for a read-only serial, the tag itself does not know where it belongs to.

But I Think you will get a card. Propably there was keylock or only a code lock Before, and its very common when Rolling out a card-access-system, to just give a common Group code, until cards are rolled out.
Then the common Group code is deleted from system. This to ensure no authorized person is rejected access to the building until the transisition period is over.

I have even seen setups where administrators, when setting up card readers without a keypad, to put a common card inside a "real estate lock box", and give the lockbox code to everyone that should have access to the building.
When all cards/tags are rolled out, then the common card and lock box are removed from the wall and from the authorized list.


What is the risk of cross site scripting if I embed javascript into a website

You embedding javascript probably won't be an issue, unless you somehow embed functionality that allows for cross site scripting (your javascript would need to accept some input from the client or and display it on the page - or other dynamic data, like something delivered to your app as part of an API call).  Other than that, you are the one putting the javascript in there, so I would assume you have vetted it.

I would be more concerned about the site building software that you are using. If you provide the name perhaps we could look for known vulnerabilities.

If the site you are building either stores user input (in a database for instance) insecurly and then displays it again it could be vulnerable to XSS.

Also if it reflects user input that could also be used for XSS.  By reflect I mean it takes some user input and insecurely renders it to the screen immediately without storing it on the server side.  On example would be if the following URL:

http://mysite.com/account/confirm?email=myemail@email.com

output:

  Thanks for confirming your account with the email: myemail@email.com!


Would people object my website just because I use Google Analytics, +1, or FB Connect?

This depends on your target group.

Like, Tweets, +1

In Germany, for example, the privacy advisor of several states have claimed that the Facebook like-button violates German privacy laws. The threats by the privacy advisor of the state Schleswig-Holstein, to fine the governmental organizations and companies, which do not remove those things, got wide media attention.

Still most people will not care at all. But if you have a target group, that is very aware of privacy issues and Facebook repeated violation of the laws, this might have a negative impact. Although it is more likely that his group is using browser extensions to suppress the social plugins anyway.

Heise developed a two clicks for more privacy approach, which only loads the social buttons after the user clicked on a placeholder.

Google Analytics

As far as Google Analytics is concerned, you can probably get similar information by analyzing the server log files. There is a number of tools available for that.

Facebook Connect, OAuth, Open ID

They can be embedded in a way, which does not send any information unless they are actually used. So instead of using the JavaScript SDK for Facebook-Connect, just add a button with a locally stored image and a plain link to the Facebook permission page.

But it may be an issue, if Facebook is the only way to authenticate.

(Since you asked about the public opinion, all links go to press coverage. Unfortunately, I am primarily aware of the press coverage in my own country, so those links go to German sites. Google Translate might be helpful).


Is it OK to put the CSRF token in a cookie?

Putting the CSRF token in a cookie instead of in a form field or HTTP header is a bad approach, and will not work. The thing that makes the CSRF token effective is that (unlike e.g. a session cookie) it is not sent automatically on all requests. It has to be added manually by your application. If you put it in a cookie, it will be send automatically and thereby it looses it's effect.

Of course, if you are using the double submit cookie pattern you will need a cookie. But that is a different story.


Severity and priority rank of Insecure Direct Object Reference bug

I'd actually say that sounds only moderately severe, because the direct harm that can be done is pretty minor. An attacker can breach a degree of confidentiality (information disclosure), can inconvenience people, can potentially deceive people, and can definitely damage the company's reputation, but can't directly cause much harm (e.g. force people to buy things, access information useful for identity theft, take over user accounts, or gain unauthorized access to the server).

I'd call it a pretty high priority, though. Direct object references are relatively easy to discover and usually also easy to exploit (i.e. usually it's just an integer you can iterate through), and the exploit can generally be scaled easily to affect a large number of people (they tend to be very amenable to automation and not require any interaction on anybody else's part). Ease of discovery and exploitation usually raise the priority, even when the severity is only middling.


Does Linux and Mac OSX have built-in Credential/Password Managers with API access?

Yes, Apple iOS and Mac OS X have an internal Keychain with Api access, have a look at Apple Dev doc


The "SHA" module in Windows Server is the module that identifies, compares and processes SHA signatures, just as much as the connection you're using.

RDP uses the SHA module to identify and compare showed and received files to ensure integrity, as example.

Without the SHA module, RDP indeed doesn't work, since it depends on it being there.


Renegotiation usually happens in the HTTP client in the following cases:

the server requires a renegotiation, typically because the client tries to access a resource which requires a client certificate which the previous handshake did not include
a renegotiation is done for security reasons after some time or number of bytes transferred. In OpenSSL this can be tuned with BIO_set_ssl_renegotiate_bytes and BIO_set_ssl_renegotiate_timeout
if the 64-bit TLS sequence number would overflow a renegotiation is needed

There is not really a need for the user or even developer to tune after how much time or transferred bytes a renegotiation should happen. And some short grep over the  source code of Chromium does not indicate any place where the browser explicitly sets these parameters, i.e. it will simply rely on the underlying TLS stack. This is BoringSSL in case of Chromium which is a derivative of OpenSSL so you can probably use the functions described above to do your own tuning by modifying the source code.


How do I securely deal with SSL certificate validation failure when the client date is incorrect?

Using the date from the server itself is self-defeating: a fake server could send a fake date.

Actually there is in SSL itself a field for the date: the first four bytes of the client_random and server_random fields contain the current date and time, as known by the client and the server, respectively. This implies the following:

A passive attacker, eavesdropping on the line, can detect clients whose clock is amiss.
An active attacker, running a fake server, can know the client's date and time, down to a precision of 1 second.

The attack scenario here is an attacker who has stolen an server's private key. The certificate has been revoked; however, the attacker also obtained CA certificates and CRL which "proved" the certificate to be valid at various previous dates. The attacker, in position to do MitM, then runs a fake server and emulates the Internet at that time, in particular sending back to the client the past CRL bearing the date that the client believes to be current.

An out of date client may make connections fail in case their current date is too far in the past, or too far in the future. The normal recovery for that case is to complain to the user, so that he sets the date and time properly. On a pure theoretical basis, there cannot be any other method which always works against MitM attackers: such an attacker can, as I said, "emulate" an old version of the Internet (as a whole), thus preventing the device from obtaining the true current date or even noticing that its clock is not set properly.

You could try to obtain a time stamp from some Time Stamp Authority; however, this implies validating the TSA certificate, or, more accurately, assuming that the TSA private key has never been stolen. So, in practice, it is possible to make a reasonably strong guess of the current date and time in a way which attackers will find difficult to fool. But that's expensive (extra connections to TSA) and depends on these external TSA, who might not be free and/or might not agree with getting so many time stamp requests from your deployed devices.

Edit: if you do revocation checks with OCSP, and the client insists on including a nonce in the request, then you get (somehow) the same property as with the TSA -- with the same caveats: you still have to assume that some entity's key has not been stolen (TSA, OCSP responder, CA...), and you still need to do extra connections.


Signing API requests with a private key: Does this key delivery scenario sound secure?

if C finds out D's X-USERNAME then they can access D's data which seems even less secure than userID/password.

Can they? B might generate a separate certificate for each customer which can only be used to access their data. The X-Username header might simply be metadata. But you might want to try this out to be sure. Especially when they don't ask for which customer they are supposed to sign the certificate.


When in Firefox I type web.whatsapp.com for whatsapp web, I get a browser re-direct.

That is concerning and could be an indicator for malware (adware) or a man-in-the-middle attack.

  Anybody knows some good approach about cleaning this sort of stuff from the sytem?

Since you have only been giving generic information about what's going on I can only redirect you to a generic answer on how to deal with a compromised server.

  Here are some suspicious connections on netsat -tulpan output:

tcp 0 0 192.168.1.2:50465 198.252.206.25:80 ESTABLISHED 4556/firefox
(...)

There is nothing inherently suspicious about the presented output. What you are seeing are several open TCP connections which is absolutely normal for an active browser session. The target ports 80 and 443 indicate that you are probably communicating with web services.

You can lookup the IP addresses online or perform a reverse DNS query, for example via the host(1) command, to find out more about the servers you are connected to. For example:

$ host 198.252.206.25
25.206.252.198.in-addr.arpa domain name pointer stackoverflow.com.

As you can see the first IP seems to belong to stackoverflow. That said, if you assume you have been compromised you should also be aware that all analysis from within the affected system is unreliable.


Find changes and modifications made to system by application or virus,

Just a quick hint, you can always use a hardware machine and make a binary copy of the hard drive. Both copies will need to be compared. You can do this by running a checksum. Just be sure nothing is run from the hard drive.

I think backtrack has a nice toolset to do such analysis. You can find them under digital forensics.


4-dial combination padlock: Is it more secure to zero it out or to blindly spin the dials after locking?

I would recommend setting it to 0000 or some other specified combination (doesn't really matter what).

"Mashing around the dials" is a little vague, but I would guess based on my own behavior that people would tend to move most or all of the dials at once, which would create a strong correlation between the current combination and the lock combination. For instance, if the lock combination is 1234, someone might change it to 5678 (probably not exactly, but close enough that an attacker could prioritize the combinations they try).

Humans also have a tendency to think some things seem more secure when they actually weaken security. Someone may try to set it to a combination that seems "further" from the lock combination, such as changing 1234 to 6578 instead of 2142 because 2142 is too "close" to the lock combination. This could allow an attacker to prioritize the order they attempt combinations. Specifying a constant value to set it to avoids such issues.


Where to start preparing for SOC 2 type 2?

A requirement is that you get an assessor to evaluate your controls. You actually want to start with that step and get their guidance on how to start because they and you will need to agree on scope and what control set will be relevant.

The reason why you are not getting good guidance from the Internet is because your task is exactly like writing a book and not like passing an exam. Your assessor will help you figure out what you are supposed to be writing and how long your book is supposed to be.


Is it enough to look at the sender's email address?

Email is a very old plain-text protocol (dating from the 1970s/1980s).

Anyone who controls a mail-server can send out mail from their mailserver using any return address (including ones at other domain).   SMTP doesn't include any checks that the mail came from a mail server who controlled the domain listed on the From: line.

Extensions to email protocols exist to help prevent this email spoofing problem (see specifically DKIM, SPF, DMARC).

Bottom line, you can't naively trust the From line in an email.


How are private keys distributed safely?

This image is confusing. The private key of the sender is different from the private key of the receiver. These keys are private, so not even the proper sender and receiver know each others private keys. They are not distributed at all, only public keys are. I don't know why this image portraits them being the same. Also there are two public keys. One for each private key. You should probably find a better image.


What do these terms means with relation to viruses and operating system?

Malicious software will often use the Windows API (Application Program Interface) to perform it's activities. In some cases malware will monitor and hook these function, there are many ways to do this:

Inline
IAT (Import Address Table)
EAT (Export Address Table)
Guard Pages

Hooking a function allows the program to analyse and/or modify the function parameters or return result. This can be used to hide from antivirus solutions, load more malicious code into other processes etc...

Inline hooking is often achieved by overwriting the first few bytes of the function with a jump to malicious code.

IAT and EAT hooks are modifications to the PE (Portable Executable) header which redirect called functions to the malicious code.

Guard Pages can be used to hook functions as the malware can set guard pages on the first bytes of a function and handle the exception when the memory is executed.

Infecting / Embedding code in executables requires in-depth knowledge of the PE format. Using the Windows API a program can read and write to files on disk. The basic steps a program would need to follow to infect an executable:

Open the executable file with read and write access
Create a new section in the executable and write the shellcode into the file
Modify the PE Entry Point to point to the virtual address of the new section

If you are interested in the PE format, I suggest this link - http://www.openrce.org/reference_library/files/reference/PE%20Format.pdf


Encode metasploit payload with ContextEncoding?

You probably don't really want Context Encoding.  Context Encoding is a technique for generating self-decrypting shellcode that will only work on the intended machine. It is off by default because it requires knowing specific information about the victim that you usually do not have unless you have already compromised that machine.

msfvenom can take shellcode on stdin and output encoded shellcode on stdout like so:

cat payload.bin | msfvenom -p - -a x86 --platform windows -e x86/shikata_ga_nai -f raw > encoded.bin


Is there an SSL / TLS Certificate state-cache on Windows, IE, and Outlook and how it it managed?

The 'Clear SSL State' button is there to purge the SSL cache of selected Client Certificates used for authenticating to SSL-based services. It's just there to make client-certificates work faster (partly by remembering which certificate you used to authenticate to a certain site). It doesn't cache previously seen SSL certificates.

Outlook+Exchange can use Client Certificates for authentication, but it's not a common configuration; most sites stick with NTLM or Kerberos over SSL.

Outlook+IMAP can't use client-certificates, but I may very well be wrong; I haven't heard of an instance where they're used.

What you may be running into instead is problems with the Windows SSL Validator.


Can TPM be used in the same way as TrustZone area?

No. A TPM offers a fixed set of functionality which does not include arbitrary code execution. The functionality set centers around using keys in the TPM for a fixed set of features, mainly authentication (proving that a value was signed on this particular computer), device-bound storage (encrypting data in such a way that it can only be decrypted on this particular computer) and platform attestation (proving that the computer memory is in a known state). The only way to extend a TPM's functionality set would be to flash a new firmware, and this ability is restricted to the manufacturer and there may only be room for a few patch points anyway.

In contrast, TrustZone is merely an isolation feature. It does not impose any constraint on what (or how much) code runs in the secure world. If the operating system of the secure world allows it, you can install applications that preform arbitrary computation with the device-bound keys. Of course, if you aren't the chip manufacturer, you often won't have the necessary keys to install code in the secure world.

Sufficiently recent Intel chips offer somewhat similar functionality (but with a very different architecture) through TXT. TXT uses the TPM to authenticate the code that runs in a TXT partition and store the partition's data securely, but the application runs on the main CPU, not on the TPM.


Randomizing system call numbers to prevent rootkits?

That'd be a very disruptive thing to do; you wouldn't be able to run any binary on your system, and would have to compile everything from scratch; including the compiler.

Security by obscurity hardly works.


What are the advantages/disadvantages of changing the SSH/SFTP port in Linux?

As you've speculated, changing the SSH port from 22 to another port is basically "security by obscurity" and only carries with it minimal advantages.

The main advantage is less botnet/automated traffic will come in on port 22 looking to run SSH attacks.  However, it is fairly trivial for a real attacker, or a botnet with a more astute programmer running it; to run a port scan against all the ports.  Port 20,000 (or whatever number) will clearly respond with an SSH handshake, and thus they'll try attacks on that port.  End of security advantages.

Generally, what these bots try to do is:

Brute force 'root' or 'admin' password by using common passwords and/or dictionaries/and or random characters.
Try SSH vulnerabilities or exploits to get to a shell, or use common users like nginx/nginx in order to get a beachhead shell into the system.

Of course, using fail2ban or similar software to blacklist IPs after so many failed attempts will mitigate the chances of a successful brute force attack.  You can also restrict your SSH daemon to only use SSH-key based authentication and disallow password authentication; thus making brute force attacks unfeasible.

To respond to some of the further information you provided, please note that it is a best practice to disable remote SSH logins from your root account.  Simply enabling multifactor authentication is sub optimal, you should have all sudoers users having to login with multifactor; and then needing to use sudo to issue commands from there.

So, in short, you might receive less scan activity on an odd port.  However, it's no replacement for using best practices for securing your SSH daemon, such as fail2ban, hardened sshd configuration (e.g. disallow SSH1, etc), two factor authentication, restricting SSH users/groups, not logging in as root directly, properly configured sudoers, and regular security patches/updates.


Threatening text messages on my cell phone, 120 in one day but no phone number for sender, how do I get this info?

Sadly it will be very hard to track down the sender.

The only way to track down a sender without a senders id to go through your carrier. For them the procedure is also hard as they would have to do the following:

Track the message -> Track all hops it went through until it got to you -> Contact the senders service provider and ask for information (Only works with a court order [Unless the sender uses the same service provider])

Since all this will probably not happen unless theere is a court order I suggest you contact authorities and work with them on stopping the sender.


Figuring out which cipher suites to remove can be very difficult.  For Windows, I've used the free IIS Crypto tool in the past:

IIS Crypto is a free tool that gives administrators the ability to enable or disable
protocols, ciphers, hashes and key exchange algorithms on Windows Server 2003, 2008
and 2012. It also lets you reorder SSL/TLS cipher suites offered by IIS, implement
best practices with a single click and test your website.

This not only leverages someone's expert knowledge as far as which algorithms are more or less secure, but also takes the pain of figuring out how to actually implement the change in Windows away (hint: it's a bunch of registry entries).


How do attacks on password locked accounts work?

Brute Force Options:

Credential Spraying (distributed brute force): try the same password on multiple accounts or multiple systems (or variations on this theme). No one account is getting focus, so the attack on each account goes under the radar.

Offline Brute Force: use a weakness in the system to extract the password database that contains the (hopefully) hashed passwords. Take all the time you want to crack each hash (or the hash of the account you want).

Online Brute Force: public sites don't lock the account when there are too many tries. They might block the IP of the source of the failures, but then the attacker can change IPs. It's possible to slow attacks down to stay under the settings of the automated protection mechanisms.

Password reuse: look up a database of breached credentials and try that combination on popular services. It's effectively one try per service. For accounts that show up multiple times, use the collection of passwords used.

Process Weaknesses:

Authentication weaknesses: flaws in the system might allow the attacker to gain access to other accounts or parts of the information that should only be accessible to the authorised account. This is pretty rare and a highly specific problem.

Social Engineering:

Phishing: just ask the person for their credentials

Help Desk Hacking: use weak password reset processes or the online support desk to get the service to grant the attacker access to the account


Encrypting text file with AES 256 instead of password manager

Considering those compromises you mention, do you think that encrypting files yourself will be easy? How do you know you won't get into those same pitfalls that resulted in compromises of password managers?

AES 256 is believed to be computationally secure. Every computer ever made working simultaneously to brute force the key, working since the beginning of time, would have a probabilistically negligible chance of ever finding the key to an encryption.

However: a secure algorithm doesn't guarantee a secure implementation. Just to give you an example, here are a few questions you should ask yourself:

How are you going to ensure that two identical passwords in your list are not encrypted to identical AES ciphertext? (so that if the adversary knows one password, he'll know where it is reused)
Are you sure your decrypted password list cannot be reclaimed by a process allocating RAM after you have consulted your list?
Are you sure your decrypted password list will not end up is the swapfile?
What communication mechanisms will you use between the user providing the master password, the process decrypting the password list and the target application in need of one password?

Password managers are designed with those (and perhaps many others) concerns in mind. It's almost impossible to get everything right when doing it yourself the first time, especially if you're not a security expert.


How can Heap Pollution cause a security flaw

I would take the similar example from the link you quoted. In the example i will get the userid (Integer) as argument and try to validate it against database.

class ListUtility {
  private static void addToList(List list, Object obj) {
    list.add(obj); // Unchecked warning
  }

  private static boolean validateUser(List list){
     boolean isValidUser=false;
     Statement stmt = conn.createStatement(); //conn is a jdbc Connection
     String Query="SELECT userid FROM Customers WHERE userid='"+list.get(0)+"'"; //developer expects list.get(0) is a integer
     ResultSet rs = stmt.executeQuery(Query);
     if (rs.next()) {
         System.out.println("Valid User");
         isValidUser=true;
       }
     return isValidUser; //returns true for args[0]=something' or '1'='1
   }

  public static void main(String[] args) {
    List<Integer> list = new ArrayList<Integer> ();
    addToList(list, args[0]); //arg[0] is expected to be a valid userid of type Integer(say)
    validateuser(list);

  }

}

Now If i invoke the program with the argument  something' or '1'='1 it will print "Valid User". This is a typical Sql Injection. But this has succeeded because of Heap Pollution where we added args[0] to list even though the type didn't match.

Heap pollution is possible in this case because the parameterized type information is discarded before execution.

The call to addToList(list,args[0]) succeeds in adding an String to list, although list is of type List<Integer>.  Also, the call to validateUser(List list) takes the list of type List<Object> instead of strict List<Integer> .

This Java runtime does not throw a ClassCastException since the value list was not  read with an invalid type in this example.
Because the list is never read strictly as List<Integer>.


Is my iPhone being targeted by the US Department of Defense?

I don't believe you (or anyone else) is targeted by the US Department of Defense. More plausibly, AT&T screwed up something on their server.

A very quick research on the number 1111301000 returns this article which seemingly sent by AT&T.

Regarding the number 6.216.198.5, it's a coincidence that a substring of AT&T's IP address pointed to the US Department of Defense. Searching that exact number returned a bug report "cannot receive MMS using AT+T" on Ubuntu's launchpad which contained

00000000 01 06 27 61 70 70 6c 69 63 61 74 69 6f 6e 2f 76 |..'application/v|
00000010 6e 64 2e 77 61 70 2e 6d 6d 73 2d 6d 65 73 73 61 |nd.wap.mms-messa|
00000020 67 65 00 af 84 8d 01 81 b4 84 8c 82 98 41 36 30 |ge...........A60|
00000030 35 32 38 31 33 32 39 31 31 35 30 30 30 31 38 30 |5281329115000180|
00000040 30 30 30 35 30 30 30 30 00 8d 90 89 18 80 2b 31 |00050000......+1|
00000050 36 31 37 36 39 39 30 36 35 35 2f 54 59 50 45 3d |6176990655/TYPE=|
00000060 50 4c 4d 4e 00 96 02 ea 00 8a 80 8e 02 80 00 88 |PLMN............|
00000070 05 81 03 05 46 00 83 68 74 74 70 3a 2f 2f 31 36 |....F..http://16|
00000080 36 2e 32 31 36 2e 31 39 38 2e 35 3a 38 30 30 38 |6.216.198.5:8008|
00000090 2f 30 35 32 38 31 33 32 39 31 31 35 30 30 30 31 |/052813291150001|

Note the last 2 lines: it contained a similar pattern 6.216.198.5:8008/<long string of number>. However, the line before that contained http://16, which means it's actually pointing to http://166.216.198.5. That IP address is actually owned by AT&T Wireless.


This page includes a password or credit card input in a non-secure context

Currently I am not able to purchase this service. So what should I do to resolve this situation by avoiding future problems?

It's pretty simple: use https. Chrome has detected that you're passing around private information on an unsecured channel, and is rightfully telling you that that's a major security issue.

There are many options for purchasing a TLS (SSL) certificate, including the monetarily free Lets Encrypt, but this isn't a forum for service recommendations. What really matters is that you get one.


Have I Been Pwned Breached Email List by Domain Names

Here's the answer from the CTI Vendor. (Name replaced with Vendor X)

  For HIBP, Vendor X had a custom and paid integration. Vendor X paid
  HIBP a fee whenever a new breach (which Vendor X did not have) was
  acquired by HIBP. Therefore, we did not use the Open API, we built a
  custom integration that pushed any new breach acquired by HIBP into
  the Vendor X portal. This was the reason no passwords were ever
  present in HIBP breaches in Vendor's portal (paid service), because
  under UK and GDPR law, any exchange of PII (including passwords)
  between any two entities, where money is involved, is a crime.


Why is TLS still commonly referred to as SSL?

The best blog post that I have read about this states, in summary, that though TLS effectively replaced SSL nearly 19 years ago, TLS is still being referred to as SSL because SSL has been known to "convey meaning better" than TLS.

This is further supported by well-known companies still using the SSL naming convention in their products and services (e.g. OpenSSL, Mozilla SSL Config generator, SSL Labs SSL test).

Also, it seems this question may have already been resolved here and was closed due to it being primarily opinion based.


Using AutoHotKey-like tools for usable long passwords

No, It gets you a decrease in security because you now have your passwords in a searchable file.

A password manager does the same job but holds the data securely. It is also likely to have mitigation tools for common attacks.


Who can see an unencrypted email sent to Gmail?

The basic answer is SMTP.

HTTPS is only a consideration on the 'last mile', if you will - between the end user and the mail client (in this case).
In the case of IMAPS or POP3S, the same would be true - that encryption protects the communication between the mail client and the IMAP or POP3 server.

In order for these to 'see' the mail, it first needs to be sent between hosts via SMTP.

When your bank sends an unencrypted email to your Gmail address, anyone able to see traffic on the network between your bank's email server and their next relay/hop in the mail path can see the full contents (i.e. Google's server).

There is a long list of who that could be.

It could include local staff at the bank, third parties providing e.g. security monitoring to the bank's network, and so on. The same would be true of all network providers between the bank and Google, and the same would be true of anyone at Google able to sniff the relevant traffic.

Basically, if you run a traceroute from you to google's server, everyone on that can see your email.

Plus any state-level actor, it seems, with a passing interest.

The 'last-mile' between you and your inbox, though, should be safe(r) if properly encrypted (and assuming your machine isn't compromised).


One SSL Certificate for Client and Server Auth?

Beware of terminology. Certificates relate to asymmetric cryptography in which keys go in pairs: each pair contains a public key and a private key, which are two facets of the same underlying mathematical object (which depends on the algorithm type). Crucially, the private key cannot be computed from the public key, which is exactly why the public key can be made public.

The certificate contains the public key -- only the public key. When a SSL client connects to a SSL server, the server sends its certificate to the client, but certainly not the corresponding private key. Instead, the server uses its private key to perform an operation that only the server can do (because that operation requires the private key and the private key is private).

Similarly, when a SSL client connects to a SSL server and the server asks for a "client certificate", it really means that the client will send its own certificate (with the client public key) and will demonstrate its mastery of the corresponding private key by performing an operation that can only be done with the private key (but can be verified with the public key); this is a signature.

In your envisioned scenario, a client C connects to a first server S1, and S1 sends to C a copy of its certificate. Then C connects to a second server S2 that asks for a "client certificate". C may send the certificate that it received from S1, but that won't go far because C does not have access to the corresponding private key: that key never left server S1, the client does not have any access to it. Thus, C won't be able to complete the authentication with server S2.

The exact extra markings in the certificate (client auth, server auth...) are merely supplementary restrictions on certificate usage, but they are not the foundation of the cryptographic security here. What matters is that a certificate contains only a public key, not the corresponding private key.


Does syncing local data to the cloud count as MFA?

No, syncing to cloud isn't MFA. It's syncing. And you are mixing several different things on the same question.
On Bitwarden, you have an account. It's the same as having an email account, or a forum account. To access it, you need credentials and have an option to use TOTP. If you enable TOTP, you have MFA - or 2FA in this case. If you needed password plus TOTP plus magic link sent by email, it would be 3FA.
You log in at Bitwarden and have access to your passwords. And that is different with Enpass.
Enpass, on the other hand, does not have an account per se. You can login there, but that account does not have anything to do with your password database. You can only buy more features with that login. The database is kept locally, encrypted. You can sync online like Bitwarden, but it syncs only an encrypted blob that is useless without the master password.
I am an Enpass user for yers, and I prefer how it works over Bitwarden in this respect.


Your idea of changing the order is good, because the additional question could be used to avoid sending unnecessary password reset messages just by typing in the username or the email address. The security question is not there because it's secure: their nature tend to be easy to answer after researching the target. That's why the order matters for other reasons.

If you use email addresses as login names, they are bind together in a way that makes it easy to know where the information needed to reset the password goes. That's not generally dangerous to every user, but on a large pool of users there may be someone who's vulnerable. Also, if the email gets compromized first, it may be used for resetting passwords for such sites. In this case, two factors isn't much.

There's all kind of variations, but the factors should always be independent: something you must know and something you need to have access to. Using both email and SMS adds extra level of security, e.g.

Ask security question to launch the process.
Email one-time link to a password reset page.
This page, when accessed, sends a code to the phone.

Nowadays it's common that people have their email on their phone. Having unlimited access to someones phone gives ultimate power over two of these factors: email & SMS. That's why security questios aren't completely pointless even if they don't add a strong layer of security. The phase 1 possibly prevents an unlocked stolen phone from being used for a password reset.


What is wrong with a confirmation page displaying my password?

The problem here could be as simple as being someone behind you that could read you password directly from the screen but consider also, that if that page is served via "HTTP" and not "HTTPs" your password will be traveling in plain text through internet and anybody could just grab the packet and clearly read it.

But the problem can be even bigger if they just store your password in plain text in their databases since once they get hacked they will probably have a lot of passwords for a lot of people that probably use that very same password with the account provided.

It is clearly a security negligence.


Can there be a secret ballot software in a membership-based community?

Yes, it's quite simple.

Each member forms their vote and blinds it. They submit it using their SSH key to a system that performs one blind signature for each member. They then unblind their signed vote and return it to the site anonymously for tallying.

This ensures that each member gets one vote but provides no way to tell which member supplied which vote because the votes were only associated with a member while blinded.


Computer team's password change time different from other users?

What should be in your policy. Your policy should specify several things:

Minimum password length/strength.  For instance, requiring that the password be at least 8 characters or longer makes sense.
Password selection methods.  Advise people on good ways to select a password.  People aren't very good at choosing strong passwords, so your password policy should provide guidance about how to do this.  The best solution might be to provide them with a tool to automatically generate a random password for them.  Alternatively, you could suggest how people can choose a strong password on their own (e.g., pick a short phrase that will be memorable to them and that no one else is likely to use).
Password handling.  You should tell people to never share their password with anyone else.  You should promise them that sysadmins will never ask them for their password.  You should prohibit sysadmins and other staff from ever asking anyone for their password.  You should specify the penalty for violations.
Cleartext passwords.  I recommend that your policy prohibit transmission of passwords in cleartext over the network: in other words, it should require that internal services and applications be designed to avoid transmitting passwords in cleartext over the network, and it should prohibit services and applications (e.g., telnet, non-anonymous ftp) that transmit user passwords unencrypted over the network.  Your policy might specify a phase-in period and a process for getting approval for exceptions, if necessary.

What should not be in your policy.  You should not require users to change their passwords every 90 days.  This is a lousy idea.  It is horrible for usability.  And, it does not improve security: it's one of those things that superficially sounds good to non-experts, but does not actually add any significant benefits that I know of.  In particular, it does not really help defend against any realistic threat model I'm familiar with.  If you're lucky, it may cause people to choose a predictable sequence of passwords (e.g., xlkjsadf1, xlkjsadf2, xlkjsadf3, etc.).  If you're less lucky, it may make security worse, by forcing people to write down their password somewhere (a yellow sticky note attached to their monitor is the traditional method).

Possibilities to consider.  Depending upon your circumstances, you might also consider the following:

Non-password authentication.  Passwords are not the end-all, be-all of user authentication.  For high-risk activities (e.g., sysadmins with root/administrator access to critical machines), you might consider requiring other forms of authentication, such as RSA SecurID cards.  They are generally more secure than passwords.
Password escrow.  There are some cases where you might want to require employees to escrow a copy of a password with the company.  A typical case is where the employee signs up for some external service (e.g., Amazon EC2) and has to specify a username and password for the account with that service, and where the external service does not provide any way to link more than one username with the service, and where the external service is relied upon or used by multiple folks in the company.  In that case, if the employee who created the account leaves the company, you may lose access to the account on the external service.  One solution is to ask the employee to escrow the password they created for that account with the company: e.g., put it in an envelope, seal the envelope, sign over the flap, and place it in a locked safe controlled by their boss or some other employee.


My goal with this approach is to ensure that only valid clients are accessing the API, while also preventing replay attacks.

Use an ever-increasing nonce value.

  An attacker should be able to see the contents of the messages (not really sensitive), but should be unable to modify them.

Have an API key and secret.

Your requests contain the key in plaintext.

They also include a 'hash' value. This hash value is a hash (eg, sha256) of the concatenation of the API secret, your ever-increasing nonce value, and the data of the request itself. The server generates its own hash, and compares it to the one your client sent.

An attacker can read your API request, but since he doesn't have your API secret, he won't be able to craft a new 'hash' value and send his own arbitrary data. He also won't be able to replay old API calls because of your nonce value.


OpenID Connect: API access using same identity provider

NO

because the Session_State value(which is used to manage the session) is initially calculated on the Google's server. It is calculated by a salted cryptographic hash of Client ID, origin URL, and OP browser state. Since the Origin URL will be different between M and S, the same Session cannot be shared between M and S.

OpenID Connect Documentation here


Is HTTPS able to prevent ARP poison attack in LAN?

I would remind you a ARP poisoning attack works at layer 2 OSI, whilst HTTPS work at layer 5.

Or else, to better pose your problem, your doubt seems to be wether someone listening to the conversation or performing a MitM (man-in-the-middle) attack can compromise the security of an SSL conversation without the user noticing.

The ARP poisoning attack only alters the default route of outgoing packets, as the attack machines poisons the ARP tables of the victims to poses as the router.

SSL technologies complicate proxying it, but the feat is not impossible. In fact, some security products/corporate firewalls implement technology that basically are MitM attacks to be able to listen to HTTPS dialogues and detect malware.

For establishing a successful MitM attack / proxy to a session protected by X.509:

. the user has to be uneducated enough to accept a wrong certificate;
. or you have to fool the user browser the certificate is legitimate.

For that effect either you search for HASH collision in older protocols (i.e. that is way SHA-1 certificates are being phased out), or you install a root certificate of your own in the victim´s computer.

In a corporate setting, normally the AD propagates a root certificate for that effect. Some malware is known also for employing this techniques, and at least a hardware vendor and an AV company were grilled in the public opinion for doing this, the first to be able to insert adverts in your pages, the latter for scanning for viruses at OS level without using dedicated plug-ins for the browser.

Kazakhstan made it to a whole new level, and is doing MitM attacks at country level, via a mandatory root CA that has to be installed in any device using a national telecom connection:

http://thehackernews.com/2015/12/kazakhstan-internet-spying.html

http://www.theregister.co.uk/2015/12/03/kazakhstan_to_maninthemiddle_all_internet_traffic/

This particular technique generates a valid certificate on the fly for the HTTPS requests it intercepts which has as root the ROOT CA installed on the victim.

You have a slashdot thread talking about the technique here:
http://it.slashdot.org/story/14/03/05/1724237/ask-slashdot-does-your-employer-perform-https-mitm-attacks-on-employees

An article from Sophos explaining how the SuperFish attack works in Lenovo´s malware:

https://nakedsecurity.sophos.com/2015/02/20/the-lenovo-superfish-controversy-what-you-need-to-know/

You also can do it in a Unix system:

https://www.roe.ch/SSLsplit

  SSLsplit supports plain TCP, plain SSL, HTTP and HTTPS connections
  over both IPv4 and IPv6. For SSL and HTTPS connections, SSLsplit
  generates and signs forged X509v3 certificates on-the-fly, based on
  the original server certificate subject DN and subjectAltName
  extension.

So evidently whilst HTTPS is better than nothing, it is not perfect.
It is far more secure to use VPNs when using Internet in more hostile environments, and specially at wifi free hotspots.

As an interesting tidbit, law enforcement has mandatory interception stations in major ISPs, with software/interfaces that implement this MitM attacks and are able to inject corrupted executables/fake OS updates to take control of a victim computer, as documented by the administration/system/operators manuals that were leaked by Snowden or Assange (cant remember)

Link to article and leak of manuals in PDF format

https://theintercept.com/2014/10/30/hacking-team/

Also once and a while, you will see there will be a stink about registrars issuing known certificates like google.com by "mistake", "trainees tests" or because they are hacked. The controversy is that this further undermines the security and trust of SSL, and I would not be surprised wether some of that mistakes are for aiding their own security/intelligence/law enforcement forces to snoop on someone, for instance using google.


How exactly does the Stagefright Vulnerability work on Android?

The details will be released on the 5th of august. However, on the Cyanogenmod github repository there are several interesting details that appear to be related: it appears that certain fields in 3GPP video metadata are vulnerable to buffer overflow attacks. In short, a 3GPP video can be given a string of metadata that, at first, exceeds a certain length, and in the end includes machine code that lands in memory that is off-limits to the application.

Update: Cyanogenmod has released a patch for this vulnerability.


How does one determine what strength parameter to pass to BCryptEncoder (default is 10) in Spring Java?

Adding one to the parameter doubles cost for both defender and attacker. You want to maximize cost for the attacker, while keeping the cost for the defender acceptable.

Benchmark it for different choices on your target hardware. Choose the largest value which offers acceptable performance. For server applications that's typically somewhere between 10 and 100ms.


Is a web application being built on an open-source platform less secure because it is open-source?

The key here is that with closed source code, the onus is on protecting that code - attackers may try to steal the code, reverse engineer it, or just attack it. The internal processes should be designed to identify vulnerabilities and fix them, but the numbers are quite skewed:

Attackers: many   Defenders: few

With open source code, there is a slightly increased risk that the attackers may identify new vulnerabilities, but importantly you end up with many more potential defenders identifying code vulnerabilities and informing the code writers:

Attackers: many   Defenders: many

Have a look at this question comparing open and closed source as it may answer all your questions. If it does, we can close this one as a dupe.


Find path of file on website with randomized string in it

Under the following assumptions, the approach is safe:

the 15-byte prefix is truly random
the character set of the prefix consists of numbers and the characters a to z. (given the file name examples that O'Niel provided).

In practical terms, the file name cannot be guessed or bruteforced because the search space is too huge (as @schroeder correctly comments).
Let's do the math:
Calculating the search space: 36 ^ 15 = 2.2107391972073336e+23
If any kind of supercomputer setup was to bruteforce this in say, a 100 years (approx. 3.1536e+9 seconds), then it had to try more than 7e+13 possibilities (70 trillion (short scale)) per second.
Which, of course, does not seem feasible.


Any threats/SQL injections possible, when single-quote is being escaped?

There are a couple of (possible) issues:

Everything that doesn't come from GET/POST is still a danger (possible sources may be files, emails, databases, etc).
SQL queries where you need to remove the quote or don't need a quote in the first place (eg in LIMIT, for id values (eg SELECT from x WHERE id = $_GET['x'])) or further transform the input (eg in IN).
Encoding issues (see eg addslashes bypass via multibyte characters).
Improper escaping (eg not escaping \ as well).
Removal of quotes in other places in the code (adding quotes on input mangles your data; in some places, you might require clean data, which you might then pass on and further process; somewhere down the line this might end up in a query).

As you mention WordPress: That there are WordPress plugins which have SQL injection vulnerabilities should demonstrate that adding magic quotes is not good enough in all situations.

Escaping as defense against SQL injection is just a mess (security as well as usability wise). If you are building a new app, just use prepared statements (they are the standard for a reason). If you have a legacy app, carefully using escaping can be good enough though.


How to securely store and manage one-time backup codes for 2FA?

The problem with storing OTBC on-device is that if your device is compromised software-wise, eg virus infection, trojan, copy attack etc, then you are toast.

Note that once you unlock Password-DB, a malicious entity could access OTBC for the OTBC-DB and then access that too.

My suggestion for securely managing these, is to use 2 separate databases, once for OTBC and one for passwords/2FA. Of course, you do NOT access OTBC-database unless absolute neccessary.

The OTBC for both these password managers, you store in a encrypted text file. In the same text file you store the seed for the OTBC-DB, eg you do NOT have 2FA access to the OTBC-DB unless in a absolute emergency.

To access password-DB/2FA, you need the following:

1: Your Brain Password A.
2: 2FA code or OTBC code taken from encrypted text file.

To access OTBC-DB, you need the following:

1: Your Brain Password B.
2: The contents of the encrypted file (Always!).

The encrypted file is then hosted to your cloud service.

Now to how you should encrypt that text file:

I would suggest using some service, that would upon a secret password trigger, send your encryption key to a email, BUT, only after having waited atleast lets say 24 hours, upon you get a email to "cancel" it.

So when you lose all your 2FA devices, you type your secret "emergency password" into the service. Then you wait 24 hour, then you have your random password to your encrypted file, which are used along with Brain password B to gain access to your OTBC database.

However, if a hacker would try to access the emergency key, you would been given a opportunity to cancel that, and then the hacker could not access that.


Definition of "passive" and "active" authentication?

Active Authentication: authenticates user via the WS-Trust protocol. The Replying Party (RP) owns the login window and requests a security token from the Security Token Service (STS). Here, the user logs in using a flow. An example of active authentication involves mobile devices, verifying a user's identity continuously based on the sensors that are a part of that device. More on this in Active Authentication on Mobile Devices via Stylometry, Application Usage, Web Browsing, and GPS Location.

Passive Authentication: the RP has no login logic; the user is directed to the login page on the STS. After logging in, the STS directs the user back to the URL and you're authenticated on that site which trusts the STS. An example of passive authentication involves a user signing in through "a web form displayed by the identity provider and the user is requested to log in." See this document for more on active and passive authentication.


How can ssh defend against timing analysis attacks?

It is true, by analyzing the timing and size of packets, one can roughly determine whether those packets were keystrokes -vs- output.

This might give some (very rough) clues as to what you were doing when signed in to that server's SSH. For example, you might be able to guess if I was using vim -vs- analyzing logs -vs- running basic commands.

But what's the benefit to the attacker? I'm not seeing much here, but it is possible.

Related: ssh login failure detection at packet level

How to defend?

Do you really need to?
Use a VPN, which provides some protection by masking whether you are connecting to SSH at all, and which SSH you are connecting to.
The protocol could be modified to constantly stream data so that keystrokes no longer produce a spike in packet frequency.


Invalid certificate name on go,microsoft.com

The routing system in your region's Akamai server is malfunctioning.

After HSTS 307 redirect to the HTTPS site, the Akamai server seems to give your browser a wrong site that they serve.

It's their problem, as the certificate seems to be valid for the other site. If the certificate is gibberish, you might be under attack.

Interesting, though.


Is there any possibility to bypass these regex?

I am not very confident in the regex, because if I do a string like "abc" or "alert(1)" it says no match on both. XSS can be obfuscated as well, meaning a good regex to catch XSS is not an easy task to write, for more information have a look at
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

actually application is huge in nature so I can't apply encoding on each and every response instance. Is there any way to mitigate commonly?

You should architect application with security in mind before you develop it. I would suggest re-factoring your code so that all output, no matter of location is encoded with html entities.

Example for C#
https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.htmlencode?view=netframework-4.8


Based on your comments to the other answers, I understand your question better now, and your point is a good one. Consider the following:

You have a Gmail account with a password that is sufficiently complex, and you've had the same password for years. Perhaps you use an email client at home to check and store your email, and you use your phone client as well. You are traveling and lose your phone. You go to the mobile store and get a new one, and they transfer your number for you to the new phone. While trying to setup Gmail on your new phone, you can't seem to remember your Gmail password, so you reset it using SMS verification, and everything is fine, except that you know your email client at home is getting annoyed because it keeps failing to connect. It's not a big deal; you realize you'll have to enter in the new password when you get home. After stopping for a coffee, you have a moment of brilliance and you suddenly remember your old Gmail password. You try to change it back to the old one but now you can't! Dejected, you go back to your hotel, sit down on the couch, and find your old phone between the seat cushions. You think back to that moment when you were trying to remember your Gmail password... "Had I only been able to remember it, then I could have kept that awesome password. But I had a moment of forgetfulness and now that perfectly good password is wasted..." Of course, had you not found your old phone, you might have wanted to change the password anyway, along with all other passwords that were automatically stored on the phone.

So why doesn't Gmail let you reuse the password? Because they have no way of knowing you found your old phone.

In other words, they don't know why you changed it in the first place, so they simply assume you changed your password because you accidentally tweeted your old one to the entire world, just in case.


Single Page Application with REST API backend based on XML, queried by dynamic XPath

Your primary problem when handling client-provided is going to be XML External Entities (XXE) attacks. Systems with such vulnerabilities can often be exploited to read files or enumerate the internal network which the server is on. In PHP you can help fix this by calling libxml_disable_entity_loader(true); in order to disable external entities.

Another problem is, potentially, the Billion Laughs attack. This is a CPU and memory exhaustion DoS attack which uses nested element type declarations. This SO question should give you a good idea on how to pre-validate XML before loading it to avoid this kind of attack, but the short answer is that libxml allows you to set a custom DTD validator / loader callback.

You may also want to consider XPath Injection, though I'm not sure how critical this would be in your use-case. It's hard to tell what kind of impact it might have on your system's business logic without having a wider understanding of the application.


Message ID and Real IP of the email sender

The Message-ID header can be chosen arbitrarily by the client, so you cannot reliably expect to find the client IP address (if any) encoded in it.

This page lists known behaviour of many email sending softwares; some (e.g. mutt) will encode the full name of the sending machine in the Message-ID, but this is the name as the machine knows it, so it can be "localhost", which is not very informative. Moreover, even if the sending software encoded its known IP address in the header, it would often be a local-only address such as 192.168.1.100 because of the high prevalence of NAT. Finally, many emails nowadays are sent through big Webmail platforms like Gmail, so if you find an IP address in it, it will be the address of a Gmail server, not the address of the client.


Two factor authentication and plausible deniability for disk encryption

It is impossible to tell if a keyfile is required. There is no difference, from an attacker's perspective, between being unable to decrypt a drive because they are exactly one letter off in the password, and because they are missing an entire keyfile. All they know is that they are unable to decrypt it. In fact, if I were to give you a hard drive that has random data on it, you would be unable to tell if I had encrypted it with a password, with a password and a keyfile, or even if it is not encrypted at all and was just wiped.

When you use a keyfile, it is mixed with the password. This is then is used to derive the key that decrypts the header to retrieve the master key. A keyfile can thus be thought of as an extension of your password.


How do I hide the OS I am using from internet sites?

It is not currently possible to hide the type of OS from a website

A solution against general fingerprinting and obtaining more specific information about your system is to use Tor Browser with the security slider set to high (in order to disable JavaScript). It is designed with fingerprint resistance in mind, attempting to look identical to all other instances of the browser. It provides resistance in several ways:

Unlike a regular connection or a VPN, Tor exposes the network stack of the exit node, not of your own computer, so you do not have to mess with advanced TCP option mangling firewalls or modify low-level networking code in your operating system.
With JavaScript disabled, system-specific behavior like high resolution math libraries (certain trigonometry functions give unique results for each operating system) and data formatting functions (which format the data in an OS-specific way).
The user agent is standardized. There is no way to know what the underlying system is from just the user agent itself. Changing the user agent randomly makes you stand out as one of the few people doing it, so using a standard one is preferred.
The default window size is standardized, so CSS and JS functions which obtain the window size cannot guess your operating system based on things like the size of your task bar.

However, the task of preventing the general type of operating system from being known is currently impossible, even on Tor Browser. A list of whitelisted fonts is provided in order to prevent font rendering exploitation or font fingerprinting, but the whitelist is different for Linux, OSX, and Windows due to needing to use system fonts. There is currently no way around this. Until you find a way to provide system fonts without revealing what type of operating system you are using, you'll have no lock.

Also note that EFF's Panopticlick is only meant to bring awareness to the issue of fingerprinting. It is extremely limited in what signatures it looks for, and does not analyze a representative sample. You should instead look into https://amiunique.org/, which was designed from the current most extensive research into browser fingerprinting.

How does fingerprinting work in general?

While it is not possible to hide the general class of operating system you are running, you can make it so that you blend in with the so-called "anonymity set". A list of ways you can fingerprint a browser, with some notes, in case it is helpful:

TCP/IP stack fingerprinting - The TCP protocol provides some extra extensions changing its behavior such as window size (unrelated to browser window size), max segment size (MSS), time-to-live (TTL), and others. It is also padded by a nop option which does nothing but make sure the size of the options are consistent. Different classes of operating systems use different values. Linux for example sets the TTL to 64, whereas Windows uses 255. Additionally, the order of these options and where the nops are inserted differs from OS to OS.
Generic settings exposed by the browser - Certain things like the order of headers and the headers themselves can uniquely identify a browser. This includes thing like the system locale, DNT status, cookie status, etc. This is effectively all EFF's Panopticlick looks for, and a small subset at that.
WebGL fingerprinting - When certain types of hardware acceleration are enabled, the browser gets low-level access to your GPU. By telling the GPU to generate certain 3D shapes with special graphical properties (textures, light, transparency, etc) and applying various transforms to it and then hashing the resulting pixmap, quirks unique to your specific GPU can be identified. This allows a browser to be identified regardless of the operating system it is run as.
Audiocontext fingerprinting - Similar to WebGL fingerprinting, the browser can be told to generate triangle wave audio, then compress it, then increase gain and hash the resulting audio buffer. This hash will be unique to your system, regardless of what you have booted into. There is no need for the audio to actually be played for this to work.
Timezone fingerprinting - The system's timezone as set in environmental variables is available via JavaScript.
Math library fingerprinting* - When certain trigonometry functions are used, such as calculating the sin of the value 10, the system's math library is called, and this differs for each OS. It will likely be the same among classes of operating systems.
Canvas fingerprinting** - By generating a visual canvas element and hashing it, results unique to your browser can be obtained.
Window size fingerprinting** - The CSS @media elements can be used to selectively load resources based on the (often unique) size of the browser window. A website can create a large number of resources and see which ones your browser loads to tell the window size.
Font list fingerprinting - Your font list is often fairly unique, and differs between different OSes. As mentioned earlier, there is no practical way to avoid this. Keeping a list of whitelisted system fonts reduces the fingerprinting accuracy to the general class of OS you are running.
Date format fingerprinting* - If you call Date().toLocaleFormat() in the browser, the output string will depend on the operating system you are using. The output on Linux, OSX, and Windows 7 respectively is "Thu 26 Mar 2015 03:43:35 PM EDT", "Thu Mar 26 15:38:55 2015", and "Thursday, March 26, 2015 3:45:01 PM".
Virtual core fingerprinting* - The hardwareConcurrency JavaScript feature can be used to automatically spawn a number of threads for performance. By starting with one and increasing it gradually, while giving the browser a CPU-heavy workload, the number of virtual cores can be guessed based on the point at which more threads no longer improve performance.

* Tor Browser only mitigates these if JavaScript is disabled.

** Tor browser mitigates these with help from the user, so the user must follow its recommendations.


Of course you can start small and implement your own algorithms. But do not assume they provide any security beyond obfuscation.

The difficult thing when it comes to cryptography is finding reasons why something actually is secure. You won't be able to decide that within months and if you feel like you are at that point, you are most probably wrong.

It is much easier to find reasons why things are insecure than reasons why they are secure, so if you want to start somewhere, develop your own algorithms until you think they are secure and then try to find out why they are not and find ways to attack them.

Most mistakes are made when implementing algorithms. So if you want to get a well paid job you could learn how to implement that stuff correctly.

I would recommend starting to implement something like AES and than continue to different operation modes like CBC or CCM and find out why randomness is important. Continue with SHA-2 and HMAC and proceed to asymmetric cryptography. Always check what others did and why they did it and have a special look at side channel attacks and how they are performed. If you are at that point you will find your way to go on.

The reference to start with would be the "HAC", which is freely available online: http://cacr.uwaterloo.ca/hac/

[Edit]
A suggestion from JRsz which shall not be buried in the comments. A good book for beginners: http://crypto-textbook.com/


Encrypt data going through an encrypted connection

SSL uses a cryptographic system that uses two keys to encrypt data so you do not need to enforce encryption by AES and so on. SSL auhenticate Web servers, and encrypts communications between Web browsers and Web servers.. Websites (bank websites, for example) rely on SSL even to retrieve very sensitive data of their users because this protocole ensures by itself data integrity.

SSL uses assymetric encryption for authentication (between the server and client). After authentication is established, they start to communicate using symetric encryption because it is faster.

From the schema above, you can see data is transferred between the server and the client after authentication is made. Encryption of this data is made after (and thanks to) exchanging the cipher key (symetric encryption)


Proper Passing of Oauth2 Key to RobinHood API

Is this safe to use?

The said R application will have access to all the functionality (view account details, fetch historical trading data, and place orders). You need to ask yourself if you truly trust this application.


Any reason not to use same key for multiple SSL domains on one server?

I can see two primary reasons why you might not want to re-use the same key:

Compromise resilience: If the private key gets leaked, and if you've re-used it for multiple domains, then multiple domains will be affected.  If you use separate private keys and store each on a separate server, then compromise of one doesn't affect the others.  If you're planning to host all the domains on a single server, this probably doesn't matter -- but using separate keys may preserve your flexibility to change the hosting details.

Future-proofing: Suppose one day in the future the owner of one of the domains says "I'd like to start hosting the domain myself; can you please give me the cert and private key for that domain?"  If you've reused the same private key for multiple domains, you cannot oblige them.
Or similarly, maybe one day one of these domains will become highly popular, and you'll want to buy multiple servers to host it and start load-balancing across them.  If you've re-used the same private key, then all of those servers need to receive the common private key, and if any of the servers is compromised, all the domains are hosed.  On the other hand, if you use separate private keys, then you can give each of those new servers a copy of just the private key for the one domain that became very popular.

These considerations may or may not matter in your particular situation.  You can decide for yourself the convenience benefits of having a single private key, vs. the flexibility for the future of having multipel private keys.


Can encryption really be "overcome" (by government) and how?

That article strikes me as inspecific.

Modernly recognized quality encryption algorithms (e.g. AES which has been scrutinized for almost 20 years now) cannot really be 'backdoored'.

It could be 'cracked', but that would require a famous research breakthrough.

As is typical with mainstream articles, they don't really give us much to go on (unless I missed something) because it doesn't define the context.

In the case of Full Disk Encryption on smartphones and laptops, etc. The designers could decide to use a weaker Derivation function making it more susceptible to Brute Force. Or other built-in vulnerabilities. If that is indeed what the article is referencing, then we could discuss further.

However, the context could be completely different, such as HTTPS/TLS which refers to encryption of data in transit. For this, a compromised CA could be used to achieve MiTM. The website owners could work around this with Public Key Pinning, but I digress.

Without knowing the context, it is difficult to answer in detail. However I would summarize by saying that encryption algorithms cannot be backdoored, but a weak implementation could certainly be used.

As for public site visiting, like HTTPS, there is perhaps more room to fudge around by a) eavesdropping to begin with and b) compromising a CA without telling anybody. Still I think they would get caught if they used this technique frequently?

  there is no mathematically possible way to offer an encryption backdoor to law enforcement without weakening that encryption for everybody else

Even not knowing the context, I would probably concur with that statement.

Beyond that I'd say we need to look for a more specific article? Or perhaps Mr. Sessions just doesn't know tech well enough to clarify the How as you are asking.


How and where can I best announce an XSS vulnerability in a relatively well-known website?

You can Make a Responsible Disclosure with ZDI (Zero day Initiative), They are well known for their work and you have a good opportunity to earn some money depending on how strong exploits can be plotted upon the vulnerability you have found.

Many security experts submit CVE's to ZDI, Its legal and secured in case you are afraid of company to sue you.

They actually act as a mediator between you and the company and let company know about the vulnerability on your behalf.

  Link to ZDI


Nmap NSE Password Brute Force is Stopping on First Positive Instance

Solution found. --script-args can only be called once, contrary to the documentation at: https://nmap.org/nsedoc/scripts/telnet-brute.html.

The successful command is:
nmap -d -vv -p 23 --script telnet-brute --script-args "userdb=users.txt,passdb=pass.txt,telnet-brute.emptypass=true,telnet-brute.firstonly=false" TARGETIP

Thanks for your help @GreatSeaSpider, @atdre, @schroeder


Is it possible to crack Joomla hash password?

Just as Swashbuckler said - "decrypt" or "dehash" or "reverse" are almost always the wrong words for attacking password hashes.

But you can try to crack them - even with an unknown salt. This involves trying many possible strings, to see if they result in the same hash. It is harder if the salt is also unknown.

If it's older Joomla, it's MD5-ish (though I'm not sure of the details there, digging into the source code for older Joomla or John the Ripper or hashcat would probably tell you). Newer Joomla uses phpass, so there are quite a few possible salts, so this would probably be non-trivial (unless the password is trivial).

Edit: Looking at this answer and other sources, unless yours was a custom naive implementation, Joomla hashes prior to 2.5.18 had a large 32-hex salt (16^32 or ~34x10^38 possibilities). Even if the password is 'password', cracking this hash without the salt would be very unlikely.


How to hide the fact that a system is virtual machine from malware

You usually cannot hide anything from malware well coded. There are lots and lots of ways to detect a virtual machine, and some of them cannot be faked.

Simpler malwares may look on a few places, so maybe you could fool some, but sophisticated ones will look at lots of places, in a lot of points of the code. You could run it through a debugger and analyze the code while it runs, and maybe you could get all (or some) detection points.

I believe it's cheaper and faster to use a physical computer dedicated to it. Install OS, any applications, put dummy user files (pictures, music, movies, documents), navigate on a couple sites, and take a disk image. Run the malware, take another image, and work on this one.


Can I reliably identify Apple devices that have not patched against the gotofail vulnerability based on user agent string?

The user agent string will allow you to select possible candidate browsers; only select browsers on select operating systems can be vulnerable. But it can't detect whether or not the operating system has been patched, since that detail is not reported in the UA string.

A site has been set up to allow you to test your browser yourself:

https://gotofail.com/

This check attempts to load a resource using a key that doesn't match the certificate. If the resource loads without warning, then the browser is vulnerable. If it fails, then the browser correctly detected the mismatch.


How is knowing a specific collision of hashing algorithm useful?

The question that @PwdRsch linked to does cover your question, but I'll give a more targeted answer:

Imagine you and I are negotiating a contract. Let's say I come up with two documents that have the same hash value, say

  I agree to pay Mike Ounsworth $1,000 for these services.

And

  I agree to pay Mike Ounsworth $1,000,000 for these services.

Then I get you to sign the first one, but since the hashes are the same, you have also signed the second one.

I would create these two documents by playing with different wordings, punctuation, non-printing characters, etc, until I get a collision. For an unbroken hash function with a 256 bit output, I would have to try on average 2255 permutations before finding a collision. This would cost me way more in electricity than the crime is worth. Any shortcuts that allow my to do this in less time would be considered a vulnerability in the hash function, and it would be retired.

By a similar argument, storing hashed passwords is fine as long as the hash function is not broken.


Why is the term "nation state" used to refer to a government-sponsored effort in infosec, and is it accurate?

The answer to your question is listed in the Wikipedia article and dictionary definition. Yes, most people associate a Nation State with an ethnicity, but if it is used in a general sense it is just a large group of like minded individuals:

Wikipedia:

  In a more general sense, a nation state is simply a large, politically sovereign country or administrative territory.

and as you noted the Merriam-Webster, the definition is:

  a form of political organization under which a relatively homogeneous people inhabits a sovereign state

The Merriam-Webster, defines homogeneous as:

  of the same or a similar kind or nature.

A homogeneous population could refer to ethnicity as you pointed out, but not necessarily. It could also just be people of a similar nature who share the same political views. Which is in opposition to a Country, in which its people may have diverse political ideals.

We know that the "Nation States" involved in malicious activities, have multiple actors. These actors co-ordinate in order to achieve some form of agenda. As these individuals are all attempting to ultimately achieve the same thing, we know that they must all share a common goal and hence their homogeneous nature.

I think the term Advanced Persistent Threat (APT), might be less confusing, but it is ultimately the same as a "Nation State". Using terms such as Federated State, Multinational State, Government, or Country, would be incorrect, as some APTs may not necessarily be in one central location, or sponsored by a Federation, they might be sponsored by a private equity, we don't really know.


Can a .DER be converted to a .PFX / .P12 ?

Can I convert directly from a .der to a .pfx/.p12?

I don't think so because Openssl uses PEM encoding for certificates by default unless you set it explicitly using -inform or -outform arguments. There is no such option listed in the pkcs12 command.

  Do I need a .key (not provided via http://burp/cert:8080) in order to do the conversion?

You don't have to provide a key for PKCS12 command if you use -nodes option. With this option openssl do not use encryption for the file created.

  Will the .pfx/.p12 even be of any use to me (and Burp-Suite) without the .key rolled in?

In your case, Yes. Because that you will only store your certificates in that file you do not need it to be encrypted. Note that, PKCS12 file format is generally used to store private keys with their corresponding certificates in a single file format. In that case, you should use a key to keep your private keys in an encrypted file.


Why do we trust organizations that certificate ISO 27001?

Certification companies like SGS, TÜV Rheinland or BSI are accredited by accreditation entities to issue ISO 27001 certificates. For example, SGS and BSI are accredited by UKAS and TÜV Rheinland is accredited by DAR.

Accreditation entities perform audits of the certification companies they accredit in order to guarantee that they conform to their accreditation requirements that use to include standards like ISO 19011. If they do not conform, their accreditation may be removed.

Who accredits the accreditation companies? Like other have said, at the end there exist the convention to trust accreditation entities and the system they have developed.


What are the pros and cons of using fail2ban when using SSH key auth?

Since it varies on a case-to-case basis, there is no perfect answer to your question.

Yet, from an information security point of view, installing fail2ban (or any alike solution) would definitely add an additional layer of security... and that's something you can regard to always be a good decision.

My 2 cents: just go ahead and do it. In the end, you're better safe than sorry.


Do ISPs like Xfinity gather geographical information about their users?

The network provider knows which node the user connected to. So from that, they can determine the geographic area that would be accessible by that node. All traffic from the user, then, can be correlated to that node.


Are those email addresses valid?

Yes, they are. See for example here or with a bit more explanation here.

For a nice explanation on how emails may look, see the informational RFC3696. The more technical RFCs are linked there as well.

Attacks possible in the local part of an Email Address

  Without quotes, local-parts may consist of any combination of
  alphabetic characters, digits, or any of the special characters

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

  period (".") may also appear, but may not be used to start or end
  the    local part, nor may two or more consecutive periods appear.
  Stated    differently, any ASCII graphic (printing) character other
  than the    at-sign ("@"), backslash, double quote, comma, or square
  brackets may    appear without quoting. If any of that list of
  excluded characters    are to appear, they must be quoted.

So the rule is more or less: most characters can be part of the local part, except for @\",[], those must be in-between " (except of course " itself, which has to be escaped when in a quoted string).

There are also rules on where and when to quote and how to handle comments, but that's less relevant to your question.

The point here is that many attacks can be part of the local part of an email address, for example:

'/**/OR/**/1=1/**/--/**/@a.a
"<script>alert(1)</script>"@example.com
" onmouseover=alert(1) foo="@example.com
"../../../../../test%00"@example.com
...

Attacks possible in the domain part of an Email Address

The exact structure of the domain part can be seen in RFC2822 or RFC5322:

addr-spec       =       local-part "@" domain

local-part      =       dot-atom / quoted-string / obs-local-part

domain          =       dot-atom / domain-literal / obs-domain

domain-literal  =       [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS]

dcontent        =       dtext / quoted-pair

dtext           =       NO-WS-CTL /     ; Non white space controls

                        %d33-90 /       ; The rest of the US-ASCII
                        %d94-126        ;  characters not including "[",
                                        ;  "]", or "\"

Where:

   dtext           =   %d33-90 /          ; Printable US-ASCII
                       %d94-126 /         ;  characters not including
                       obs-dtext          ;  "[", "]", or "\"

You can see that again, most characters are allowed (even non-ascii characters). Possible attacks would be:

a@a.a&a=////etc/passwd
foo@bar(<script>alert(1)</script>).com
foo@'/**/OR/**/1=1/**/--/**/

Conclusion

You can't validate email addresses safely.

Instead, you need to make sure to have proper defenses in place (HTML encoding for XSS, prepared statements for SQL injection, etc).

As defense in depth, you could forbid quoted strings and comments to gain some amount of protection, as these two things allow the most unusual characters and string. But some attacks are still possible, and you will exclude a small amount of users.

If you do need additional input filtering that exceeds the limits of the email format, because you do not trust the rest of your application, you should carefully consider what you do allow and what you do not allow. For example + is used by gmail to allow filtering incoming emails, so not allowing it may lead users to not sign up. Other characters may be used by other providers for similar functionalities. A first approach might be to only allow alphanum + ! # % * + - = ? ^ _ . | ~. This would disallow < > ' " ` / $ { } &, which are characters used in common attacks. Depending on your application, you may want to disallow further characters.

And as you mentioned RFC822: It is a bit outdated (it's from 1982), but even it allows for quoted strings and comments, so just saying that you only accept RFC822 compliant addresses would not only not be practical, but also not work.

Also, are you checking your emails client-side? The JS code gives that impression. An attacker could just bypass client-side checks.


Encryption scheme where multiple users can encrypt

That sounds like a use-case for GPG - have you tried GPG and found it lacking (as many others have), and want a different solution?

If not, then GPG sounds like the appropriate tool for the job - although it does mean you will have one key per user, and no control over that key (although you can choose to mark it as untrusted).

If you do need control over the key, then x509 does sound like the better way to go, but as you say, you need to then manage decryption.

I would also caution against your private key encrypt, public key decrypt approach, as it means all users with access to the public key (i.e. anyone having had a copy of the cert) can decrypt. To avoid that, you would need to use the recipient's public key for encryption (and the sender's private key for signing).

In passing: you seem to be talking about signing, for which you don't need to worry about encryption. Either way, publishing/validating public keys (e.g. in LDAP, or using x509) seems like a possible solution.


What do web trackers know about/think of me?

Information is overwhelming

As someone who writes these sort of applications for a living I can tell you that you are protected by anonymity in numbers. Most companies see the sea of people, not the individuals.

If you're talking about a web stalker or researcher, the main question shouldn't be "What do web trackers know about me." Assume they know everything. Almost all information is public record these days (in the States):

Where you bought your house? (public record)
Where you went to school? (facebook, reunion sites, etc)
How old you are? (facebook, linked in, stack exchange, reunion sites)
Who are you related to? (facebook, ancestry.com)
What's your e-mail address? (online and offline surveys, anywhere it's posted on the web)
Your home address? (facebook, foursquare, public record, magazine subscriptions, e-mail subscriptions, reverse phone look-up)
Were you arrested? (public record)
Were you convicted? (public record)
Where do you work? (linkedin, facebook, company website)

Search for your name, your phone number, your home address on Google. Want to see a satellite image of your house? What your house looks like from the road?

What can you do to prevent someone from finding you?

live off the grid (cash only)
provide disinformation
use IP phones like magicjack
use a PO box
use anonymous e-mail accounts
don't complete surveys
complete surveys incorrectly
don't verify information cold callers (eg. Caller ID says "Unknown"... "Hello, Mr. Jones?")

If you're concerned about companies sharing your information, they already do. The profile for each companies depends on what they're interested in. Most companies try to stick with their corporate mandate or charter.

For instance a company that you may use at work for business travel isn't necessarily concerned with your buying habits on Amazon.com, however they may be part of the same network of advertisers that show that you also go to Amazon. The advertisers use this to try and sell their services to other companies. They won't specifically single you out. They may show you ads for places that you frequent when you're on a partner site. So if you visit Delta Airline's website and check for ticket prices, you may see an ad on Amazon, Google, Yahoo, Youtube, etc... You might get offers for luggage on Amazon (or suntan lotion if you searched for tickets in a tropical environment). Luckily they don't do this at the moment because user experience tracking tells them people freak out about this stuff.

Anytime you see third party cookies, these are transmitting information to a server that keeps track of your "profile" off of the site you're visiting.

It's not only online.
Another place that people don't think of that tracks all of their purchases is their credit card company. Companies like Visa, Mastercard, Paypal, and American Express all have records (many times multiple records) for the same account holder and their purchase patterns, histories and frequencies.

One of the scariest profiles out there can be found by creating a Google Plus account. Google (Microsoft and Apple) see everything that is transmitted over their devices and software, whether it's an android (or apple) phone, a browser, a web search, or a DNS lookup (8.8.8.8,8.8.4.4). It's all logged in some form or fashion.

Most browsers keep your cache, history, and saved passwords as features. Also they store cookies. If someone wanted to exploit a browser it would be easy to have it forward all of this information to one centralized location. Your computer and your personal electronics have the most information about you on them. Guard them for they are your identity in the modern age.

When I write an application for a client we usually try to pair their existing history (prior to a personal identifier) with the profile after they've provided some bit of information. If I submit a cookie to the end user, they likely don't know it. Then every time they connect from the same device using the same browser I can keep track of their actions. At the point they log in with another device or browser I can document the device, or a new browser, and pair that information with the existing info. If they send a link to a colleague I can track the colleague too. If they provide an address or a company name I can search online directories and build a deeper profile for a client. If they subscribe to a mailing list and I send them weekly emails I can tell whether they travel or not. (By the ip address of the device they check their email on, you can already do this by data-mining e-mail thread headers in your inbox as well).

I'm one of the good guys. Ethically it would be bad to try and exploit any of the information available. If I did this once I would risk all of my clients who depend on me for my professional services.

So you have two options... live off the grid for fear of the worst case scenario... or enjoy life because you have nothing to worry about. Bad things happen to people all the time. They usually don't involve your web profile.


what stops us from starting a shell from within the debugger?

If you run a setuid program under debugger, and you're not root, it will run as if was not setuid. Meaning it will execute under your id, not root. So while you can spawn a shell, it will use your credentials.

You can easily test it yourself by launching su under gdb and verify in another console that it is executed under your user account.

And if you launch the setuid program and then try to gdb attach to it, this will return 'permission denied' error.


Confusing question, but I'll take a stab...

'Secret Keys' are used in symmetric encryption, meaning the sender and receiver have the same key that is used to turn text into a cypher AND to turn the cypher back into text on the other end.  AES is a 'symmetric' algorithm.
'Public Keys' are coupled with a private key to do asymmetric encryption, meaning the receivers public key is used by the sender to turn text into a cypher, but decryption on the receiving end requires the receivers private key.  RSA is a asymmetric algorithm.

Often asymmetric algorithms are used to initialize a connection and to exchange secret keys to do symmetric encryption from that point forward due to performance.  Such is the case with https.

'Signing' refers to Public Key Infrastructure (PKI) where certificate authorities provide some level of assurance that a website is who they say they are.  Only related to public/private/secret keys in that they 'sign' the web providers SSL/TLS certificates.


Safari downloaded my php source once. Should I worry?

Check your server php configuration as explained here.

Make sure you have AddType application/x-httpd-php .php in the httpd.conf file.
Use <?php instead of <?.


Why is JavaScript executed manually from the browser console not allowed to access everything?

The answer to this is more regarding usability than it is security.

It's easier for the developers to build a box that does JavaScript, with rules and restrictions in place for what it is and is not allowed to do. You feed that box JavaScript code, and out comes the result of that code (plus side effects).

By implementing a feature like you suggested, you would introduce more complexity into that machine (and more possible surfaces for bugs), as now the machine would not only have to execute JavaScript, but also remember where that JavaScript came from, and what it is allowed to do.

Furthermore, it makes life for developers harder. Imagine typing a simple JavaScript command into your console, and it works, and when you then execute it from a script file, it suddenly does not work anymore. That can be incredibly frustrating for a developer to experience.

And finally, what is the upside? There is not really one. Manual JavaScript execution in a browser is an extremely niche feature 99.99% of browser users don't use. Even developers usually don't do that.

To summarize, this "feature" does not exist because:

It would introduce even more complexity (and thus more bugs)
It would confuse many developers
It would barely have any positives worth the cost


DSA is not a variant of RSA. If anything, DSA is a variant of the Schnorr signature scheme, modified in order to make signatures shorter, and, more importantly, to make DSA out of reach of the Schnorr patent (which has long expired). DSA itself was promoted by NIST as a US Federal standard because RSA was also covered by a patent at that time (this one has expired too).

Mathematics of DSA and RSA are quite distinct. See the mathematical description on the Wikipedia pages for DSA and RSA.


OpenID Connect/OAuth 2.0 and "fake" official apps

Stealing the client secret is becoming increasingly more difficult since these can now be stored using hardware APIs for encryption/safe storage on modern devices.  Mobile applications should use those to the fullest possible extent.

Some time ago, the advised flow to use for mobile apps was the implicit flow - no client secret and no way to get a refresh token, which limited the possible window of attack.

These days I'd advise the Hybrid flow (code id_token), which does allow refresh tokens and thus also requires a secret.  That secret must be stored as safe as possible, and additionally you should implement PKCE protection.  PKCE protects against code interception attacks, not unlike what you describe: a malicious app could steal the auth code by registering the redirect URI/scheme.  PKCE protects against that by requiring you to send over a code challenge (generated from a cryporandom code verifier) when sending the auth request.  On each request to the token endpoint, the verifier is sent.  That allows the IDP to check this against the challenge, which ensures tokens are only delivered to the correct redirection URI.

Hope this helps :)