Implementing an autologin link in an email

The token should have at least 72 bits of entropy (9 bytes, or 12 Base64 characters)
This should be generated with a Secure PSRNG (random number generator). So don't use the simple rand() operator of your programming language as it might be predictable, but look for the Secure random generator that PHP provides internally , or read bytes from /dev/urandom

store the generated links in a database table

It is best not to store the plain token in the database, in case the database is partially stolen . Instead, store an SHA-256 hash of the token, so that the only copy of the original token is found in the email you sent to the customer.
Note that Hashing is also common for passwords, but since passwords have less entropy you would normally use BCrypt. Since the tokens have 72 bits of entropy, the fast SHA hash will do fine.

both token and customer id in the URL
in case the token does not match the one stored for the customer id, reset the token (to avoid brute forcing)

I would say this is not needed. With 72 bits of entropy, it will be near-impossible to brute-force the token.
Also this scheme suggests that any unauthorized person could reset tokens this way, which is a form of DOS attack. (not hacking in, but preventing others from being able to use the system)

make the links one use only

This is a good choice, because the link will be stored in browser history unfortunately.

set an expiration time on the links

Certainly a good idea.
Do note however, that the weakest link is the ability for someone to hack your customer's Email (which is usually synced across multiple devices), so this is not sufficient security for many situations, but may be acceptable in your case. That is your decision.

I'm looking for any recommendation on this approach, and how can I improve it ? What did I miss ? What are the risks left with such approach and how to overcome them ?

I've outlined what you missed above and the primary risk of using this approach overall. However I would add that you should limit the amount of emails a person will receive. You don't want a robot filling out your Forgot Password form too many times thereby spamming your customer.
There are many other security considerations related to session management as well as authentication itself but that is beyond the scope of this answer.


Any reason not to encrypt a 32 byte value by XORing it with a PBKDF2 hash?

By using PBKDF2 that way, what you are really doing is turning PBKDF2 into a stream cipher. The three main problems with this idea are:

Use of PBKDF2 as a stream cipher has not been thoroughly investigated. It may be fine. Or not. Security properties of PBKDF2 have been analyzed for mostly short outputs only, and then, only as a KDF.
If you reuse the same password and salt, then you get the same output. In a stream cipher XOR-with-the-data mode, this is very bad if you encrypt two elements. In that sense, you have now merged the PBKDF2 salt with what was the IV for AES, thus conflating the requirements. You'd better make sure that your overall protocol deals properly with that. (In that sense, this is similar to using PBKDF2 to generate a key for RC4 encryption, because RC4 has no IV.)
PBKDF2 is made slow with iterations. It so happens that its processing speed is also proportional to the requested output length. If you use PBKDF2/SHA-1 and ask, for, say, 24 bytes, and use 10000 iterations, then you will actually pay for 20000 iterations. This can quick become intolerable for longer messages to encrypt. Take note that the attacker who runs a dictionary attack does not need to compute the whole stream; thus, you incur the risk of needlessly slowing the defender while letting the attacker run at full speed.


Use cases for GnuPG's --(import|export)-options (import|export)-(clean|minimal)

Debian maintainers sometimes use keys exported with export-minimal in their source packages to verify new upstream releases. That way the keys take up less space.


What Twitter #hashtags apply to IT Security

#infosec and #security are the two main hashtags I'm aware of.

Depending on what you're interested in there are other less popular hashtags. For example:

#websecurity
#privacy
#cybercrime
#cyberwar
#hacker and #hackers
#cybersecurity
#malware
#spam

There's also the option to use multiple hashtags in your search. If, for example, you are interested in Android security, you can search for "#android AND #security".


Can websites detect if visitors are logged in to mainstream ID providers and collect their IDs?

It depends.

  Can websites see if you are logged into?

Yes, if you have third-party cookies enabled.

  Are they able to log you in behind your back?

This shouldn't be possible.

  Can they grab data from a website site?

I'm not to sure on this one but this should depend on the security of the website. Maybe you could do some mischief but properly set up x-frame-options
in combination with a secure CORS implementation should prevent most of it.

Please note I only mention CORS because it plays a role in the practical implementation of such systems and has no direct security benefits.


how long does it take to crack wpa or wpa2

It mostly depends on the password length.

In a tradeoff you can download WPA Tables to crack the PSK faster, if it is in the dictionary used to create the tables.


There is no reason the test virus should run. Nobody expects that an antivrus is doing behavioral analysis on this file because it actually does nothing bad. All what is expected is that even the stupidest antivirus without any current pattern is able to detect this file so that one can check if the antivirus is running at all or that a firewall is able to extract potentially malicious payloads from the traffic.


My home modem-router is occupying most subnets

Those are ports used in "media" servers- RTSP and realserver are streaming protocols, 1863 is a Microsoft notification protocol. Napster was for file sharing, etc.

Having the router listening on these ports on all internal networks isn't necessarily problematic, though the presence of ancient protocols like realserver and napster is certainly suggestive of age and therefore by implication of security issues.

The two things to look further into are:

what ports if any are open on the external interface?
can services listening on internal and external ports be disabled in configuration?

Going through configuration and disabling everything possible to disable should result in there being no listening ports on the external interface and no listening ports except for http (or https) on the internal interface.

There may still be security issues with the internal http port, of greater or lesser difficulty to find. It should be much faster to determine if the minimal level of assurance that unnecessary ports are closed can be achieved. If that level of assurance cannot be achieved then it goes without saying that there will be vulnerabilities on those unnecessarily open ports.


What are criteria and rules to determine bug bounty amounts?

Criteria to determine bounty amounts
A bug bounty program's rules should communicate the used criteria and process for determining bounty amounts as clearly as possible. However, bug bounty platforms usually don't constrain your program's reward structure or enforce fixed severity levels which you must adhere to. There are just too many cases that require some flexibility. That said, many program rules lay out tables of different tiers with baseline (and possibly maximum) payouts. The following are some common criteria to rank vulnerability submissions and determine adequate amounts.

Severity of the vulnerability. A more severe vulnerability should (obviously) pay more. A remote code execution bug is most likely more dangerous than XSS and so on. You can apply the Common Vulnerability Scoring System (CVSS) to quantify the severity of a given security bug. However, this may get tedious. Many program rules just set a rough list of tiers. E.g., Google's VRP distinguishes between remote code execution, file system/database access, security control bypasses, client-side code exec (e.g. XSS), and others. Similarly, the program of Uber makes use of several "security impact buckets".

Relevance of the affected application/component. This partially ties into the previous point. The same type of vulnerability may have a different impact on different sites or components. XSS on a static subdomain served over HTTP may not be as harmful as XSS on the main domain where users manage their accounts. As for a real-life example, Twitter's program distinguishes vulnerabilities affecting the Twitter core (e.g. on *.twitter.com) from all others. Google's VRP classifies applications as account management-related, high severity, normal, and non-integrated/lower priority applications, each with their own payout structure.

Maturity of the bug bounty program. A new program/scope should start with moderate bounties and increase payouts once the "low-hanging fruits" have been discovered and finding high-severity bugs becomes increasingly difficult. You should keep adjusting baseline amounts based on the reports you're receiving to pay fair bounties that balance the bug hunters' skill and time efforts, with your budget.

Quality of the report. Some programs pay higher rewards for well-written reports. This is especially common/relevant for client software where some bugs can be significantly easier to investigate and patch with more technical information and post-report assistance by the researcher. E.g., Mozilla's Client Bug Bounty Program states "Improving test cases post-submission, figuring out if an engineer's speculation is founded or not, or other assistance that helps resolve the issue will increase your bounty payout." However, for your standard reflected XSS in a web app, a simple proof of concept is often sufficient and a submission quality rating has no merit.

Broader context of the bug. Sometimes, a vulnerability submission has an impact beyond the initial report. It may reveal a larger issue or be more critical than the researcher anticipated. Or, on the contrary, multiple reported vulnerabilities may all have the same root cause and it makes sense to treat them as a single bug. These considerations may, too, warrant a payout adjustment.

(Some of these points are presented similarly in the SANS whitepaper Bug Bounty Programs: Enterprise Implementation, chapter 2.7. Also have a look at #2 of this instructive post on the HackerOne blog.)
Assigning bounties on a bug bounty platform

...how do the different platforms support them?

Platforms generally let vendors choose the bounty amount freely. E.g. on HackerOne you can choose between pre-calculated amount levels or reward a custom amount.

(Image: HackerOne Docs)
HackerOne also provides an optional CVSS calculator which can be used to have a vulnerability's severity determined automatically.
The right bounty range to start with
... depends on the budget your company is willing to assign to the program. As mentioned above, you can start with low bounties and work your way up based on the reports received and bounties paid so far. It may help to look at the payout ranges of other companies that are comparable to your own business. The concrete financial considerations would be beyond this answer.


I dug into this, cause I also got the Discord message. Felt too good to be true, right? Well, yes, it is too good to be true.

I set up a new Browser, with no history in it, made a temporary email and signed up. I entered their "You have won" code, and sure thing, they did deposit 0.48 BTC on the account I just made on their site. Cool.

(They probably just edited a value in a database somewhere though, so I doubt there is any real BTC under that value)

Alright, so lets withdraw that to a newly made wallet, right? Nope!

So this is how the scam works: Make you sign up -> give you "free BTC" -> request a really small deposit (to prove you are not a bot) -> take that small deposit and laugh all the way to the bank. (Just like @Demento predicted)

Until I have significant proof from multiple credible sources, I would not trust this.


Was granting myself this permission a security risk?

File permissions are really designed for a multi-user system. If that's the case -- multiple people use this machine, or it's part of a corporate environment -- then giving yourself write permissions inside C:\Windows\System32\ means that you (or malware you download that's running as you) can muck things up for other users.

If this is a single-user system then the distinction between you and Admin is a bit less meaningful. As usual, there's a perfect XKCD for this:

XKCD comic "Authorization"

It's also worth noting that by giving yourself (and therefore any malware running as you) write permission to C:\Windows\System32\, you increase the chance that malware can escalate itself to being Admin, at which point it's easier for it to hide from any anti-virus software you might be running because now the malware is equally powerful as the AV.


Can ISP deanonymize Telegram public channel creators?

Probably not
The attack is sound in theory: you check everyone which sent telegram messages at that time and correlate based on timestamp and/or size.
The hurdles you have are:

Many people would be sending Telegram messages around that time (it is a popular service, the correlation would be much better if there would be few users connected and apart)
Messages are tiny. Uploading a video would produce a bigger signal, but sending a few words would probably be noise amongst the padding blocks. Pretty much everyone will be sending the same amount of traffic
Moreover, it could probably be confused with traffic received from telegram (sending a small message vs asking the server if there are pending messages to download¹ or a "message received/seen" reply)
Telegram attempts to hide its entrypoints as part of its efforts to avoid being blocked. You might not be sure if certain requests are going to Telegram or not.
You have a partial view of the network. Maybe you are a big ISP, and have 5 users that were sending telegram messages ±3 seconds the reported time. But you won't know if it was sent by someone else. Maybe someone using a VPN or living on the other side of the world.

It would work best if you already had one (or maybe a handful) suspects, and then restricted that based on that network data. If you have external evidence that this channel is owned by Alice or Bob, and you are able to snoop on the connections of both of them, I think you could determine which of them is the channel owner quite easily with a few datapoints.
On the other hand, as a generic fishing system, it would be much more complicated. You would need to take into account the legislation you are working with, though. On many countries, it would be illegal to deanonymize the user (lacking a warrant or their consent). While others wouldn't mind jailing and beating the 50 people that were connected to Telegram around that time to discover which of them were at fault (in addition of grabbing and analyzing their phones).
¹ Note: Some Telegram clients can use the system native messaging (like Google Cloud Messaging) to be woken when there are messages to retrieve, but other builds use polling.


Admins running Powershell from their desktop instead of server

If it's a dedicated admin workstation and admin account then that is the ideal scenario. So admin uses his regular account and regular pc for email & web browsing. And the admin uses his admin account and admin pc for powershell scripting against other systems.

Also don't forget to enable powershell logging so that you have a history of the commands executed in case an account is compromised.

Also make sure you apply least privilege to admin accounts. In many cases an admin can accomplish his powershell commands and queries without requiring local admin privileges.


How does a Web Security Gateway analyse SSL Encrypted Traffic?

Products which purport to be able to filter SSL-encrypted traffic usually do so by doing a man-in-the-middle attack, just like an active attacker would do. The "security product" sits on the Web proxy, through which the connection is performed. It intercepts the flow, and generates on-the-fly a custom certificate with the name of the target site; the client effectively establishes a SSL tunnel with the proxy, not with the intended target site. Simultaneously, the proxy connects to the target site, and forwards data in both direction.

This can work only because the automatically generated certificate is signed relatively to a special certification authority controlled by the proxy, and installed as a "root CA" in the relevant store in the client machines. This requires that whoever installs the proxy has administrative control of the client systems.

Apart from such "security products", such an institutional MitM setup is found in products which claim to "speed up the Internet" (i.e. they grab the data, compress it, and send it to a specific gateway which uncompresses it).

Note that such a system cannot work with bi-authenticated SSL connections (the kind where the client also has a certificate): the client-generated signature cannot be converted by the proxy into a signature which will convince the server (because, among the data signed by the client, is the server certificate as the client saw it, i.e. the one automatically generated by the proxy).

Another way to analyze SSL-encrypted traffic, not on the client side but on the server, is to have a product which has a copy of the server private key, and ensure that the server does not use the "DHE" cipher suites. Under these conditions, it suffices to grab a copy of the packets to decipher the tunnel. Of course, this is for connections to one specific server, and it requires some cooperation of the said server (the server private key is, after all, private to the server).


TCP- or UDP-based Port Scans, IP Fragmented Packet

IP Fragmented Packets are a form of evasion against network devices. It consists of submitting the payload through smaller pieces to make it more difficult for firewalls and IPS to identify the scan or even an attack.

Networking scanning is pretty normal and you have to get prepared to it. Important is to have a firewall well configured in place, limit the open ports and have the services listening to them (ports) well hardened.


Is it possible for a hacker to download a php file without executing it first?

In order to read PHP code you need a directory traversal vulnerability. file_get_contents() or other file system functions that are exploitable.

SQL Injection under mysql can be used to read source code.  For example:

select load_file("/var/www/index.php")

To combat this make sure file_privs are disabled for the MySQL user account used by PHP.  If display_errors = on in your php configuration then an attacker can obtain the path to your web root,  and use sql injection or directory traversal to read source code.

Using FTP means that source code is transmitted in plain text.   Use SFTP,  and make sure you have a strong password -- or better yet, set up an RSA key.

Be careful of backup files,  sometimes editors will create index.php~ or index.php.orig files which can discovered using forced browsing.


Questions towards my application that uses bouncy castle crypto

it uses AES-CBC

You should probably use EAX mode instead of CBC. It will prevent the encrypted data from being tampered with (with almost no effort), and it will protect you from certain edge cases that effect CBC mode. See this answer for a discussion of different modes.

The only changes you'll need to make to do this are to use EAX instead of CBC, and you need to use a key that's twice as large (a 256-bit key if using AES-128, or a 512-bit key if you're using AES-256). You can make PBKDF2 generate a key of any size, but make sure the output is the native output size of the hash function, so if you want a 512-bit key, use PBKDF2-HMAC-SHA512.

  I dont want to use a static IV (due to security reasons) how do i go about it? do i have to append the IV to the file and then when decrypting extract it?

You can store the IV however you want. It seems common to prepend it to the data (prepending is slightly easier, because you can read the file from the beginning without jumping around). The OpenPGP format is nice because you can use other applications to read and write the files (and the format has had a lot of attention, so it probably handles cases you haven't thought of yet). I've written programs that output a JSON file, with the base64 encoded encrypted data, and the IV as attributes. You could use XML. You could distribute the data and the metadata as separate files. It's really up to you.

  When the encryption is finished the unencrypted file is deleted. Should i have any concerns that an attacker could recover the unencrypted file (this is an android app so the underlying storage technology is flash, and i am using the standard API to delete the file) should i implement a secure delete function or how to deal with this?

When you delete a file, the filesystem usually just marks it as deleted so other files can be written over the top. To fix that, you would need to write over the file, but I'm not sure if there's any way to guarantee that on a journaling filesystem, especially if it's using flash (because flash controllers usually move blocks around for wear levelling). You could probably do this by deleting the file, then writing a giant file that takes up all of the free space on the device, then deleting that file.

The best way to guarantee that private data isn't left unencrypted on the disk is to never write it to the disk unencrypted, but it sounds like that may not be an option for your program.

  The files are encrypted using a 256-Bit key derived by PBKDF2. PBKDF2 needs a salt for which i use a hash of the users password is this a bad idea?

A unique salt will protect your system from a large number of vulnerabilities, so you should definitely use it.

  does the salt has to be random?

It doesn't necessarily have to be random, but it does need to be unique. Randomness is usually the easiest way to get unique values.

  if so how do i deal with it do i have to append the salt to the file to perform decryption?

Store the salt the same way you store the IV.

Your probably also want to store the number of PBKDF2 iterations, so you can increase the default in the future, and still be able to decrypt older files. Make sure your iteration count is high enough. For comparison, iOS uses PBKDF2 with 10,000 iterations when storing passwords. Unless your program is running on a toaster, you have no excuse to set the value lower than that.


Is random URL token secure enough for file attachments and other user content?

While it definitely does provide a degree of security, it still leaves you a number of security holes that may or may not matter dependent on the type of application you are developing. For a non-exhaustive list:

Content may meant to be limited to a select group of users, what if one of them leaks the URL?
URLs with GET parameters are stored in a large number of places - web history for example
Occasionally you see major issues when google crawls things they are not meant to, for example the instawallet fiasco.
Security vulnerabilities elsewhere in your site may expose the links, and with no additional security they will be exposed.

If I were you, I would want to implement additional security by tying files to specific people/groups who may be able to access it, and confirm their session prior to serving the content.


Based on the fact that it contains "binary" characters (those > 0x7F), it's likely it was encrypted before being stored in the cookie.  If the site wanted to encode it in a way that was publicly readable they could have used any number of ASCII-only encoding schemes.  It seems they deliberately obscured the email address to make it publicly unreadable from the cookie, while allowing them to decrypt it using a key only they know.

If you want to be exhaustive in your search for a possible encoding format, you need to interpret the characters using different character sets.  In this case though it's unlikely any character set would make sense: the email address stored is almost certainly ASCII-only, so only a non-ASCII compatible character set would generate that type of output.  UTF-16 and UTF-32 are possibilities though, if the email address was short.


ASV scan - What to expect from external scan services?

These are vulnerability scans which are more detailed and have more basic security information than a simple port scan. These are also not as detailed and don't dig nearly as deep as a full penetration test.

The ASV testing company may perform the test in a number of ways and having a portal to request a scan is not a requirement at all.

It could be considered a conflict of interest to have your ASV remediate your issues so this is not normally handled by the same company. The PCI DSS 3.1 mentions organizational independence in section 11.3.1.b of the PCI DSS
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf

You can learn more about ASV's from the PCI ASV Program Guide.
https://www.pcisecuritystandards.org/pdfs/asv_program_guide_v1.0.pdf


Using randomly generated numbers to authenticate with a Relay server

As you described it, this relay scheme is secure, if the data relayed via the server is properly authenticated and encrypted.

The only attack vector I found would be, that an attacker could determine (based on the pairing codes) which 2 clients want to talk which each other, but traffic analysis would have shown this either way.

As the API distributes keys to the clients you might want to implement/use ECDHE_PSK_* TLS cipher suites between the two clients, so that event the API can't read the traffic. WikipediaYou can use TLS (and I'd recommend it) for end-to-end communication between the clients, so you still won't have to implement TLS for the relay server.


Are the keys generated by ssh-keygen only used in authentication?

Yes the keys you generate are only used to authenticate who you are. The actual encryption is handled after you authenticate.

So the initial communication to authenticate is Asymmetric, using your generated keys to confirm who you are, then a set of Symmetric keys are generated to encrypt the actual session.

Rather than me make a mess of explaining the actual details here is an easy to understand breakdown: https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process.

Assuming you do change ssh-keygen as long as it is a supported cryptography method the server can understand it will not effect the integrity of the data in transit.


Is it safer and more secure to buy your own online storage from a hosting service or use major cloud services?

There is no difference. What you describe as "cloud storage" and "shared storage" is exactly the same thing: A few GB of network-accessible storage on someone's servers.

If you want to know how much a service respects your privacy, you don't need to look at how they call their product in their marketing material. You need to read the privacy policy and terms of service. It should state exactly what data they keep, how long they keep it, and under what circumstances they are allowed to access customer data or give it to other people.

You might also want to search some older IT news for any reports about security incidents at each service provider to get an idea of how competent they are at keeping your data save.


Security of cross-origin XMLHttpRequest Javascript

Don't use encodeuricomponent - this is for percent encoding values for insertion into URIs (as suggested by its name).

Data itself cannot be malicious. It can only be "malicious" in the context where it is used. If all you are doing is displaying it on the page, go with the recommendation of setting text rather than HTML, as any characters with special meaning will be properly encoded using this property.

Use textContent rather than innerText as the latter is specific to Internet Explorer, with a few other browsers tagging along rather than a web standard.

JSONP is less secure than CORS, as you have to trust that the external domain is not injecting malicious script into your site (whether the external domain is malicious or has been itself compromised).


I got my drive "bitlocker encrypted" by enterprise admins. Will this prevent me to share docs with my collaborators?

No, it will not.
Bitlocker encrypts your files when your PC is turned off. That means if your PC is turned off and someone would steal it, your documents should be safe, assuming your Bitlocker password is strong.
Once you turn your PC back on and type your Bitlocker password, you can use it normally, as if Bitlocker was not present at all.


Is forward secrecy useful for an application where keeping message history is an integral part?

It depends on the capabilities of the attacker. If an attacker can compromise your device, then yes, storing the full message history obviously means they'll be able to see everything.

But what if the attacker can only see communication between the users? In this case forward secrecy is still useful, as it means breaking a user's long-term key at some point in the future won't compromise every message for that user, instead each individual key would have to be broken.

Forward secrecy works by using an "ephemeral key", which means a new key is negotiated for each message. It's the difference between an attacker in the future spending a couple weeks breaking your key and having every message you sent for several years vs breaking a single message's key and having only that message. Once keys can be broken quickly enough (perhaps with quantum computing) forward secrecy doesn't help much. In either case, the attacker still needs to have the ciphertext. If they don't have the ciphertext they can't decrypt it.

As an example, suppose you had a 512 bit RSA key a couple decades ago. 512 bit RSA was first broken in 1999, taking 6 months. Today it can be done in a few hours for less than $100. If you had many hundreds of messages encrypted for that key that an adversary had previously intercepted and wants to decrypt, all they have to do is spend a couple hours and under $100 to break your key and they'd have all of them. If each message had used an ephemeral key, they'd have to spend that much time and money per message.

You can think of forward secrecy as a stop-gap measure, making each individual key much less valuable. This works because once it's possible to break a key, it still often takes significant effort to do so, with the effort required steadily declining over time.


Possibility of faking someone's public key

If Alice keeps her correspondent's public key in a database, spreadsheet, text document; then it's feasible that your scenario would work.

However, most (including Alice hopefully) would only trust public keys that have been certified as authentic. There are two mainstream methods by which this is currently done:

Certified by a central authority

The public key is certified by an organisation specifically set up for this task - these are called Certification Authorities (CA).

The CA will have checked Bob's credentials when he asked them to certify his public key.  Bob can then send his certified public key (commonly known as a certificate) to Alice and his many other friends/colleagues.

If Alice only trust public keys that have been certified by trusted CAs then your scenario now fails.  You cannot sneak in your public key as it hasn't been certified and consequently Alice won't trust it.

You can approach the CA with your public key, but they'll only certify that it belongs to you - not to Bob (or Alice, or anyone else).

This method is used by the commercial CAs which sign the certificates used for asserting the identity of resources on the Internet (such as this site).  Organisations may also operate their own CAs.

Certified by friends and/or colleagues

An alternative to the above method is for Alice to confirm with friends/colleagues that already correspond with Bob as to whether his public key is genuine.  They'll know this by confirming with others, or by confirming with Bob himself (maybe a face-to-face meeting). This way, the trust spreads like a spider's web, leading to this concept being called a web-of-trust.

This latter method is used by Pretty Good Privacy and Gnu Privacy Guard.

The CA isn't the be-all and end-all of the problem though.  In your scenario you have compromised Alice's device, which means you could configure her device to trust public keys certified by another CA - namely yours.  You can now certify your public key masquerading as Bob's and Alice would unwittingly trust it.

However, CAs come into their own when we diverge slightly from your question and consider 'Bob' not to be a person, but instead to be a new resource on a extremely large network such as the Internet.  In such cases, the Web-of-Trust model would not work simply due to the scale of the problem of managing all the public keys.

In other words, a CA would not be of much benefit in a scenario which consists of a single one-to-one relationship, such as Alice and Bob in your question, because it simply changes the test Alice implicitly makes from Do I trust Bob's public key? to Do I trust that my device hasn't been configured to trust additional CAs?

However, in a one-to-many relationship, such as the Internet, a CA will remove the requirement to somehow check each and every public key before use and replace it with checking the configuration of your device (which we all do without question!).

Of course, in the real world, if you successfully compromise Alice's device, whether you change Bob's public key is immaterial in the bigger picture.


Using getimagesize() is not made for testing if the file is an image. Just determining the type of known valid images. It is not meant for security, and can only be used as an extra check. A malicious file might make the function return a valid value while still being malicious, so that's no good.

OWASP is the go-to source for prevention and attack cheat sheets. This is the main point on file uploads:

  The upload feature should be using a whitelist approach to only allow specific file types and extensions. However, it is important to be aware of the following file types that, if allowed, could result in security vulnerabilities.

  "crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight. If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks. Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".

  ".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted.

https://www.owasp.org/index.php/Input_Validation_Cheat_Sheet#File_Upload_Validation

More can be found here under prevention:

https://www.owasp.org/index.php/Unrestricted_File_Upload

But even this will fail if there's a vulnerability in the parsing code of your application ( stagefright for example )


It depends on budget and contract with your provider how far you will be able to go. You can try and use automated scanners like apkscan.

Another possibility, which will be a lot more thorough (and a lot more expensive), is to hire specialized security companies who can either perform a source code review of the application (and you will have to compile the APK yourself from the reviewed source code). If your provider does not want to give you the source code then you could request your security consultants to reverse engineer and review the provided APK. (but there might be difficulties here as well)


First things first

Are you even allowed and authorized to test and mess around with this? You might need a written proof for your own sake in case it turns bad. Make sure you're not doing this live on some production server, use a test server instead.

Back to the basics

A classic way to demonstrate SQL injections:

$id = isset($_GET['id']) ? $id : -1; // Set default value if id isn't set
$stmt = $db->query('SELECT * FROM articles WHERE id=' . $id);
$results = $stmt->fetchAll();
fancy_display($results);

To get all the rows, we might use 0 OR 1=1. The final query will look like this SELECT * FROM articles WHERE id=0 OR 1=1. Since 1=1 is always true it will return all rows from articles.

This is usually not what we want unless we want to stress the server in some way. So we tend to use UNION to reach other tables: 1 UNION SELECT ALL 1, 2, username, hash from users.

What about injecting an INSERT after SELECT?

SQL injection is really about modifying the original SQL query in unintended ways. The query needs to be valid to be successful. Following our previous example, you can't just mix an INSERT with a SELECT in one query:

SELECT * FROM articles WHERE id=1 ALSO INSERT INTO articles (title, content) VALUES ("foo", "bar")

Note that ALSO is just an imaginary keyword, well since it's not supported. Another attempt would be to use to separate queries by separating them with ;:

SELECT * FROM articles WHERE id=1; INSERT INTO articles (title, content) VALUES ("foo", "bar")

Most of the times this won't work. The second query gets ignored, because the underlying code needs to specify it's using "multiple queries" also known as "stacked queries". In PHP for example, one needs to use mysqli::multi_query instead of mysqli::query. Most applications use the later equivalant. You might want to read a previous answer of mine.

Injecting an INSERT statement

So the other legit way is to try and find a vulnerable code that uses INSERT:

// Registration page
// Got credentials via $_POST
$username = 'foo';
$password = 'bar'; // not hashed, so bad

$db->query('INSERT INTO users (username, password, admin) VALUES ("' . $username . '", "' . $password . '", 0)');

The final query will look like:

INSERT INTO users (username, password, admin) VALUES ("foo", "bar", 0)

We change the flow by using a different password: bar", 0), ("haxors_admin", "easy", 1)--. The final query will look like this:

INSERT INTO users (username, password, admin) VALUES ("foo", "bar", 0), ("haxors_admin", "easy", 1)--", 0)

Everything after -- gets commented and thus effectively ignored. We just added an admin user. Note that this scenario is very simple to demonstrate the attack.

sqlmap joins the fun

sqlmap is an automation tool to find SQL vulnerabilities and exploit them. Apart from data exfiltration, it also has options for OS takeover like --os-shell or --os-cmd.

Under the hood, it will check if stacked queries are supported. If it is, it will either use sys_exec or sys_eval to execute those commands. If it isn't, it will try to use a web backdoor (for example a php backdoor) to execute those commands. The backdoor is created by injecting INTO OUTFILE: trick the query to write to a writable folder. Now if MySQL doesn't have the rights to write to that folder, it won't be created. Thus the attack fails. This attack vector is better explained in the sqlmap usage wiki. More on this in Advanced SQL injection to operating system full control (whitepaper).

Conclusion

In your case, stacked queries aren't supported and MySQL doesn't have enough rights. Which explains why the attack failed. Aside from learning purposes, I would advise to not bother further and start fixing vulnerabilities.


how do CPU cache side-channel attack fit into the background of Meltdown vulnerability?

There's an XKCD for that!.

A page is the smallest unit of data for memory management in a virtual memory operating system. That means when data is moved in and out of caches it is moved in chunks of at least 1 page.

In the simplest case lets assume the attacker is interested in a single byte of memory. Lets say this byte is at address 0. The attacker sets up an array which is 256 pages long. Lets call this array "page_array". They then trick the processor into performing the following -

1. load address 0 into register[X]
2. load the byte at page_array[PAGE_SIZE * register[x]] into register[y].
   // PAGE_SIZE would usually be 4096

The CPU then realizes its mistake and undoes all of the above. But meanwhile the page containing page_array[PAGE_SIZE * register[x]] has been fetched and is sitting in the cache. i.e if the value were 1 you would expect -

bytes at page_array[0 to 4095] to be unlikely to be in the cache.
bytes at page_array[4096 to 8191] to be likely to be in the cache.
bytes at page_array[8192+] to be unlikely to be in the cache.

By timing access to page_array[PAGE_SIZE * i] for i in the range 0 to 255 the pages which load fastest are almost certainly in the cache. The difference is large enough that by selecting an appropriate threshold you should be able to somewhat reliably discern between a hit and a miss.

By repeating the same process multiple times and taking special steps to flush the array out of the cache before indexing into it a malicious actor can reach a point where they have the correct value with a very high statistical probability.


You should be concerned only when using non secure connections ie.http
these connections can be sniffed.

what is important is to be aware of various attacks against encrypted connections, basically, ensure you do not accept new SSL certificates if prompted, unless 100% sure.

another important thing is to ensure your software firewall blocks inbound connections, if you're running a service that requires inbound port to be open, ensure software listening on this port is fully updated.

also, keep in mind if your PC/phone is infected already then all of the above doesn't make sense, in which case you should fix that first.


Practices for storing username/password in Web applications

The server needs to be able to access some resource R. If an attacker has full control of the server then that attacker can by definition now access any resource the server can access. There is absolutely nothing you can do about this except secure the server.

If the attacker doesn't have full control of the server but has access to the server's file system then the question is if the server needs to boot autonomously (without any external help). If the server needs to boot autonomously then all the data required to access resource R must reside somewhere in the server's file system and are thus available to the attacker. The best you could do is to try and obfuscate the password - good luck with that.

If the server can use external help to boot then the best option would be to require an administrator to enter the password during boot (and keeping the password stored in RAM).   If that's not a practical option (it usually isn't) then you could secure the password using a USB token (e.g. store an encrypted password and use the USB token to decrypt it).

TL;DR: Assuming you can't manually enter the password every time you boot the server there's not much you can do except protect the server itself.


How can I securely disable CSRF validation for native clients when browser clients access the same API?

You have a few options, in random order:
1. Different authentication schemes
Web browsers frequently authenticate by session identifiers in cookies.  Many native apps attach auth tokens directly in the request header (in an Authorization header or some other custom header key).  CSRF is generally only a concern when authentication comes up with cookies.  As a result, if your application only checks CSRF tokens when the user is authenticated via cookies, and if your native apps don't use cookies for identifying themselves, then you'll be fine.
2. Client side certificates
This probably isn't worth the trouble, but if you enable client identification via client-side certificates (and do it properly) then you can be certain that the person on the other end of the conversation is an app, not browser, and disable CSRF validation.
3. Custom headers
One potential strategy would be to include a custom header with the request from the native app, and disable CSRF protection if present.  This is likely a safe strategy.  Further reading here:
CSRF protection with custom headers (and without validating token)
4. Anonymous requests
You asked about doing this is an anonymous manner.  To some extent (aka this is not 100% applicable) anonymous requests don't need CSRF protection because the whole point of a CSRF attack is to take over a user's session.  If a user is anonymous and not logged in, then there probably isn't much to take over anyway.  An application without logins, which stores no state as a result of client actions, doesn't really need CSRF protection in the first place (although I may have misunderstood what you meant there).
5. Separate Endpoints
I think this is what it really comes down to.  If you have an endpoint serving two different clients in two different ways, then I think the issue is that you need two endpoints, one with CSRF checks disabled and one with them enabled.  Of course this only actually works if the two endpoints are authenticated differently, which really just brings us back to item #1.  If you have two separate endpoints, one for native (with CSRF disabled) and one for web (with CSRF enabled), but both accept the same cookie for authentication, then an attacker can perform CSRF attacks the second they realize that that native API exists and accepts the same cookie as the web.
Ideally I think you should have two separate endpoints.  Even if the two perform almost exactly the same action, you can always just structure your system so that you use the same basic code to fulfill both API calls, but they have separate endpoints and separate authentication logic.  Of course the other option would be to have one endpoint meant for both systems, that operates exactly the same for both.  Having one endpoint that tries to operate differently for two different systems is probably the easiest way to get yourself in trouble.
I didn't hit up your questions point-by-point, but I believe these are effectively all the options you have, so hopefully it answers your question anyway.


I have a feeling this is really a graph theory puzzle. -- I kinda like those. -- But this is very different from a real live PKI implementation.

Anyway: here's what you could do in a real live PKI:

  I am supposed to add exactly one certificate so that T trusts G, but not D.

Add G to T's list of trusted sites.

  Another certificate is searched in order that D trusts J and L, but not K

Add J and L (or just B) to T's list of trusted site.


Should I tell my boss I have discovered their passwords and they are too weak?

While there is no doubt that weak passwords are an issue for your company, I would strongly advise against telling your boss about the things that you have done.

Your company decided against giving temporary workers access to sites and resources for a reason. Not only did you gain unauthorized access to the wireless LAN by guessing the password to the router, you also extended that access by probing the credentials against other resources - Resources that you were not supposed to have the password to. You then basically shoulder surfed your boss.

While there seem to be flaws in your employers policy concerning the access to company resources, and their password policies, all of these things could be considered 'hacking' by your employer and were definitely outside of your authorization.

If I were you I would log off the WLAN and ask your employer for the password if you want to have access to it. Apart from that you should stop trying to use other peoples passwords on any access points just 'to see if the same pattern was used'. Depending on the legal system of the involved countries you can very well face legal problems for these kinds of acts.

So what should you do with the information you have?
If your employer gives you a password to a service or a resource you could point out, that e.g. that password would easily be guessable for other people. I would not mention the other password here directly though.
If your boss seems interested you could volunteer to research password best practices for the company. If they are serious about it, this would eliminate your concerns.
If there is an IT person in the company you could bring these concerns to him as he will probably understand the need for a secure password policy better.


As of Nmap 7.70, this is not a feature that the Nmap development team is interested in developing. Full discussion can be found in Issue #1217, but the current best practice is to scan all desired ports against all targets.

EDIT: To everyone doing some big shell script to scan each port and host individually, you'll be here all day waiting for that to finish. Accumulate all the unique ports and targets and scan them in one go. You'll end up scanning a few ports on some systems that you didn't intend, but overall it won't take that long. And like everything else, it fits into one line of Perl:

perl -lanE'END{$,="\n";open$i,">ips";say$i keys%h;exec"nmap -iL ips -p".join(",",keys%p)}$h{$F[0]}=$p{$F[1]}=1' input.txt


BLP Lattice structure with missing top and bottom levels

You seem to have misunderstood how this lattice model works, and the diagram you gave doesn't really help. It's meant to be a 3D structure.

In this model, we have:

Entities - These are things that you can have access to. In your diagram, these are crypto and nuclear.
Privilege levels - These are generic levels of privilege that can be applied to any entity. Each higher privilege inherits the privilege below it. In your diagram, these are secret and top secret.
Entity privileges - These are privilege levels associated with an individual entity. For example, you might have (Top Secret {nuclear}), or (Secret {crypto}).
Escalation paths - These are ways to increase an individual's privilege. Notice that each line on the lattice increases one type of privilege - e.g. it's not possible to jump directly from (Secret {nuclear}) to (Top Secret {nuclear,crypto}). This allows for strongly defined privilege escalation procedures, and proper audit trails.

The lattice model essentially puts all possible combinations of entity access on each privilege level. As such, an individual can only possibly be at one point in the lattice.

Entity privileges in this model do not allow for cases where an individual can have a higher privilege on one entity  than another. You have the same privilege for all entities that you have access to, but you might not have access to some entities at all. This is often a good thing in classic law enforcement and government systems, but doesn't lend well to modern business computer systems.

Altering this model to have missing privilege levels or have missing layers doesn't make any sense. From a software design point of view, your administrator would hold the highest privilege level for all entities, whilst an unauthenticated user has no privileges on any entity. Individual users would be at any point in between. Removing any of these entity privileges makes escalation paths more circuitous, and makes for some unnecessary validation work.

If you're looking for a more flexible access control model, try access control lists with inheritance. In such a model, users may be organised into groups and subgroups, each of which have a base privilege level that inherits from its parent. Individual users may be escalated beyond the base level, but not below. This allows for complex privilege groups to be created with minimal work, in an intuitive way that mirrors your physical infrastructure.


How can kids transfer data to a school computer safely?

I'll argue that you're taking on this from the wrong side.  Instead of trying to protect the pendrive from malware assume that the pendrive is compromised as well (since it may at some point connected to a compromised system) and act from there.

I managed to get family members to assume that if their pen drives connected somewhere that is not under their full control then it likely contains malware.  And I do have a machine in which I can plug the drive, link the device, check partition signature, check filesystem signature, and (only then) mount it.  All this is done by a script that I know what is doing, not some automated auto-mount system which may try to read "smart" caches from the pendrive (autorun.bat anyone?).

The ornate procedure you link can be almost fully automated.  But there is more.

  who needs to bring a presentation to school

This means that the transport is one way (home -> school).  So the contents of the pendrive can be completely discarded once the presentation is made.  This makes things a lot easier!  There absolutely no need to mount the pendrive.  Your procedure can simply by to erase the partition table and write a new one.

So, your daughter can get a presentation to school, catch all the malware she wants in the process.  Return home and plug the drive into a "cleaning machine" which would simply overwrite the partition table.

Extra: overwriting the first, say, 16MBs of the drive (before recreating the partition table) may also be useful.  Software that creates partition tables may be buggy, and may not overwrite every byte of the old partition table, this would make sure that the old table (and some of the old filesystem) is completely erased.


Go to https://www.virustotal.com/

Put in the URL of the website you visited that gave you the JavaScript warning.

It will search to see if that URL has malicious content.

You will get results.

Unless there is zero-day malware on that URL, the results will be correct.


Can a SIM-less smartphone be tracked only by IMEI?

Phones without a SIM still talk to the towers whether you make emergency calls or not. They access the cell network for time updates, if nothing else. No "tricks" required, no "finding" required. You can see this if you go into the network settings and look up what carrier the phone is connected to.

So, yes, a SIM-less phone is still very much active and, therefore, traceable.


The attacker did not seem to really try to conceal his track :he could have faked an existing MAC address for instance, or used the classical yagi antenna + high power WiFi adapter to silently intercept your communication. Instead it seems he just used a classical home grade WiFi range extender with what seems to be default settings.

So it still seems very possible to me that he just wanted to get a free / pseudo-anonymous Internet access and was actually not interested in your own data.

You can (and should!) still inspect:

If you can determine the usage the attacker made of his access (have you got logs showing he connected end-user devices to browse the web for instance? Or high activity caused by peer-to-peer sharing services?),
If you can detect any abnormal activity on one of the account you were using during this period (mail, websites, etc.).

In all case, while changing the WiFi access security and password was the minimum, as a precaution measure I would also suggest to change the password of the above mentioned accounts.

Note that the direct attacker of your WiFi account may not be your only threat there. If, as I suppose, this attacker used your Internet access to go on dubious websites or freely download pirated material, then chances are that his own machine may be infected by some malware so, for some time, you hosted an infected machine in your network. This may worth a few sanity measures.


How does xss work with web applications that take payload not through url

There is stored XSS and DOM based XSS which do not rely upon a GET parameter.  POST based XSS is exploited using a simple cross-site post request,  which can be triggered using the following HTML and JavaScript

<form id=xss action=http://target/action method=POST>
  <input name=param3 value="'+alert(document.cookie)+'">
  <input type=submit>
</form>
<script>
  document.getElementById("xss").submit()
</script>

Once the XSS payload stored in param3 is executed within the context of http://target,  the Same-Origin Policy is bypassed.


When hashing, do longer messages have a higher chance of collisions?

What pieces of the puzzle am I missing? Does the ease of finding a collision depend on input length?

For finding a collision it is not relevant how long a string is (apart from the time needed to compute the hash - which is actually longer for long strings) but how many different strings you try. Because the more different inputs you have the higher is the chance that any of these result in the same (fixed length) hash value, i.e. a collision. And there are simply more different long strings than short strings.

For example: there are 10^3 = 1000 strings with 3 digits but already 10^6 = 1000000 strings with 6 digits. If you imagine a hash which consists of 4 digits then there might be a collision with the 3 digit strings but there will be definitely many collisions within the 6 digit strings because there are way more string values than hash values.

  The longer the allowed input, the easier to supply an input that could cause a hash collision

The statement you cite is wrong in the current form. It is true that the chance is higher that the strings you'll find will be long. But since there are many more long than short strings this does not make finding a collision any easier. Again, what counts is the number of different inputs you have and not the length.


Does bcrypt compare the hashes in "length-constant" time?

The cool thing about hashing is that even a one-bit change to the input will completely change the output. Keep this in your mind! How does that relate to your question? Well, bear with me a little.

In the vast majority of cases, access to the salt implies access to the password hash. This is especially true in the case of Bcrypt since almost all implementations store the salt, the hash, and the iteration count in the same string with delimiters. Also keep this in your mind!

Since the comparison is happening on the password's hash, and any change to the input password will completely change resulting hash (remember?),  the yield of the timing attack will be information about the hash itself at best. However, that's only true if the attacker has access to the salt. Remember what we said? An access to the salt implies access to the hash. This means that the timing attack in this case is irrelevant.

If the attacker doesn't have access to the salt, then the timing attack will give (practically speaking) zero information. Thus it will give the attacker zero advantage.

Bottom line: For hashing schemes such as Bcrypt, Scrypt, etc., timing attacks are irrelevant. Using comparisons such as == and === isn't a problem. Having that said, using constant time comparison is a good practice as part of a defence-in-depth policy. In fact, many Bcrypt implementations already used timing-safe comparison just in case (timingsafe_bcmp.c in py-bcrypt, for example).

Update:

There is indeed a way to extract some information about the hash without knowledge of any of its components (salt, iterations, or plaintext value). It's described in a comment by Oasiscircle

  This can still leak parts of the hash using the early-exit byte
  comparison. Example: Attacker computes tons of hashes and stores them
  looking for a hash that starts with 0x00. Upon finding a plaintext
  with that value, send that plaintext, listen for timing on response.
  Do this for 255 more values until one value takes slightly longer.
  That's the first byte value of the hash created from the plaintext.

Having that said, I still hold the same opinion expressed in the original answer about the irrelevance of the timing attack when using a hashing scheme such as Bcrypt. While there's indeed a possibility of such attack, it's extremely infeasible. The computation and storage requirements for such attack are enormous, and they keep grown exponentially with every bit discovered from the hash.


The addition of the user requested feature doesn't seem to add any security vulnerability to the current flow of things.

  I am suggesting the feature could possibly open the email system to
  attack by locking all users accounts and issuing emails on mass
  assuming someone knows all usernames.

Does the "forgot username/password" feature send an email to the user with a password reset link? If so, then an attacker that knows the username could still force the victim to be peppered with a different category of emails, by initiating password reset emails a bunch of times

  Feature does not add value to the user, as our product provides a nice
  forgotten password ability.

In line with Matthew's comment, the average user very probably does not know why they are not able to successfully log in. Unless they explicitly know that this because of a lockout, they would most likely blame the application.

Additionally, it is never bad to have a measure in place that doesn't pepper locked out users with repeated "locked-out" emails. One email with the necessary information on the account being locked out should be sufficient. The user not acting on the email is their own bad. Beyond that, as you say, they could always access the forgot password feature.


Symmetric and asymmetric encryption are distinct operations which operate in distinct contexts, for distinct usages and distinct attack models. There is little sense in claiming that either is "more secure" than the other (it would first require some kind of quantified measure of security, which is not easy to define).

Asymmetric encryption is more demanding: it is about realizing encryption and being able to publish the ways to encrypt (the public key) without revealing the ways to decrypt (the private key). A practical implementation needs mathematics, whereas symmetric encryption is mostly scrambling things around (mind you, it is difficult to do a good job of scrambling; but still, less mathematics are involved).

Commonly deployed systems (e.g. SSL/TLS) combine asymmetric encryption and symmetric encryption (and a few other things as well) into protocols which do some intended job (e.g. "bidirectional tunnel with confidentiality, integrity and authentication").


Behavior Monitoring in Endpoint Protection Platform

Generically, an EDR-EPP combination such as the ones you describe will assign a threat score based on machine learning, statistical techniques, and a variety of known badness factors, such as enrichments from machine-readable threat intelligence (which can, in turn, also be informed by machine learning, reinforcement learning, and statistical techniques).
I would say the primary variables that lead to a higher threat score (and this changes over time), would be Prevalence factorization, such as through a large customerbase, but also specific to each's environment(s).
Combined with spawning numerous processes, levering LOLbins in unusual/outlier ways, and other combinatorials (not too too many packaged Portable Executables will lever kernel timing functions and also have access to the camera, microphone, and network stacks -- only implants typically display ALL of this activity at once). Those combinatorials typically are referenced through function (API) analysis, and their associated imports. Anti-detection, system querying, anomalous in-binary values, and certain memory-handling conditions are supplementary to the above.
Please ask deeper questions on the above and I can provide deeper answers.


Can my school look at my search history through Google Chrome if I am logged in through my school account?

The searches are logged under your Google Account and could be seen by your school admins.  You can disable search and other activities from being logged via your Google Account's Activity Controls. You can also delete previously logged activity - see Privacy & Personalization panel in your Google Account.


It seems to me it's possible snort was doing its job.

ET INFO Possible Chrome Plugin install

The above rule detects when a chrome extension was installed. So perhaps you installed one from google.

SENSITIVE-DATA Credit Card Number

The above rule matches any number in a packet that resembles a credit card. Perhaps one request you made contained a sequence of numbers that looked like a credit card.

The next questions
- verify each happened (what extension ? What number ?)
- do you want to monitor these rules ? Perhaps turn them off
- if left on , should they be blocking or just alerting ?

Snort rules require a lot of maintenance and tuning


Transparent key management for client computers

I personally recommend Hardware Key stores for these type of tasks. there small USB devices that work like a smart card that store the actual key information on it. than the software just uses as encryption key. you can use 2, 1 in a safe and 1 at the client.

These tokens are not very expensive and solve many of the issues you would have when using a password based encryption.

2 examples I know of:

Yubi Key
Nitro Key

There are more of these but I find there more expensive where I live.


No, I wouldn't worry too much about other applications, especially not the ones you've mentioned above.

First of all, they don't send out as much information as your browser does. Depending on the protocol or application there might be a a couple of things like a header describing the used program or version, but usually there are no plugins or extensions making it easy to identify you. Furthermore in most cases there are only a few appliactions to be used, e.g. for SSH it would be the OpenSSH client and PuTTY. Everything else would be quite unusual.

Secondly, you don't use these type of application randomly throughout the web. In a typical scenario you would use them only to interact with a few selected servers. You most probably need to login, in order to be able to use them anyway, so you can't expect any privacy.

Having said that, you can always use a packet sniffer, e.g. Wireshark to look at the things you are sending out and evaluate the situation for yourself.


What's the purpose of Server Key Exchange when using Ephemeral Diffie-Hellman?

In Diffie-Hellman, the client can't compute a premaster secret on its own; both sides contribute to computing it, so the client needs to get a Diffie-Hellman public key from the server. In ephemeral Diffie-Hellman, that public key isn't in the certificate (that's what ephemeral Diffie-Hellman means). So the server has to send the client its ephemeral DH public key in a separate message so that the client can compute the premaster secret (remember, both parties need to know the premaster secret, because that's how they derive the master secret). That message is the ServerKeyExchange.

I'm not sure what you mean by "a message that allows the client to contribute more material earlier" in regards to the ServerKeyExchange. The ServerKeyExchange doesn't let the client contribute more material; the client sends a ClientKeyExchange in all TLS suites. The point of the ServerKeyExchange is to let the server contribute more material to the key exchange, by letting it send additional information not in the certificate.

About "backtracking to premaster secret:" The premaster_secret is the immediate outcome of key exchange. Key exchange in TLS never produces a master_secret directly; this is because the TLS designers wanted the master secret to have a consistent length with entropy spread throughout, so that your key derivation code doesn't have to worry about how key exchange happened. Different key exchange methods produce differently formatted shared secrets, so you always have to convert the premaster secret to a master secret of 48 bytes. There's no real concept of "backtracking," as the master secret isn't derived until key exchange is finished.


How to add a custom CA to androids trusted root system folder

Magisk claims to do this.

  This module makes all installed user certificates part of the system certificate store, so that they will automatically be used when building the trust chain.


Your attempt to establish the theory behind the creation of the password has some shortcomings to it. Let me explain

Taking an easy password like foo and the attempt to transform for_website.com will lead to the attacker creating a set of files that would allow him to crack into the simple function and  then generate a list of all the hashes using a combination of dictionary attack and a list of most your used websites and use that as one of the input to the password cracker. Which is why crypto-graphic algorithms are somewhat complex in their working.

To answer your other question:

Use a password manager on your mobility device. Try some of the apps available on your OS store.
I would say it as bad as it. Because there is no significant gain in the security. You would be better off using other available proven methods.
Totally depends on the context. Generally means a list of passwords in a text file that could be used as input in cracking tools or could also mean a list of compromised passwords.


Yes, you need to scan the virtual hosts.

3. Prior to scanning the web site and IT infrastructure, merchants and service providers must:
• Provide the ASV with a list of all Internet-facing IP addresses and/or IP address ranges
• Provide the ASV with a list of all domains that should be scanned if domain-based virtual hosting is used

Details

PCI scans are not just testing the security of your operating system, but your web server configuration and application security among other things.


There are different types of authentications for cards.  Years ago the old mag stripe cards (still in use in the USA) had only "Static Data Authentication" (SDA), which was a fixed, unchanging number embedded in the mag stripe, similar to the CVV2 printed on the back of the card.  The data breaches that have rampaged across America in the last few years have been due to exactly the problem you identified; that is the malware in the payment terminal makes a copy of the data and sends it to the hacker.  SDA cannot defend against the type of copying you describe.

A more modern type of authentication is called Dynamic Data Authentication (DDA).  It takes advantage of the fact that the card data is delivered by a computer chip, and is not just a stream of fixed data.  The computer chip runs an algorithm to generate the DDA number; this algorithm uses a rolling code.  This DDA then takes the place of the old SDA.  During authorization, the bank notes the rolling code value used to generate that DDA and invalidates any older DDAs in order to prevent a replay attack using any earlier DDA codes.

That means that if a terminal makes a copy of a DDA card's data verbatim, including the DDA, the bank will still reject it on future transactions because that DDA has already been used.

Finally, EMV supports the Combined DDA (CDA) method, which is a cryptographic operation based on various pieces of data available in the transaction, including the transaction number, amount, terminal ID, an internal counter, a terminal-generated random number, and a secret key stored there by the issuing bank.  The algorithm produces a cryptogram that can only be recalculated by someone who knows all of those components; since they include the secret key, only the bank or the card's chip could reproduce them.

(There was an attack possible when the terminal's generated random numbers weren't truly random; changes to the EMV spec in revision 4.3 addressed that.)

Note that some older EMV chips may still use SDA because it's still supported by the protocols.  But if the authorization data is skimmed or copied, the bank who issued the chip with SDA has to pay for the fraud because they used known insecure technology.


How to exploit open redirect vulnerability?

Exactly as you are doing. The idea of open redirect vulnerabilities is to use the trust a user has in a specific website (the vulnerable site), and exploit it to get them to visit your website.

So you would send this link to a user: example.com/?url=evil.com/sploitCode.php. Because the website they see is example.com, and they trust them, they will click on it (in theory). On the other hand, if you would have send them evil.com, they would not click on it, because they do not know or trust it.

You can also obfuscate the url further example.com/some/nice/sounding/path/%2F..%2F..%2F..%2F..%2F/?url=evil.com/something-less-evil.php?some-unneded=parameters. Then you can also wrap it up in a nice a tag, so users will be less suspicious (then the main advantage is that hovering over the link will show them an innocent link at first glance) .


Can I safely store my admin scripts in a publicly available script file?

There's no security risks associated with including everything in a single file. This is typically what web optimizers do anyway.

Whether it's safe to allow public access to admin scripts though, depends on what's in them. You've mentioned you don't store credentials in there, so it shouldn't be a security risk. However you may potentially have intellectual property that you'd prefer your competitors don't get access to. In this case you could potentially protect them in the same way as the rest of the admin only content.


Security of Site-to-Site VPN vs Client VPN

Hmmm.

Thst you say "using the Cisco client" makes me think you are already using a VPN.

It seems odd when you are the service provider that your customer should dictate how you provide that service. Particularly if this is a purely technical service (e.g. a web based application). I can understand that if its more of a business service - such as managing multiple devices within the customers network, that a VPN would be the right solution - but for some sort of application service then a VPN is the wrong approach - by default it gives too much access which you then must tailor down to the minimum necessary to perform the function. OTOH using an TLS wrapped service, with client certificate validation, protects both you and your client.

Given that you appear to be in the situation where your customer thinks that a site to site is the only viable solution, it is of course quite possible to setup a "network" at your end which (from your perspective) appears to be part of the customer's network and simply implement a better connectivity solution from there into your actual network. But this is mostly conjecture - I know nothing about what this service is, nor your customer's motivations - you really need to speak to them and understand the problem properly (or provide more information here).


How to securely store and use 3rd party API Keys?

Based on what you stating on your question.
Just use plain certificate store such as JKS file, file or PFX if running on windows and then secure your file system , so the file is protected.
This is if you are storing private keys, however if your application is the client of a third party service then you only need their public key, which does not need to be protected as good as the private key.
Your application still needs the passphrase to open the key store.
there are some security patterns for certificates such as rotating certs.


My credit union is reducing its maximum password length to 10 characters

WARNING: Do not change your password!

This seems exactly what scammers would do to trick you into giving them your password.
Do you really think your bank would send a message like this on Friday with a deadline just over the weekend so there is no chance for you to call them for verification?


Good way to protect lots of private keys

Buy yourself an HSM.

Then its your choice :

Store the keys on the HSM; or
Create an encryption key on the HSM and encrypt the keys stored in the databse using the key stored in the HSM.

An HSM-based solution of some description is the only real way to get real assurance against attack.  HSMs are robustly designed for security and explicitly designed to make it impossible to gain access to key-data stored on the HSM.


Does an ethical hacker need to stay anonymous?

When you find yoursel wondering whether something is or not ethical or reasonable in IT world, just try to transpose it in real life.
Searching for exploits or security flaws in an information system is like trying to enter into a closed building. Serious companies do hire specialists to show them possible problems in their security. But when they find someone that was not asked to do that trying to enter in their building, they call the authorities before asking the guy for his motivations.
Transposing it into the IT world means that if no bug bounty program was published, and you have no contract (whatever the legal form) that allows you to search for exploits into an information system, doing it is clearly an attack and can lead to legal action against you if you are caught. And only in that case you need anonymity.
Now for your question.
If you have a contract with a company to search security flaws in their system, anonymity does not really matter because they already know you. If there is a bug bounty program, anonymity will only make harder for them to retribute you. That is the real why anonymity is not really a concern for white hat hacking.
It is only in what I would call grey hat hacking: trying to find exploits more or less at random with no authorization even if with no bad wills. But as I said above, this is not allowed, is likely to be seen as offensive, and could lead to legal actions. My advice is to just avoid it.


It looks like all I need to do to acheive this is set the permissions to 711 on /home/sites:

rwx--x--x

Then a directory listing cannot be generated but files within it can still be accessed.


PGP (and also GnuPG) uses the concept of a web of trust to allow you to validate the ownership of other's keys, also if you didn't meet them in person.

PGP's Trust Model

A long explanation is in PGP's manual, starting from checking trust. The short version:

In PGP, a key is valid, if

it is not revoked or expired
it is your own key (which is also implicitly trusted) or
it is certified (signed) by other valid and trusted keys, requiring at least either

one certification by a fully trusted key or
two certifications by different marginally trusted keys.

Certifications are shared on key servers and show that the issuer is sure about the signee's identity. Trust is only locally (by yourself) and not shared, and defines whose certifications you trust for validating other's keys.

Trust example

Alice certified Bob's key, and fully trusts Bob. Bob certified Carol. As Alice key is valid (it's her own key), Bob's key is also valid (signed by another valid, trusted key), so keys certified by him are again considered valid for Alice, here Carol's key.

GnuPG's Trust Model

GnuPG has a very similar trust model, but by default requires certifications by three marginally trusted participants (or like PGP one by a fully trusted key), and limits the length of trust paths to five (allowing a maximum of four intermediate certifications).


What are the best IT auditing guidelines for Red Hat Linux 5.x+, including the critical data protection?

look at this CIS benchmark  RHEL 5 Benchmark


I thought that this would be easier to look up, but everything I found was oddly worded.
The reason why there is not a good description is because the handler does what it is told to do. So, quite literally, it just "responds". But there are some common use cases that should make it easier to understand.
The handler is a process on the attacking machine (metasploit) that listens for and responds to connections made from the target. So, when you launch a reverse shell, it's the handler that is listening to the port you set up and then responds to the reverse shell.
The handler knows what the incoming connection needs. For instance, if it is a staged shell, that it requires the next stage.
And it can provide an interface for you to interact with the remote shell.
It can do more than this, depending on the payload, but this should give you the best idea.


Force a device to give up its IP address?

This would be an "attack" that would prevent only devices that don't know the MAC address/IP correspondence to talk to Device A. Under normal circumstances they would have the MAC address of Device A in their ARP cache.

If however this cache expires or a new device is connected to the LAN (the same broadcast domain) then the ARP request "who has 192.168.1.2" would be answered by two different machines. Quoting from Networking Basics: How ARP Works:

  In the case where multiple machines have the same IP address, you may
  get multiple responses. The one that gets placed in the ARP table can
  vary depending on the networking implementation, how busy hosts are,
  and how quickly they respond, etc...

Your concern is unavailability of Device A but another thing that can happen is for an attacker to be a man-in-the-middle: Inform you Device A that he has the IP of the gateway and inform the gateway that he has the IP of Device A. He will thus make all traffic to and from Device A pass from the eavesdropping system in the middle.


For email security you can consider the following. These are common issues which are not well secured because of other factors, so the basics like XSS, virus scanning etc are not considered.

Strict SSL-only access with no known attacks like BEAST
Log of previous logon attempts
Encrypted storage
S/MIME, PGP support
TLS on SMTP and IMAP
High security application, which is not the case for most Webmail providers

So all of that is OK with GMAIL, Hotmail had issues with cookie handling recently (so it was enough to submit simple empty cookie for a session).

The most secure is to have email server on your own location, and protected the way, that without logging in with mailbox login / password, you cant read mail, and then simply run auto-update on the server, to make sure that the mailbox storage is not breached. Basically webmail with updates and good hardening does the effective trick good even for 100.000 mailboxes for business use.


What's the purpose of a key hash when you have the fingerprint?

I think you're mistaken. The top hexidecimal value is the key ID. That's what they're explaining at the top of the search results page with: Type bits/keyID            cr. time   exp time   key expir.
The second line with "Hash=" is the fingerprint of the public key calculated with MD5.
Fingerprints and hashes are functionally similar in that they are both produced by one-way functions. They both take arbitrarily large inputs and produce a smaller output. The important distinction is that cryptographic hash functions require collision resistence while fingerprints do not. The trade-off is that hashes are slower than fingerprints to calculate. So for large amounts of data, use fingerprints. For security-critical applications, hashes. Or both, starting with the faster fingerprint and using it like a Bloom filter. This specific case is a little confusing because MD5 is a cryptographic hash function used for fingerprints. MD5 is no longer considered trustworthy for cryptographic applications but can still function for fingerprints.
If you want the SHA256 hash you can use ssh-keygen -i -e "SHA256" -f yourkeyfile.
If you and your friend are using out-of-band communications to verify your keys then good job. Just use the fingerprint provided by gpg --fingerprint.


What is the most reliable way to transfer emails without specific recipient support?

Can't be done.

To achieve option 1, you need digital signing, and the receiving end has to check the signature.
To achieve option 2, you need encryption, and the receiving end has to decrypt.
To achieve option 3, you need the receiving end to check for a forged sender address.

You're always going to need stuff at the receiving end. Now, that could be in the server, or the client. But it needs to be there. And you have to decide what you want to happen if it's not there. Have the mail fail? Or allow it to go in an insecure fashion?

w.r.t STARTTLS, that is just an extension to the SMTP protocol allowing the originating server to ask the receiving server to use TLS for the connection. So basically it is TLS.


With the mknod command it is possible to create device files other than those that already exist in /dev.

$ sudo mknod /tmp/sda b 8 0
$ fdisk -l /tmp/sda
Disk sda: 80 GiB, 85899345920 bytes, 167772160 sectors
...

When a filesystem is mounted nodev, you can still create such device-files, but they are no longer usable.

An attack on /tmp files works like this. A program with elevated privileges opens some temprary file in /tmp and writes something to it. An attacker will beforehand do something to this file so that the program actually writes to another file.

The attacker symlinks /tmp/tmp1234 to /etc/passwd.
Root runs some program which writes to /tmp/tmp1234 as a temporary file.
/etc/passwd gets overwritten.

You can see that if /tmp/tmp1234 is not a symbolic link but a device file instead, the program would write to /dev/sda, or some other device, which could have bad results.


First, I think we should clarify vocabulary. DAC means discretionary access control, which means someone (to be defined) can decide who accesses what within the system, when MAC, mandatory access control, tends to relate to systems where access cannot be given within the system.
In my understanding, neither DAC nor MAC implies a specific implementation.

Concerning RBAC in the UNIX world, IBM has a good explanation on why this is important: http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.security/rbac.htm?lang=en. The AIX RBAC implementation implements a partition of the set of all root accesses and allows specific roles to have specific admin access (on the network, on the passwords, and so on)

Your example with sysadmins and managers is a good one although limited to the user space and file access.

So regarding your last question about the place of an RBAC UNIX implementation  (layer or different internals), it seems it largely depends on what access we're talking about.

If file access is concerned, RBAC can be implemented with existing functions, although ressources a role can access are not centrally managed as you mentioned. A layer of abstraction could deal with that.
if root accesses are to be divided in many accesses (The AIX RBAC implementation), then I guess some internal work is needed with new methods and data structures in the OS kernel.

Hope this helps,
Regards,


For users that does not use PGP, what would be the other channel to securely send them a document?

You assume that the document has to be sent via email.  It sounds like you are only protecting against interception while the email is being sent (smtp).  If that is the case, you only need secure transport and not necessarily encryption handled by the end user.

Can't you have them download the document from a web server you control over SSL?  You still have to give them the URL and password in some manner, but at least you can remove the document from the webserver.  They are going to have a clear text version of the document anyway, so it doesn't matter if you keep it in the clear on your webserver, but behind a password.  You can control access and pull it down after they get it.


Question on information retrieved from systems that could potentially lead to exploits

If your web server is only serving specific IPs, it's probably a better idea to only allow those IPs in your firewall.


How to avoid local caches when I open encrypted files

Security is hard. While I applaud your attempts to use commonly available programs to increase your security, software that wasn't expressly designed for security often does the little things wrong (as you found out). In your case, your rar program makes a local cache of the contents, presumably so it'll run faster - something that most users would be happy about.

TL;DR: the single best way to protect yourself from data leakage on a personal computer is to use full-disk encryption (or encrypt your user's folder if it's a shared computer), a strong password for your user account, don't share your account with anyone, and make sure you log out (or at least lock your screen) whenever you step away from the computer. Also, turn on your firewall to make sure that programs aren't uploading data anywhere without your permission. That way, even if you are using programs that do the little things wrong, it doesn't matter.

You asked:

  if anytime I open a rar it caches its content, then is the whole encryption pointless?

To answer this question, let's start by asking what problem the rar software is trying to solve by offering this feature. Their goal is to protect the data while it's in motion; ie if I rar a scan of my passport and email it to someone, I want to make sure that nobody can open it unless I give them the password. This feature assumes that the endpoints are secure, meaning that once somebody types in the password, its job is done.

In fact, once it decrypts / unarchives the files and saves them to disk there's really no point in even trying to protect them anymore because every other program on your system can see them. For example, Windows Explorer will index and process the photos in order to display thumbnail previews, leaving cache files behind. And what about actually opening the photos? Which photo viewer will you use? Are you the programmer who wrote it? If not, how do you know that the photo viewer will not make cache files? Or maybe upload your files to the internet? The point is: unless you've personally inspected the source code of every program that's running on your computer (including the OS itself), any one of them could be doing naughty things with your data.

That kind of paranoia is exhausting. Just lock down your user account so that nobody but you can see the data, and let your programs do whatever they want.


As far as I know, Whatsapp uses Certificate Pinning. When I tried to analyze the Android app in january, it didn't accept my forged certificates (created with mitmproxy). I didn't invesigate this further and I might have missed something.

However, Whatsapp upgraded its encryption algorithms earlier this year and introduced end-to-end encryption, and therefore messages are now better encrypted than it would ever be possible with TLS.


Any benefit to proof-of-work to avoid database lookups?

You are asking several very different questions.

  I'm trying to limit the database queries and writes that I need to perform in case someone tries to make my costs very high

You should have a gateway (e.g. Amazon Lambda) that supports rate limiting. With this toy in your hands you'd be able to configure number of allowed requests. There are generic gateways available if standard stuff is not suitable or available, e.g. Umbrella.

  ... how to avoid double-issued requests to isolated replication nodes

You do this by configuring write quorum. More nodes in the quorum - better consistency but slower write speed (this is known as CAP theorem).

  There's no shared state ...

This is by design, shared state is a performance killer especially in distributed environments.


Trying to understand RSA and it's terminology?

The source of your confusion is an historical "explanation" of RSA signatures as being "encryption of the hash with the private key". This explanation is confusing, and flawed in many ways. It works only for RSA. Actually it does not work for RSA either.

Let's define things properly:

An asymmetric encryption system defines two functions:

Encrypt: takes as inputs a message (a sequence of bytes, possibly limited in length) and a public key. It outputs a value in a given space of possible values (in the case of RSA, this is a big integer, no longer than the modulus).
Decrypt: takes as inputs an encrypted message (an output of Encrypt) and a private key, and produces back the original message (provided that the private key matches the public key which was used for encryption, of course).

A signature algorithm defines two functions:

Sign: takes as inputs a message (a sequence of bytes, usually not limited in length) and a private key. It outputs a value in a given space of possible values.
Verify: takes as inputs a message, a signature value (an output of Sign) and a public key, and outputs a boolean value ("true" on match, "false" otherwise).

Since these four functions take different types of inputs and produce different kind of outputs, they cannot be swapped around.

In general, asymmetric encryption algorithms and signature algorithms live in separate worlds. It so happens that there is an asymmetric encryption algorithm known as "RSA", and there is a signature algorithm that is also known as "RSA". Moreover, they both use the same kind of public/private key pairs. However, still generally speaking, encryption and signature keys should be distinct.

If we look at the internals of RSA (both algorithms), as defined in PKCS#1, then we may find some common elements, and others which are distinct.

For asymmetric encryption, the message must be smaller (by at least 11 bytes) than the modulus. The message to encrypt is "padded" as follows:

0x00 0x02 rr rr ... rr 0x00 mm...

where mm... is the message, and the rr are random non-zero bytes. The number of rr bytes is adjusted so that the total length is equal to that of the modulus, and there must be at least eight such non-zero bytes (hence the restriction on the message length). The resulting sequence of bytes is interpreted as an integer modulo N (the "modulus" part of the public/private key pair), and raised to the public exponent modulo N. The result is the encrypted message: it is an integer modulo N (the convention is to encode that message in big-endian, yielding a sequence of bytes of the same length as the modulus).

To give some numbers: if you use a 1024-bit RSA key, the modulus has size 128 bytes. Messages that can be encrypted must be no longer than 117 bytes. The encryption result is a sequence of 128 bytes.

For signatures, the message that is to be signed is first hashed with a suitable hash function like SHA-256. Thus, arbitrarily long messages can be processed (SHA-256 has no practical limit on input length). The hash value is then padded, with a padding which looks like this:

0x00 0x01 0xFF 0xFF ... 0xFF 0x00 ii... hh...

where ii... is a conventional header that designates the hash function, and hh... is the hash value. The number of 0xFF bytes is again adjusted so that the total length matches that of the modulus. The resulting sequence is again interpreted as in integer, and exponentiated modulo N, but this time the private exponent is used. Moreover, most RSA implementations actually optimize that operation by using the Chinese Remainder Theorem through their knowledge of the factors of N (these factors are part of the private key).

So, while both encryption and signature generation rely on some sort of padding followed by an exponentiation, they differ in significant ways:

For encryption, the message is taken "as is" and is limited in length. For signature, the message is first hashed, and has no length limit.
The paddings differ. It is important for security that the padding used in encryption includes sufficiently many random bytes. It is equally important for security that the padding used in signatures includes sufficiently many non-random bytes. Less obviously, it is very important that the padding bytes occur "on the left" in the big-endian convention.
The exponentiations differ. For encryption, you use the public exponent, which is usually short (possibly down to e = 3, although the value e = 65537 is traditional)(as it happens, 65537 is used for no good reason at all, but hey, tradition is tradition). For signature generation, the private exponent is used, but the operation rarely use that exponent "as is"; in fact, two sub-exponentiations are done modulo p and q (the prime factors of N), for a total speed-up of about 4x.

In fact, the only really common point is that both RSA-encrypted messages and RSA signatures are integers modulo N, and are encoded with big-endian convention. Everything else differs. And, as I said earlier, you should not do signatures and encryption with the same key pairs anyway; both kinds of key pairs call for distinct management and lifecycles.

Some implementations of signature generation/verification accept as input a pre-hashed value. The hash function is still an important part of the overall process. Even if a given piece of code accepts the hash value as input, the hash must still occur at some point.

Some implementations of the RSA signature verification algorithm actually on "just" the signature and the public key; instead of the simple boolean result (match/mismatch), they produce the hash value itself; the caller is then responsible for matching that hash value with the message that is purported to be signed. The ability to recover the hashed message from the signature+public key is a specificity of RSA (RSA is said to be a signature algorithm with recovery). Not all other signature algorithms can do that. And, again, it is important that the hash occurs; don't let it make you believe that you could do "RSA signatures without hashing".

Traditionally, RSA signatures used in SSL have relied on a slightly different procedure: the padding lacks the identifying header (the ii... in my notations), and the hash value is actually the concatenation of MD5 and SHA-1, both computed over the message that is to be signed. This is a remnant from a past where the PKCS#1 standard was not as firmly entrenched as it is today.