Testing a password for similarity to previous hashes This question is a follow-up to a comment by Tobias Kienzler to an answer to "What is the purpose of the “Password minimum age” setting?".

Consider a password policy that new passwords cannot be identical to the current password or any of the user's five passwords that precede the current password. Nor can they be similar to the current password or any of these previous passwords, where "similar" is defined as Levenshtein distance 2 or less. (For the sake of this question, assume no complexity requirement other than six or more characters, one letter and one digit.) This protects against, say, "bush41", "clinton42", "bush-43" (which should be stopped), "obama44" (which should be allowed), and either "clinton 45" or "bush 45" (either of which should be stopped).

The ordinary password change flow requires the current password so that someone can't run a password change with a Firesheeped session cookie. The alternate password change flow sends a reset token through another channel, such as e-mail, voice, or text. In the ordinary flow, I can test whether the new password is similar to the current password by using the Levenshtein distance function from a library. But I don't have the previous password; all I have are salted PBKDF2 hashes. Nor can I test for similarity to the current password if the user has entered a password reset token instead of the current password.

In the aforementioned comment, Tobias Kienzler recommended to "compute all mutations of the new password within the unacceptable edit distance, calculate their hashes and compare them to old password hashes (with the respective salts)." In an answer to "Password security", an answer to "Does Facebook store plain-text passwords?", and an answer to "How can a system enforce a minimum number of changed characters in passwords, without storing or processing old passwords in cleartext?", apsillers, Michał Šrajer, and Ori suggested something similar.

But I don't see how it's tractable on present hardware to compute the set of all strings with Levenshtein distance 2 from a given 20-plus-character passphrase and hash them all, especially with an intentionally slow hash like PBKDF2 and a large character set like Unicode. It would appear to require around h(nc)s hashes, where h is the length of the history (here 5), n is the number of characters in a password (and thus the number of positions in which a replacement or insertion can occur), c is the number of characters in the character set (95 for printable ASCII or much larger for printable Unicode), and s is the maximum edit distance to call two passwords "similar".

So what is this computationally feasible way to test a password for similarity to previous passwords without storing previous passwords with reversible encryption? Would it require applying any or all of the following simplifications to the definition of similarity, and if so, would those simplifications compromise the password system's security in practice?

Require all characters in passwords to be printable ASCII (space to ~).
Reduce the Levenshtein distance of a "similar password" to 1.
Compare only the current password for similarity and the previous passwords only for identity.
Willfully sacrifice availability to protect password confidentiality. When a user requests a password change, lock out the user for the remainder of the day while the system enumerates all possible similar passwords, and disallow other users from changing their passwords if too many users' similarity searches are queued.

I'd like to suggest that you consider why people change passwords.  It could be because the user believes the password is compromised, or "because security;" the system is forcing regular changes in the belief that such changes somehow improve security.  I would argue that a strong password needs to be changed only in the case of compromise.  Further, there are thousands of weak passwords with a Levenshtein distance > 2.  I could alternate through: loveyou1, hateit2, scroomall3, Shannon4, and dammit5 and be completely within the rules you put forth.  Yet, all of these will fall to dictionary-based guessing in seconds.

You have correctly computed that you cannot do what is proposed within a reasonable time.

If you limit the key space to the printable ASCII characters, you violate one of Shannon's principles (the key space should not be artificially constrained) and at least potentially make your passwords less secure.  "Less secure" is at least mostly theoretical, because people will at least mostly use the characters on the keyboard.  Even so, we reject this alternative because it reduces the key space.

Reducing the Levenshtein distance to one doesn't really help you, as my examples show.  So we reject it.

We reject locking out users as a violation of the property of availability.

You are left with comparing the current password for similarity and the previous passwords for identity, and that is what I recommend.  You can't even do that when using a reset token, so you have to compare all for identity, and that is OK.  People should not "change" their passwords to their current values.

Beyond all of that, I'd suggest you revisit why you want to force password changes in the absence of evidence of compromise.  Mostly you will get loveyou1, hateit2, scroomall3, Shannon4, and dammit5, or things very similar.

Finally, it might be a better use of programming time to reject the most frequent 1,000 or 2,500 passwords instead of worrying about password history.  In a high-security application, you might reject the top 10,000, but for ordinary users that's tantamount to rejecting everything.  One such password list is here: https://xato.net/passwords/more-top-worst-passwords/


Why does malware periodically check google.com I'm looking at some malware PCAPs, e.g. http://malware-traffic-analysis.net/2014/05/27/index.html .

One of the things I've been seeing frequently is  requests to alexa top million sites (e.g. yandex, google, yahoo). I've always considered this to be a connection checking technique.

However, recently I've been thinking about other information you can glean from that request (e.g. a rough geoip feature through DNS / page redirection).

I am looking for links on the subject and thoughts about this technique in common/uncommon malware.

Most likely, it's just trying to check if there's a working internet connection.

The malware authors assume that:

Google (or other Alexa Top-1M sites) will be up 99.999% of the time.
Traffic going to common productivity sites like Google will not be flagged as unusual.
You (or your network administrator) will be unlikely to have blocked these sites at the gateway.

As such, Google is a good candidate.


Is there a way to change the creation date of a GPG/PGP cert How can I modify the creation date of a GPG/PGP key?  I can set the Creation-Date while creating a key.  But can I change this Creation-Date after the key was created?

I cannot find how to do this.

It's not possible to change the creation date of a PGP key, because the creation date is part of the Public and Private Key Packet.

The OpenPGP Standard (RFC4880) says

5.5.2. Public-Key Packet Formats

  (snip)

  A version 4 packet contains:

- ...
- A four-octet number denoting the time that the key was created.
- ...

5.5.3.  Secret-Key Packet Formats

  (snip)

  The packet contains:

- A Public-Key or Public-Subkey packet, as described above.

Also regarding signatures, the specification says under section 5.2.2.  Version 3 Signature Packet Format:

  The concatenation of the data to be signed, the signature type, and creation time from the Signature packet (5 additional octets) is hashed. The resulting hash value is used in the signature algorithm. The high 16 bits (first two octets) of the hash are included in the Signature packet to provide a quick test to reject some invalid signatures.

As you also added, in the GnuPG documentation under "Unattended GPG key generation" the documentation specifically says:

  Ceation-Date: iso-date

  Set the creation date of the key as stored in the key information and which is also part of the fingerprint calculation.

As you may understand by now, editing the creation date of your current key and keeping the ability to encrypt, decrypt and sign with the key is impossible. Simply because the date is used as part of the key.


How to secure Epson Beamer? I work in a school and we have several Epson Beamers but some of our students have download an application for their mobile (with infra-red and WiFi connection) and they now have remote control and the ability to shut the projectors down.

How to protect an Epson Beamer against people with such application? With an password or access control list (compatible with the normal remote control, against the app)?

Electrical tape works wonders.  If you still need to be able to remote control, you will need your own IR transmitter to tape to the receiver and a more secure triggering system for the IR transmitter taped directly to it.

There is no way to use the existing remotes in a secure manner.


NFC contactless payment security This is really bugging me.

Up until recently debit cards with an electronic chip were the most popular electronic form of payment available in Poland (I'd wager that in other European countries as well). It does seem pretty safe too - in order to make any kind of purchase (either from an ATM or in a store), the user needs to provide a PIN code. While said PIN isn't particularly long it's there to provide an extra level of security: the first being the card itself.

In recent times PayPass (or similar) cards have been gaining popularity and it seems banks are pushing these cards onto the public. These cards can act just like the regular debit cards described above, but you can also use them to make payments using NFC.

Here's the big deal: when making a payment through NFC the user doesn't need to input the PIN.

It seems to me that with a wireless technology like this, a PIN should be a definite requirement as it feels the technology isn't particularly secure. One example of this is the proxy attack, where one person with a cell-phone gets some items in a store and goes to pay for them, while another person with a cell-phone looks for a PayPass card to read (on a crowded train / bus / station / etc.). Depending on the technology used, those cards can be read from quite a distance away as well.

Which brings me back to the matter of PINs... Why aren't PINs always a requirement when paying using NFC?

EDIT:
I do realize that the amount you can pay for using NFC is limited*. However, as far as convenience goes (no need to put the card in / swipe wallet) it seems like we're trading security AND some convenience for... slightly more convenience.

What I mean: as it is, you can pay for small things by just swiping the card. Great. But inputting a 4 digit pin after swiping shouldn't be much of a deal, right? And then you wouldn't need to limit the amount you can pay for. You could still keep the card in your wallet, and the whole thing would be just as fast. In fact, ideally, you could have a "PIN-less" limit as it is now but allow NFC transactions over that amount... just require the PIN! Or are there other technical / security concerns with PINs and NFC in general?

* While it seems that this limit could easily be changed, I haven't heard of a bank (in Poland at least) actually allowing the customer to make such a change. I know I tried calling my bank directly and was informed this is impossible...

It is about risks weighted against benefits.

Requiring PIN for NFC transactions would reduce main NFC advantage - speed.
NFC payments without PIN are used only for payments of limited amount and usually for limited number of transaction and/or limited total amount of transactions per day. Maybe also other bank specific rules apply; at least I was informed by my bank that I may be asked for PIN without reaching any limit. This way card issuing bank or card company limit its risk (in EU you are not liable in the case of fraud for more then 150 EUR as long as you haven’t acted with gross negligence) and keep you using the card often and making profit for them.


Using the Android hardware-backed KeyStore I wish to use the Android hardware-backed KeyStore, but I'm concerned about security and usability.
From what I've read here, KeyStore gets wiped when the user changes the device lock, unless setEncryptionRequired() is omitted. For usability sake, it seems this needs to be done, otherwise all hardware-backed keys would get wiped once the device lock is modified.

However, I've also read here that hardware-backed keys are not actually stored in the TEE, but rather, stored as key files in /data/misc/keystore/user_0/, encrypted by a device specific key that is stored within the TEE. Since a change in device lock wipes the KeyStore, it seems that the device specific key is derived from the device lock.

For security reasons, it makes sense to encrypt the key file, otherwise any root user would be able to read the key files and extract the private key, since they'd presumably be in they clear.

So I'm kind of in a dilemma. For usability sake, I should omit setEncryptionRequired(), but for security sake, I should set setEncryptionRequired().

Lastly, is it possible import a private key into the hardware-backed KeyStore using setKeyEntry()? I'm able to do so with no errors but I'm not sure if it's hardware-backed.

Is my understanding correct?

setEncryptionRequired(): It is used to encrypt the key pair at rest and the encryption key is derived from the secure lock screen credential(e.g., password, PIN, or pattern).

Hardware Backed-Keystore: The key-entry files generated by hardware-backed keystore are encrypted using device-specific keys that is only accessible to trustlets executing in the TEE.

From the Android Sources

  TEE processors have become a mainstay in today's mobile devices. The
  main processor on these devices is considered "untrusted" and cannot
  access certain areas of RAM, hardware registers and fuses where secret
  data (such as device-specific cryptographic keys) is stored by the
  manufacturer.

So these are the two different encryption implementations using different encryption keys.
The key-entry files generated by hardware backed keystore are encrypted using device-specific keys.

To implement another layer of security, Android allows developers to encrypt the keys further using encryption key derived from the screen lock through setEncryptionRequired() option. It is clearly a functionality/security tradeoff relationship.

I personally feel that setEncryptionRequired() must be enabled for the devices that do not support hardware-backed keystore.


openssl problem decrypting passhrase-encrypted file using the derived IV, Key and Salt So I followed openssl: recover key and IV by passphrase and managed to retrieve my salt, key and IV using -P in openssl.

openssl enc -aes-256-cbc -in encrypted -pass "pass:password" -out m.jpg

this gives me the proper m.jpg file so I would assume

openssl enc -aes-256-cbc -d -in encrypted -pass "pass:password" -out m.jpg -P

gives me the right salt, key and IV:

salt=7A01E44D968CEBD0
key=6F4C7DD6F49D0605095CAD7EA2745913E83B71A52C34F2ED260544286FDEE78A
iv =0BBD122901B13F76D03ED2EBE4E8D1CC

Now when I tried to decrypt the encrypted file with the above salt, key and IV by doing

openssl enc -aes-256-cbc -d -in encrypted -K 6F4C7DD6F49D0605095CAD7EA2745913E83B71A52C34F2ED260544286FDEE78A -iv 0BBD122901B13F76D03ED2EBE4E8D1CC -S 7A01E44D968CEBD0 -out m.jpg

I wasn't able to decrypt the file. Maybe something's wrong with the format? So I tried putting them into quotes

openssl enc -aes-256-cbc -d -in encrypted -K "6F4C7DD6F49D0605095CAD7EA2745913E83B71A52C34F2ED260544286FDEE78A" -iv "0BBD122901B13F76D03ED2EBE4E8D1CC" -S "7A01E44D968CEBD0" -out m.jpg

and to no avail.

The --help states that

  -iv IV             IV to use, specified as a hexidecimal string
  -K key             Key to use, specified as a hexidecimal string
  -S salt            Salt to use, specified as a hexidecimal string

which is exactly what I did. Unless there is a special way of passing the hex string?

Or had something gone wrong in my process of retrieving the IV, key and salt? (Or in the process of decrypting the file)?

Just to be clear, as the answer you reference points out openssl enc is quite terrible and was never intended to be used for anything other than testing.

The problem is with inconsistent formats. If you encrypt with a password, it will use the 16 byte Salted__ header that includes the salt used in the key derivation. If you use the key and IV directly there is no need to specify a salt, and it won't use the salt header. Since you encrypted with a password and later retrieved the key and IV, you'll need to strip off the first 16 bytes before decrypting.

$ echo test | openssl enc -aes-256-cbc -pass pass:password -base64
U2FsdGVkX1/hmWydD0WX5S5n369MQhQ6Q3w4pxLYrh8=

$ echo 'U2FsdGVkX1/hmWydD0WX5S5n369MQhQ6Q3w4pxLYrh8=' | openssl enc -aes-256-cbc -d -pass pass:password -base64 -P
salt=E1996C9D0F4597E5
key=90C6AF89C13459AD5F55B9CD72705249BC494F4539D2FA75B4C6E5B343D7FDB2
iv =3D29E6F33CBBDA72B6757B5078003B53

$ echo 'U2FsdGVkX1/hmWydD0WX5S5n369MQhQ6Q3w4pxLYrh8=' | base64 -d | tail -c+17 | openssl enc -aes-256-cbc -d -K 90C6AF89C13459AD5F55B9CD72705249BC494F4539D2FA75B4C6E5B343D7FDB2 -iv 3D29E6F33CBBDA72B6757B5078003B53
test


How does one determine what strength parameter to pass to BCryptEncoder (default is 10) in Spring Java? The spring documentation doesn't say much, just that the default strength is 10. How does one determine when using increased strength might be warranted and what the trade off is?

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

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


wireless point-to-point security I have a remote site where I need to bridge approx 700m distance either with fibre or wireless for a backbone internet connection.

The digging would cost a bit more and many suppliers are offering point-to-point wireless technology.

I have seen Ubiquity, Silku and Cisco Meraki and I am sure there are many others which I am not aware of.

Price is one factor which I would only look at if you can compare apples to apples.

My question is about the security of Point-to-Point wireless. Could you help me gather some security criteria to help to decide what technology would suit the best for this scenario?

I am trying to not be biased towards any brands but instead focusing on the security elements.

In short: wireless means data travel through the air and can thus easily be sniffed. This means you need some protection against sniffing and this is commonly done using encryption. There are established encryption methods for wireless networks (see Wikipedia:Wi-Fi Protected Access
 for details). If these are not implemented or not deemed sufficient it is also possible to run a VPN like IPSec on top of the wireless connection.

Another issue to look out for is that the devices by themselves don't have any backdoors or security problem which might be used as a backdoor. Because otherwise some attacker might reconfigure the device or get access to the encryption keys and thus can decrypt sniffed data. Running a VPN on top of the wireless connection and independently from the devices providing the connection can mitigate this issue since it is now not enough to crack the encryption of the wireless layer.


Full disk encryption vs home folder encryption - why should the former be chosen over the latter Niebezpiecznik.pl, a popular and acclaimed infosec blog in my country, recommends full disk encryption (emphasis original) to all people (ie. "Average Joes"). They warn that in the opposite scenario device theft is likely to have catastrophic consequences.

I'm interested, however, why full disk encryption and not home folder encryption. (By home folder I also mean its Windows equivalent, that is, C:\Users\username\).

All personal data thieves might find interesting for frauds, blackmails, etc, is likely to reside in the home folder. Access to other folders can only give thieves the oh-so-important list of installed programs; so thieves will learn that the person was using Firefox or Google Chrome; Libre Office or Ms Office; maybe they will also learn the person was indulging themselves in certain video games. Other programs that are likely to be installed (Photoshop in case of graphic designers, programing IDEs in case of programmers, etc) will give them equally useless pieces of information.

Even in Windows, since Vista or 7 (I don't recall), badly written programs which would store user data in Program Files, have their write access silently redirected to Virtual Store (which resides in C:\Users\username\). Therefore I fail to see how could any personal information get leaked outside of the home folder.

The page I linked to doesn't provide rationale for full disk encryption as opposed to the home folder encryption. Therefore, may I ask if this is the general recommendation and why (not)? What threats can be mitigated by full disk encryption that home folder encryption would fail to mitigate? (Evil Maid is one of such threats, but I'm not sure if that's anything an Average Joe would have to worry about.)

I recommend Full Disk Encryption everywhere. Home folder encryption will cover a lot, but there are a few points missing:

Data outside of home

Some programs will write things on /tmp, log files are going to /var/log, swap will contain sensitive data. Those directories are outside of your home, and will not be protected.
Protection against tampering

I think this is the most important. If your computer breaks down for any reason, and you must send it to repairs, your home is protected, your system isn't. It will be trivial to replace binaries, or put backdoors in place.
Protect login password, WiFi passwords, and databases

The same support technician  can copy /etc/shadow, all data from NetworkManager, anything on /var/lib/mysql, and so on. With full disk encryption, nothing can be copied.


Look over my Web API Authentication Scheme I want some advice on my Authorization/Authentication scheme that I will be using for my Web API that I am writing.

Firstly the Authentication :

1) When a user first logs in and they are authorized, I send back a unique token back to the client.  This token is used in subsequent API requests in order to authenticate the user.

I plan to store this unique token in the users database row and remove it from the database on log out, time out, etc.
I was planning to create the token in the format "user/user's IP/timestamp"
When the user sends back the token, I will parse out the IP and compare it to the current requester's IP, if that passes I will look up the token in the database and compare the database's token and the client's token.

The part I need help on is the type of encryption to use in creating the token.  I was planning to use RSA but the token came out to be like 50+ characters which seems obsessive.  What is a better encryption to use so that the token isn't too long?

Other things to note is that I will be using SSL to login, register a user, but not to request data so the request will be open text.

2) Secondly is the authorization of the user.

When the user first registers, I salt their password with a salt generated from BCrypt and hash that password.
I save the salt and the hashed password in the database.
When a user wants to log in, I add the hash to the new password and compare it to the hashed password in the database.

Is this a good form of authorization?

Thanks for any help you can provide.

First things first: you are not using the correct terminology. This may be problematic if you are looking for documentation.

What you call "authorization" is what the rest of the world calls "authentication". What you call "authentication" is what the rest of the world calls "session management".

Authentication is about making sure that whoever is at the other end of the line really is who he claims to be. Session management is about extending authentication over several successive requests, which collectively constitute a session. Authorization is about deciding what a specific, duly authenticated user should be allowed to see and do.

When using passwords, authentication is defined as follows: a user U will be deemed "authenticated" if he can demonstrate knowledge of a password that only user U knows. This calls for two important comments:

Use SSL. The "show the password" authentication method implies, really, showing the password. The client should show it only to the proper server (yours), not to a fake server, and certainly not to the world at large. SSL will provide the necessary server authentication (that's what the server's certificate is about) and encryption. Also, SSL will bind the authentication with whatever is afterwards sent over the link, in particular your token. You won't get any decent security without something similar to SSL, and that's hard to implement and run correctly (especially in a Web context), so use SSL.
Don't store passwords themselves. The server does not need to store the password, but only enough to be able to verify a given password. This is where bcrypt is used: you store a password hash on the server. The idea is that if an attacker succeeds in having a look at your database, he won't get all the passwords in one go. That's a second line of defence.

Password hashing has a lot of theory and involves some configurable slowness and salts. The good news is that bcrypt is a good solution, and most bcrypt implementations already manage the salt. That is, when a salt must be generated, the bcrypt implementation generates one internally and properly; and the salt is encoded in the output. This means that the bcrypt output is a string that you just have to store and read back. See this answer for some details. You should not have to muck with salts directly.

For session management, you want to give to the client, after successful authentication, some fast way to tell to the server that it's him again. Sending back a session token is the normal way of ding that.

The token is a secret key: it is a value whose only important characteristic is that the correct user knows it, but not any other. As such, a good token is a random sequence of bits (128 are enough) generated with a cryptographically secure PRNG. You might want to encode that token into characters with, e.g., Base64, so that it better fits text-based protocols and systems (like Javascript); it does not matter.

Other characteristics are merely extra safety tricks:

You may want to restrict the validity of the token in time, so as to force a new authentication regularly or after a given inactivity period. For this, the server must somehow remember the time at which the token was issued or last used.
You may want to restrict the token to a given IP address, on the basis that... what exactly ? If you do things properly, then if the token is stolen, then the attacker has enough control on the victim's machine that he may launch the fake commands from the victim's machine itself. On the other hand, normal users may sometimes switch IP addresses (there are ISP who provide dynamic IP addresses and change them occasionally; a user may have a laptop and use the WiFi from whatever restaurant he currently sits in). In any case, if you want to restrict a given session token to a specific IP address, then the server must somehow remember the said IP address.

In both case, the server must remember. On the server side, whenever a session token is created, the server must be able to map back that token value to the proper user identity. So there should be on the server a table, indexed by session token, which points back to the "session data", in particular the user name. An issuance timestamp is handy here to allow an obsolescence policy, in order to prevent that table from growing indefinitely (entries for old, expired tokens can then be removed automatically).

If you have millions of clients then you may want to offload such storage on the client itself. This is a size optimization. Now (and only now) would you envision a special "token format" which encodes some data that your server would like to remember about the session, but cannot or will not actually store in its database. The generic scheme is the following: for a given session, there is some data D which contains everything that the server wants to remember about the session. This includes the user name, the time of issuance or last use, possibly the client's IP address if you really wish to put restrictions at that level... then the token value is an encoding of D || M (concatenation of D and M) where M is a Message Authentication Code (in practice, HMAC) computed over D with a secret key K that the server stores.

The server uses K to generate the token (i.e. compute M). The server also uses K to validate an incoming token. Such a token can be seen like a sort of ID card: after successful authentication, the server grants to the client a temporary ID card, which can be verified by whoever knows the MAC key, i.e. the server itself, without having to maintain some knowledge of all issued cards. From the point of view of the server, things go the following way: if a client connects and sends a token T, then the server validates the MAC part of T, and if that matches, then server knows that T was issued by itself, and its contents are therefore trustworthy.

This scheme has some consequences:

Since the client does the storage, the server can manage millions of simultaneous sessions without having to pay the storage cost for it.
There is no easy way to enforce an early session close. As long as a client remembers a given token T, and the expiry date (encoded in the D-part of T) is still in the future, then the client can connect back and will be considered authenticated. If you want to be able to force-evict sessions (e.g. as an administrative action) then you will have to maintain some sort of revocation list (a list of seemingly-valid tokens that you decide not to accept nonetheless). Alternatively, by changing the key K on the server, you cancel all existing tokens simultaneously.
The client will see D. If you just want to store the user name, his IP address and his date of last authentication, this is not a problem: the user already knows all that. However, generically, if you want to store user-dependent data in the user token D that the user should not be able to see, then you will have to use encryption (which complements but does not replace the MAC).
You cannot prevent a user from doing a rollback. If a client connects and sends T1 with data D1, and the server sends back a token T2 with data D2, to be used for subsequent requests, the server has no real way to prevent the client from sending back T1 again. This is unavoidable if the server has a "no user-specific memory" stance.
You have a secret key K to manage on the server. Secret keys for HMAC are easy enough to generate (just get 16 bytes from your CSPRNG) but you have to store that key (so that the server does not forget it when it reboots); if the server has several front-ends then all of them must know the same key K; that key K is very valuable to attackers since knowing K allows impersonating every user, so K would have to be well protected (simply storing it in the database would make it an easy prey to basic SQL injection attacks).

Summary: unless you have clear performance issues which require client-side storage of session data, I recommend that you refrain from using a MAC-based kind of scheme. Don't encode user data in the token. Do this:

When a user logs in (the client shows the user name and password, and the password verification with the stored bcrypt value succeeds), generate a new token T as a sequence of 16 bytes (128 bits) obtained from a CSPRNG (/dev/urandom, java.security.SecureRandom, System.Security.RNGCryptoServiceProvider... depending on the OS and language). The server creates a new row in the "session table" which maps T to the user data (name, date of last use, IP address...). T is sent back to the client.
When a user connects and sends a token T, look it up in the session table to recover the user data. It is sufficient that the client knows T to consider the user as duly authenticated.
Prune expired rows from the session table at regular intervals.
And do everything above within SSL.


Is there any reason to use AesManaged over DPAPI in this scenario? I have a situation where my web application is going to be deployed on multiple web servers, and I'll be wanting to store some securely encrypted data on the DB servers (each web server has a DB server paired with it).

Now, what I was thinking of doing was implementing Encrypt and Decrypt library functions that utilize the AesManaged class.  These would use an AES key that would be different for each server (we would generate a new one for each server on deployment) - that way, each server would be using a different key.  We would then use SectionInformation.ProtectSection() to encrypt them in Web.config, so they were secure.

However, I've come accross the ProtectedData class.  This hooks into the Windows DPAPI functionality and allows symmetric encryption and decryption.  Now I'm wondering, is there any point in my using AesManaged with my own generated keys at all, or should I just encrypt and decrypt data using ProtectedData?  What are the pros and cons of each?

This is probably a little late but just as a recommendation for other people who stumble on this. For this type of problem I would always use ProtectedData over rolling your own implementation with AesManaged for two reasons. First, you don't need to deal with managing cryptographic keys with ProtectedData which is a hassle to do correctly. Second, there's a handful of security considerations that a developer needs to understand before hand-rolling their own crypto and even then there's a chance the developer could make a mistake and render the crypto useless. Why take the chance and risk a headache when a perfectly acceptable, already vetted, solution is already available?


How to configure F5 load balancer and backend server both with SSL Certs I have an F5 load balancer and a backend server. Load balancer is www.example.com. Backend server is server1.example.com. I have the F5 load balancer with SSL Profile (client) and SSL Profile (server) enabled and SSL certs on the load balancer and backend server. So it looks like this:

  Client (laptop) --> HTTPS/SSL --> F5 Load Balancer (www.example.com) --> HTTPS/SSL
  --> Backend server (server1.example.com)

The backend server is running Windows 2012/IIS 8.5. In the bindings, the Host Name field is blank.

I expected a request to www.example.com to fail because the backend server SSL Cert is for server1.example.com. It actually succeeds. I don't understand why it works.

If I set the Host Name in the IIS bindings to server1.example.com, the request does fail. If i leave it blank or set it to www.example.com, the request succeeds. Not sure why. Doesn't make sense.

I understand the F5 LB is acting as the client in the handshake between itself and the backend server. But my understanding is the F5 is sending a request for www.example.com (host name) to the backend server. The backend SSL cert is for server1.example.com. Therefore, the request should fail because the host name being sent by the F5 does not match the host name associated with the backend server SSL cert. That is, www.example.com != server1.example.com.

Please tell me where I am wrong in my logic because I obviously am. I just don't understand why it works.

Thank you.

I understand the F5 LB is acting as the client in the handshake between itself and the backend server. But my understanding is the F5 is sending a request for www.example.com (host name) to the backend server. The backend SSL cert is for server1.example.com. Therefore, the request should fail because the host name being sent by the F5 does not match the host name associated with the backend server SSL cert. That is, www.example.com != server1.example.com.

I am not sure what you mean by "the request should fail."  What agent would fail it?  The server does not validate the SSL cert against the host name; the client (in this case, the LB) does.

Because it is the LB that is responsible for validating the cert, it can intelligently figure out what is going on and validate against the correct host name rather than the host name of the individual server node.

So here is approximately what happens:

Browser looks up the IP address associated with www.example.com
Browser establishes a TCP/IP connection to the address
Browser establishes a TLS connection over TCP/IP, thereby retrieving the cert from the LB (www.example.com)
Browser validates the Subject of the cert against the domain name submitted in step #1 above; if they don't match, you get a phishing warning
Browser sends HTTP payload over TCP/IP+TLS to load balancer.  This payload includes an HTTP header "Host: www.example.com"
LB evaluates load balancing rules and picks a back end server to which to direct the request.  The output of this is either a server name or IP address, depending on how you have this set up.

If it is a host name, it is used only for IP lookup; it is discarded immediately afterwards, because the name of the server node doesn't mean anything to the system overall.
If it is an IP address, the LB will just use that.  Notice that in this setup, the LB never even learns that the name of the back end server is server1.example.com; in fact it has no idea what its name is.

LB establishes TCP/IP connection to back end server
LB establishes TLS connection to back end server, thereby retrieving the cert from the back end server (www.example.com)
LB validates the subject of the back end cert against the host header provided by the original client, in step 5 (www.example.com)
LB re-encrypts the HTTP payload and submits to back end server.  It includes the HTTP header "Host: www.example.com" and may also include additional headers such as x-forwarded-for.

You should never have a host header that says server1.example.com, nor will that host name ever be used for validation of the SSL certificate.


Can you get someone's IP if you have their Skype number? I was reading about capturing packets during skype sessions to get the other person's IP address... sounds like you can do this mainly while in a live skype chat / call between skype to skype, but
Is it possible to get the other person's IP by just ringing their Skype number even if they don't pick up your call? (By skype number I mean the online number you can purchase from skype, not the skype ID.)
And do you basically just need internet and a capturing software for that?

Skype is a modified P2P network.
 You have no guarantee that your traffic is going to them, so a sniffer wouldn't work the way you'd expect. However, you can resolve the person's username to their ip address with a tool like this while they are online. So if you can get their username from the Skype number, or the email address associated with the number (to then get the skype username), you'd be able to resolve it to an ip address.


What can I do to improve my Keepass XC setup? I'm planning on using KeePass XC for the first time and am trying to create a setup that:

(1) would prevent hackers from stealing my passwords

(2) would prevent me from losing access to my passwords

My password management setup is written below. Currently, my weakest point of attack is if someone steals my USB.

I use Keepass XC.
I use TOTP 2FA via Keepass XC.
I make backups in 2 separate USB drives.
I have the Keepass database stored on my computer and access it using a keyfile stored on my USB.

USB x2 (What I store in my USB)

db
db keyfile
db master pw
export file of all account credentials and totp codes in my keepass database

Full disclosure is more opinion than fact: (I used KeyPass/XC for a few years, but switch to a different service due to sync difficulty)

Your risk tolerance is really based on your own comfort level and personal threat level.  If you are a high-value target this conversation would be different.

In General, having 2 or more backups is good, BUT all in the same space is bad. Off-site backups are important, but then you need to trust the offsite location. Second is the need to sync, a backup database that out of date is not too helpful. So syncing will be an issue and difficult if the off-site copy is in a bank vault for example.

Assuming Windows pc with a not high-value target, modist risk.
I would recommend:

Store one of the vaults in a trusted/one you comfortable with cloud storage  (this solves the offsite need).
Keep the master password and key file (if applicable) out of the cloud storage. (cloud storage user cannot decrypt if storage is not the key file isn't accessible.) Alternatively, there is a phone app option.
keep another DB/key file on a USB stick ( the master password stay separate)

this allows you to have the password on go (if stolen/lost they still need master password).  If really paranoid, you can get a pin protected USB, but that more to remember.

You may not want to store the totp data with the keypassxc database. Save in a phone app like authy?
Building off of another question increasing iteration and using a strong master password will make brute force harder, though slow down the app.
As for the sync issue, I did it manually, there is a feature called keeshare, that offers sync options, however I could only find docs in the beta page, so it's functionally/stability may be limited.
Finally, there is no perfect security, it all about trade-off and risks


git reflog is showing plain text password used as a secret texts or files in Jenkins We are using Jenkins Freestyle Project to push the changes on the remote server. We are executing shell script on remote host using ssh for it. To pull the changes on the remote server, we are using origin url with git username and git password. The credentials should not be visible in plain text in the url that's why we have stored them in variables using 'secret text(s) or file(s)' option of 'Build Environment'.
The git credentials are not visible to the users who are using Jenkins for other projects but the remote server is showing git credentials in plain text. Any user with ssh access of the remote server is able to run the git reflog command in the project directory.
Port 22 cannot be opened on the server where gitlab is deployed so we cannot use ssh keys method to create the build in Jenkins. We can use only http method to pull the changes.
Is there any way so we could implement to avoid showing the git credentials in plain text in the project directory.

You can turn off saving reflogs by setting the following option in the remote git repository:
[core]
  logAllRefUpdates = 0

Note, that this is usually off by default, so the fact that your reflogs are saved means that somewhere it's been turned on.
Then you can delete the logs directory in the git repository where these logs are stored.


How I can prove that SSH attacks are not from my application? My ruby on rails web application is hosted on Linode. Linode opened a ticket and blamed my Linode server for attacking other servers. The logs revealed that it's a SSH brute force attack which originated from my server. I have studied my source code, checked if there is any malicious script on my server but I found none.

How can I prove that attack is not originating from my end?
If however the attack is originating from my end, how can I detect which process is responsible for the attack?

My web application is running on Ubuntu 12.04.

Linode uses Xen, which means that you not only have an app; you have a whole operating system, complete with kernel and base libraries. The attack comes from your system, so it is completely in your jurisdiction. The attacker entered your system in some way, but once there, if he is at least half competent, he used a rootkit to transform his break-in into a permanent installation. The downside of it is that a rootkitted system will not show up from the inside of the system: the kernel would have been infected and will not show the attack process from the attackers.

(I am using here the assumption that once the attacker entered, he could escalate his rights into root level -- that's the prudent assumption, because operating systems are rarely rock solid against local attackers.)

This implies that your system should be wiped out and reinstalled from scratch; it has been compromised and can no longer be trusted. At that point, you would have two goals:

Understand how the attacker came in, so that he won't do it again on the newly reinstalled system.
Convince the Linode people that you are a victim, not an accomplice.

For the first point, this is a matter of analysis of all the logs and other traces that can be found in your system. So before scraping it, take a full copy of it (preferably, a byte-by-byte copy of its virtual hard disk) for ulterior analysis. But remember that if the attacker is reasonably good, he covered his tracks (that's what rootkits are for). Also, some auditing of your application code would be in order: the attacker entered in some way through one of the externally accessible services of your server, which includes your application. Another possibility is that the attacker guessed your SSH account password (after all, you know that this attacker does run brute-force attacks on SSH logins): on your new system, use a new, bigger, more random password (don't type it on your current system ! It is compromised, thus possibly grabbing password changes on-the-fly).

For the second point, this is a matter of trust and human relationships. You cannot prove that you are not the attacker; but the Linode people know that hijacked systems are an unfortunately common reality. Just exercise due diligence, such as reinstalling the system from scratch: going through that tedious task will go a long way towards establishing your good faith in that matter.


secure webmail provider Which email providers (e.g. Gmail, Yahoo, etc) offer the most robust security for a personal email account?  The recent article about Mat Honan getting hacked illustrates the challenge.  The account owner is responsible for some aspects (e.g. choose a strong password, partition your information by avoiding daisy-chaining), but the service provider also has responsibilities (e.g. verify identity of people calling support, provide robust authentication).

GMail offers two-factor authentication, and Yahoo has the same feature in beta (as of August 2012).  Are there other aspects to consider?

UPDATE: I accepted the answer below.  The discussion has reminded me to consider the people and process involved, not just the technology.

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

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

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

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


What defines a programming language as useful for hacking? I know that scripting languages (Perl, Ruby, Python, javascript, and even Lua!!!) are most suitable for hacking and penetration testing.

My question is: What is it that makes those languages suitable? From what I know, they are slower than other languages, and operate at a higher abstraction level, which means they are too far from the hardware. The only reason I could think is because of their advanced string manipulation capabilities, but I believe that other languages have such capabilities.

Languages are useful for doing things. What type of things it's suitable for completely depends on the type of language, the frameworks available for it, what OSes have interpreters / compilers for it, etc.

Let's look at the ones you've mentioned:

Perl

Scripting language
General purpose
Available on most *nix OSes since the '90s.
Great for quick hacks and short scripts.

Ruby

Scripting language
General purpose
Cross-platform
Object-oriented
Reflective (can see its own structure and code)
Good for dynamic frameworks

Python

Scripting language
General purpose
Cross-platform
Designed for clear and readable source code
Huge framework of libraries

JavaScript

Scripting language
Web-based
Cross-platform (available on every major browser)

So what makes these particularly good for pentesting? Well, most pentesting involves writing up quick throw-away tools to do a specific job for a specific test. Writing such a tool in C or C++ every time you want to do a quick job is cumbersome and time-consuming. Furthermore, they tend to produce platform-specific binaries or source that requires platform-specific compilation, rather than cross-platform scripts that just run. Scripting languages give you the flexibility to produce such tools quickly and easily.

For example, Ruby and Python are popular for more complex tasks because they have comprehensive libraries, whereas Perl is popular for quick data processing hacks. JavaScript is commonly utilised as a simple browser-based language that everyone has access to. Other languages such as C tend to be used for more low-level tasks that interface with the OS.

Now, the other side of the coin is languages used as payloads. This is where the line gets blurred, because requirements are so varied. For attacking Windows boxes, any payload that has no dependencies outside of what the OS provides is useful. This might be C, C++, VBScript, x86 asm, C# / VB.NET (.NET 2.0 is on most machines these days), etc. For attacking Linux boxes you might use C, C++, bash scripts or Perl. Java is also common for cross-platform attacks.

At the end of the day, pick the language that you find best for the job!


Multiple login attempts made using mobile OTP in multiple customer sites at the same time We have multiple customer sites which provides login via mobile number OTP option (new & registered users). Recently, we come across an incident where a user received 100+ OTPs with in few minutes to login to 10+ different websites multiple times. Attempts made on few unfamiliar websites as well.

Which type of attack this is ? and how it is possible ?
How to understand whether those OTP were used for login & collect information ? or just to create cyber fear ? (Not all customer sites are providing new device login notification like social networking sites)
How we can prevent this? (No restrictions on the sites and mobile number can't be kept as secret)

1.Which type of attack this is ? and how it is possible ?
Attack could be a dictionary attack or Brute-force guessing attack. There are many scripts available publicly to perform those kind of attacks. Even an expert can develop their own script as well. In addition to that botnet attack also possible.
2.How to understand whether those OTP were used for login & collect information ?
It is only possible if you have setup proper logs and monitoring solution. OTP in mainly two types. Synchronous and asynchronous. Synchronous OTPs are not working after specific time period and asynchronous OTPs are available until it use. But according to your scenario, synchronous should be used and If logs and monitoring are not enabled, unable to check whether those are used or not.
3.How we can prevent this?
You need to enable firewall/IPS and especially Input validation and clipping levels for failure login attempts. Monitoring is required at any situation, Otherwise you don't have visibility on what is going on with network.


Disable USB keyboard pluggability on MacBook I'm concerned about USB devices being physically attached to my MacBook laptop when I am about to unlock my computer or while my computer is unlocked.

My threat model involves an attacker who is willing to spend about $200 to gain access to my laptop, in particular my own user account or root. So, sophisticated physical attacks such as complicated hardware modifications or physical laptop replacement are not possible.

But I'd like to be able to:

Leave my computer unattended but locked for a few minutes while I use the bathroom at a coffee shop.
Plug-in external USB storage devices without having to boot into an isolated VM or use a guest user account. Be able to charge my phone from the USB port using an untrusted cable and still be able to use my computer from my user account at the same time. Be able to use untrusted external monitors through USB.
Avoid having to physically touch my USB ports to make sure nothing nefarious is connected before I type login.

The attack I'm worried about is obviously BadUSB or customly designed USB devices that can act like keyboards (and can be produced for less than $200). These devices could be plugged in while I leave my laptop unattended, and can possibly be too tiny (think ubikey size) to be immediately noticed. Or they could be plugged in by a person sitting next to me when I show them something on my screen.

I already employ basic opsec practices, including FDE, a firmware password, a user account password that changes often, always locking my computer when I am away, no password reuse, running only binaries I trust etc.

The solution I am thinking of would be along the lines of having to "authorize" new USB devices when they are plugged in; and I should be able to view their type (e.g. keyboard VS camera VS microphone VS charging cable VS storage device). If I authorize a USB device and it is unplugged and re-plugged, I should be given the option to re-authorize it or to unauthorize it, and it shouldn't be able to act until I make the decision. And if a device tries to re-register as a different type, it should be blocked until authorized.

Do you know of a system that allows me to do that? Thanks!

I guess you only want to use one USB port at a time (you could use a hub to this port in the few cases you need more ports) and you intend to keep this macbook until its out of service. (eg, it does not matter if some USB ports gets destroyed).

Then I would suggest filling all USB ports except one with Expoxy glue. The port you select to be open would ideally be easly visible or accessible so you can later detect tampering to this open USB port.

Then you use a USB lock. Theres numerious USB locks available out there, some has a "general" key that will fit all USB locks, other have a color-coded key that will only fit USB locks of the same color, and other have a completely unique key.

If you want, you could buy one of those laptop Cable locks with a key and a USB "tounge" that locks into the USB port, and then modify the device to remove the locking Cable, leaving only the "lock". Thus you lock the "lock" into your open USB port, and then it cannot be removed without the key or using force, and using force would also destroy the USB port and leave telltale evidence that manipulatiion has been in effect.

If you very rarely use your USB ports, only occassionally, you could even use one of those serially numbered "USB seals", which is a Little plastic device that you put into the open USB port (that you select not to expoxy), and stucks permanently. To remove the seal, the seal has to been destroyed, and then the plastic seal cannot be reused. Every seal then have a serial number, that you check against a secure source (for example, a paper in your wallet that you wear on yourself at all time) when you want to "go secure".


How to restrict user access mobile data when mobile is connected to laptop? When a user connects his mobile phone to a laptop in our organisation, his complete mobile data can be accessed from laptop. How do we control this and restrict the user from accessing mobile data when the phone is connected to laptop by USB?

I assume you mean data tethering from the phone to the laptop.

If it is pure USB, you can force an USB blocking policy via GPO. Blocking WiFi tethering will be much more difficult, unless you restrict the laptopts to certain WiFi points only. The second option will not make you popular, but it will prevent the user from accessing information over a mobile network

Instructions on Group Policies

USB tethering is managed over the MTP, which on Windows is the same as a WDP Device.

Open the Group Policy Editor
Go to either computer or user settings.
Administrative Templates \ System \ Removable Storage Access
WDP Devices, then disable Read and Write access.


How do you handle log analysis? How do you handle log analysis in your business?

I want to establish a good way of finding exceptions and alerts in the server logs, either automatically or semi automatic (having to review exceptions and alerts).

Is this functionality that is usually handled by an IDS/IPS?

Right now I am collecting all log data from web servers, databases, syslog and such into Splunk, and I'm considering to make Splunk dashboards which presents me weird and non-normal log entries. Is this the right way to go?

OSSEC is a great FOSS HIDS that works well to reduce the number of log events you need to check out to something potentially manageable.

It supports all of the log sources you mentioned:  http://www.ossec.net/main/supported-systems

We built an in-house app that allows us to do a quick “daily check” of all the alerts OSSEC fires in a day; it typically takes us less than 20 minutes of time to call out an all clear or to kick-off an incident investigation.  For one environment we receive ~70,000 OSSEC alerts per day, but most of the alerts/events are clusters of auth events or app errors spamming the logging system, for example:

Since you have Splunk going you could do the Splunk + OSSEC integration:
http://www.ossec.net/main/splunk-ossec-integration

The other day I saw a couple enterprise SIEMs in action – I was stunned to learn they apparently have no canned reports detailing unusual or rare log events.  Unusual and rare events are frequently the best indicators of something bad and can serve as your short list of events to chase down until the leads turn cold.

We also use Logwatch as a secondary log analyzer.


Security-by-design based on an existing framework or a custom design? Personally I do most of the development in PHP (the programming language doesn't really matter for this question). Popular PHP frameworks along developers are for example:

CodeIgniter
Laravel
Symfony

From this three frameworks, I know most about CodeIgniter and in general I think they supply developers with a good input library and pay extra attention to security. Also they have a security program in order for researchers to report vulnerabilities in the framework in order to fix those. Disclaimer: I'm also contributing to the CodeIgniter framework and their security program.

My general question is: is it better to rely on an existing framework for developing an application in order to extend a basic security-by-design structure. Or is it safer to start from scratch and develop everything yourself?

In other words: With security-by-design in mind, is it safer to start developing an application based on an existing application framework or to start from scratch with a custom build design?

Let alone that developers of course need to use the framework functions properly in order to benefit of them. The same applies on custom build functions/features.

If you were to start a framework from scratch, you would have to catalog and address a wide range of possible vulnerabilities - from input sanitation to cross-site exploits, from authentication (and hashing, salting, password recovery, possibly data encryption) to resource access control.

What I mean is, these are things you would need to do in abstract, before starting development. So what about doing them in the abstract, and then applying them to an existing framework?

This would have several advantages:

larger developer base. Given enough eyes, most bugs are shallow (even if events such as the SSL storm have tarnished that concept).
already-(largely)-audited code base.
a concrete, definite framework to which to apply the various security concepts and issues, short-circuiting the whole design-mock-build-test cycle.
larger creative base - however brilliant you may be, you plus the others will always think of more possibilities than you alone. When doing the laundry list of things to do and watch for, this will be an invaluable help.
the rest of the code is already there - you did focus on security, but the rest of the features and functionalities have been already developed.
also, the rest of the code will probably supply some requirements just by being there - things that the framework need to be able to do. What if you designed a splendid, tightly secured system which later turned out to be unable (or able only with great difficulty and patching) to perform some key feature that in the beginning had been overlooked?

You do have the disadvantage of not being able to design the whole framework from the ground up, which could spawn some issues of its own.

But at least to start, I'd begin with a thorough examination of the security approach in an existing framework. And you get a lot of good karma with your chosen framework's guys; from a career standpoint, it's much more likely that you'll meet some potential employer requiring expertise with a known framework.


smart card authentication process Smart cards (for instance, public transit cards) are widely used in some countries for authentication purposes at universities and workplaces, so that an authorized person can use a printer or access a room by just putting the card on a reader. How does this really work and is it enough safe to use a public transit card in such cases? Can a bank card be used in this case instead of a public transit card?

An example of dumb card is those used in hotels to replace physical keys. Or entry badges. These can be usually be cloned with equipment like a Proxmark, Proxmark pro or even an NFC-enabled smartphone. You can argue that they are less secure than physical keys, because someone who has portable equipment (that is readily available on the market and may already exist in your pocket) and comes close enough to the card could make a copy.

When it comes to contactless there are quite a few standards. Not all cards are the same in terms of design, cryptographic abilities and they do not all operate on the same frequency ranges.

Let me address this sentence:

  Smart cards (for instance, public transit cards) are widely used in
  some countries for authentication purposes at universities and
  workplaces, so that an authorized person can use a printer or access a
  room by just putting the card on a reader.

What you describe is not authentication but identification. Because you are not proving you are who you say you are (an authorized user), for example by providing a password in addition to the physical token. Anybody can 'borrow' your card to use the printer.

The difference can be explained in simple terms:

  Identification occurs when a user (or any subject) claims or professes an identity. This can be accomplished with a username, a
  process ID, a smart card, or anything else that can uniquely identify
  a subject...

  Authentication is the process of proving an identity and it occurs when subjects provide appropriate credentials to prove their identity.
  For example, when a user provides the correct password with a
  username, the password proves that the user is the owner of the
  username. In short, the authentication provides proof of a claimed
  identity.

Source: Identification, Authentication, and Authorization

For a more detailed discussion: Difference between authentication and identification [Crypto and Security perspective]

As to the question "Can a bank card be used in this case instead", the answer is yes probably but there are legal considerations that will probably not permit it. If my employer required the use of a bank card or chip identity card to access the printer or restroom, the data protection authority in my country would step in, because such a scheme is illegal.

In addition to the legal considerations, the liability aspect raised by
Schroeder above has to be considered too.


RFID protected wallet Is there something I can put behind my bus pass in my rfid protected wallet so that it will scan on the busses. At the moment I have to take it out to use it.

Since you have to take it out of your wallet for it to work, I'm going to assume that your bus pass uses an RFID.  In that case the answer is very straightforward:
No
If you have an RFID blocking wallet, then it won't let RFID's inside it work.  That's pretty much the point.  The only way to make your bus pass work while inside your wallet is to switch to a non-RFID blocking wallet (or remove whatever is inside the wallet that blocks RF waves).
In that case though it will no longer be an RFID blocking wallet.  It seems you're looking for an RFID blocking wallet that doesn't actually block RFIDs.  Such a thing doesn't exist.


Industry-accepted time sources PCI DSS requirement 10.4.3 asks to:

  Examine systems configurations to verify that the time server(s) accept time updates from specific, industry-accepted external sources (to prevent a malicious individual from changing the clock)...

Why are only external time sources acceptable? If I restrict access to the internal time source then where is the danger? I need to use an internal time source. Can you suggest ideas for compensating controls for this requirement?

This is no different from other aspects of network and system configuration. PCI is mostly concerned with separation of duties, so the sysadmin is not also the dba and is not also the developer, and with auditability, so that changes are recorded and approved and implementation matches policy. So sites can run internal NTP servers. Demonstrate that there is a formal policy for their use, that they are under sufficient custody to be accurate and reliable, that changes to their config go through change management, and that the hosts in PCI space cant be made not to use the approved internal source.


How secure is this schema between a Desktop App (c++) and an API (php) as title says I'm writing a paid Desktop App that automates some process, it indirectly requires internet connection because MY app automates another Desktop app that requires internet connection. There is no webpage or such, only my Desktop App and my API.

Normal Workflow:

User opens Desktop App: Login prompt shows on screen (it's a simple interface written in c++ that then posts to my API).
User presses the "Login" button: Data is sent via POST to my API.
API validates and verifies the data, then generates a JWT and sends it to the user.
User then uses the App all the time he/she wants: Every X seconds the JWT is sent to the API to see if it's still valid.
The user stops using the App: It might be because the App crashed, because he lost connection or because he closed it.

What I want to achieve:

I need it to be secure for the users and for me (by me I mean I don't want it to be easily pirated):

I'm using HTTPS.
I'm hashing the Password before sending it to my API.
I'm validating and verifying all the data.
I don't know how to make sure that this data comes from my Desktop App and was not modified in the middle by the user (like replacing an unique identifier with a simple string).

I want to prevent multiple clients logging in using the same account at the same time:

I don't want multiple Apps connected at the same time using the same account. I don't mind if an user uses the same account on different computers as long as he is not having more than 1 App connected at the same time.
When a user logs in with an account it will kill the rest of the "sessions" that this account had. (Like an online game where if you log in with an account that's already logged in, it will kick the user that was logged in preventing from 2 clients using the same account at the same time).

My schema:

Using JWT, when user "A" logs in it will generate a new JWT using his username and some kind of unique information like IP or computer information.

My Desktop App will verify and store this JWT in memory. Then every X seconds it will do a POST request sending the JWT to see if it's still valid.

If everything is okay then the App will continue to run normally.
If the token is not valid anymore or something is wrong it will log out.

Problems I found:

Let's say User "A" logs in and a JWT is then generated and sent to the Desktop App, how can the Desktop App tell that this JWT is valid and that is not a fake response the user is using so the App thinks it's logged in?.
What happens if user "A" logs in and then fakes responses every X seconds? I mean, how can I make this response unique? Is it a good fix to generate a new JWT everytime it performs this check?
Let's say I make it unique using some kind of unique identifier for each client (like IP, computer information, etc.), what if the user intercepts the information and replaces it with something simple like "hello world" so then all clients can use the same account and have a valid token at the same time. How do I prevent user from being able to intercept the data sent?

So my questions are:

How do I fix those problems.
Is it a good schema? I mean is it secure (to prevent piracy)? (I know nothing is 100% secure, but I don't want to make an authentication system that can be easily broken or with no security at all).
Is JWT a good choice here? Are there alternatives that are "better" or "different"?
Do you see any other problems, flaws, bugs, etc.?
Do you have another schema or idea to achieve this?

Thanks in advance.

P.S.: I'm not taking into account what happens if the user reverses my Desktop App because that's another topic and in that case nothing here is important.

Problem 0: You don't need to send the hash of the password, because you're already using TLS (HTTPS).  If you do send the hash, then the hash becomes the password.

Problem 1: Preventing users from generating a fake JWT response.

You're already using TLS.  Pin your server's certificate.  That is, include the server's public key in your app. If anything answers with a certificate that doesn't match the public key, then the app isn't connecting directly to your server.

Problem 2: Preventing replays of a valid JWT response.

Use a new nonce each time.  (Also, every few seconds? If their connection to the internet needs to be reset, and they don't need to access resources on a server to do work in your app, only to make sure that their session hasn't been revoked, then give them a few minutes.)

Problem 3: Keeping different computers uniquely identified.

You're using TLS, so they can't change the bytes on the network.  Simply produce a random nonce when the user logs in, identifying that session. Don't store it on disk, keep it in memory.  They would have to crack your app to change that, which you've already said is beyond the scope of this question.


Secure way to establish PHP database connections I've read the advice (example: store them in php file in a location inaccessible as a URL) but can't help thinking there must be a better way of storing/accessing database credentials.

Ideally it would be impossible for someone with access to the webserver files to obtain the database credentials. This leaves the challenge of how the webserver gets a database connection...

If there was a way to pass a PDO connection object between two unrelated scripts, it might be possible.

e.g.

main website script, running as www-data needs a db connection
somehow makes a call to a php function that exists in a file that is unreadable by www-data.
that function decides whether the script should be allowed to access the database (e.g. uses a debug backtrace, creates md5sums (or similar) of all the files mentioned, compares them against protected, known-good, ones) and if it passes this test, establishes a connection and returns the PDO object.
main web script is able to use the PDO object, but cannot extract the credentials.

Is there a way to create a PHP library that is loaded before, but outside of the main script execution? e.g. add to stock libs? This would make this sort of thing possible.

Or is there a better way?

If your attack model allows "attackers to upload their own scripts", then they have access to everything those same script can see or do, and "secure access to database", for this value of secure, is simply not possible.

(Short of redesigning the database so that it can run a check on all PHP files involved in a given connection - while theoretically possible, it would be exceedingly difficult - just think what it means to identify the PHP scripts, included by a Web process, that opened a connection, of which the DB server only knows the source address and port! - and very likely a performance killer)

But at this point you can move some logic away from the webserver, taken as unreliable, and see what security can be found elsewhere.

For example, you can make it so the different web application access levels use different credentials - you might have three database users "guest", "user" and "admin". You can organize things so that, for example, user administration by the user admin is not done on the same web server (you can separate it by process user, on a different webroot, another VM, or a physically separated web server).

Most functions and queries you can replicate using high-privileged procedures and functions that can access underlying data to which the web users have no access: for example you can do login checks with a function:

DELIMITER //
CREATE FUNCTION is_valid_user(user varchar(32), pass varchar(32))
returns BOOLEAN
DETERMINISTIC SQL SECURITY DEFINER
BEGIN
DECLARE ret BOOLEAN;
SELECT 1 = COUNT(*) INTO ret FROM users WHERE user = username AND MD5(pass) = password;
RETURN ret;
END//
DELIMITER ;

The Web application as user web has EXECUTE privilege, but has no SELECT/INSERT/DELETE privileges on the users table. So it can't enumerate users, or reset all the passwords in one fell swoop,

It is even possible (but not very useful, since ability to upload executable scripts makes an almost ideal man-in-the-middle scenario) to use the guest account to retrieve the web access credentials, stored in the users table, provided that the Web user has the correct password:

user John logs in with password 'Doe'. Web application is running as guest
the function get_credentials('John','Doe') returns 'web:myfirstpass'
Web application switches credentials to web, and has now access to more features

All data logging is INSERT only (only the admin can delete log records), and access to important/"financial" data (e.g. an invoice table) can be done by running all ops on a temporary table owned by web, while a privileged procedure can be used to finalize and validate the table, and copy it into invoices.

With a bit more work, the user can be associated with a highly random 'security identifier' string that is unique to him. Only by supplying that security identifier can he access procedures that retrieve invoices; and those procedures will only select invoices with that same identifier.

This way - a very labor-intensive way, admittedly - an attacker can only access the data of those users that log in, and are tricked out of their credentials, on the compromised web server.

You're left with the problem of quickly reacting to such a compromise.

On a Linux server with inotify, it would be possible to continuously monitor files and remove those that are not "approved" (i.e. their SHA1 hash is not in the "allowed" list). Any modification or addition to monitored files would trigger their removal as well as an alert being sent to the administrator:

inotify: '/srv/www/padma/htdocs/ CREATE dfqjkw.php'
inotify: '/srv/www/padma/htdocs/ MODIFY dfqjkw.php'
inotify: '/srv/www/padma/htdocs/ CLOSE_WRITE,CLOSE dfqjkw.php'
ANOMALY: '/srv/www/padma/htdocs/dfqjkw.php' (SHA: e0a6bf9020320dca178cf115da4fa26de0278a25cf41702d667988877cdbc2d1) is neither known nor in testing
inotify: '/srv/www/padma/htdocs/ DELETE dfqjkw.php'
ACTIONS: '/srv/www/padma/htdocs/dfqjkw.php' targzipped, sent to root, and removed

This would also require a pretty bit of tweaking for people uploading their web sites - you'd need a "test" FTP web site where the upload takes place, and an "approval" procedure by which each file's signature is extracted and the web site is copied onto the "production" filesystem, effectively doubling data usage.

On the other hand, stealing FTP credentials as many trojan malware does would be no longer useful: lacking the approval procedure, the compromised files would only be present on http://test.www.mysite.com, which would only be accessible from a few selected networks, not on http://www.mysite.com which is allowed to all.


security in the browsers - broad questions I'm working on security project in the browsing field but I am confused about some points.

What does "security in browsers" mean? Is it all about secure connections or there are other aspects?
How does the level of security differ from one browser to another?
Insecure connection: browser issue or network issue?

"Browser security" is about far more than secure connections. Using HTTPS to secure the connection between browser and server is an important part of browser security, but it's certainly not the whole thing. To show what I mean, here are some things off the top of my head (and by the way, I have never done any work related to browsers, these are just things I've heard about):

Javascript Sandboxing: So your browser is going to download and run arbitrary javascript code. What if this code is malicious? Can it read the user's personal files on the hard drive? Can it modify files on the hard drive to plant viruses? Can it read data from other tabs? Can it force the browser to do something malicious on its behalf? These are things you need to think about when designing a browser.
Browser extensions: Most major browsers have some system for people to add extensions written by other random people. Unlike javascript, once installed these are part of the browser and can not be effectively sandboxed. What security features exist around these? Do they have to be reviewed by a security team before being allowed on the app store? Will the browser monitor them and disable the extension if it breaks the rules?
Cross-Site Scripting (XSS): If I have two tabs open, can one tab get access to the cookies / session info for the other tab, allowing it to impersonate the other tab through GET / POST requests?
Media file exploits: Many browsers now include built-in media libraries for things like PDF, audio, video, etc. These are very complex media types with long lists of supported codecs. Libraries that parse them are notoriously buggy for things like buffer overflows that allow arbitrary code execution. How much security analysis have you done on the libraries that your browser compiles against?
Root Certificates: Most browsers now embed (aka "pin") the root SSL certificates into the source code of the browser. How fast will the browser issue a security patch if one of the root CAs is reported to have a breach?

Those are just examples off the top of my head. Bottom line: "Browser Security" is a HUGE topic.

To answer your other two questions:

  How does the level of security differ from one browser to another?

That depends on which browsers you are comparing. Firefox and Chrome? They are pretty similar. Firefox and the browser my friend wrote for fun last weekend? There's a pretty big difference. Everything else will be somewhere in the middle.

  Insecure connection: browser issue or network issue?

Yes. Also No.

Sometimes it's the browser's fault. Sometimes it's the network's fault. Sometimes it's the server's fault, or the OS's fault, or the user's fault, or the IT department's fault, or openssl's fault, or the VPN's fault ... the list goes on.

Actually, scratch that, a good security developer will write their code under the assumption that the other machines on the network are malicious (hopefully, including routers). So a faulty network should not be able to cause an insecure connection, but even if it can that doesn't mean it's the browser's fault: it could be any of those other things I mentioned.


Error on Content Security Policy while testing for Clickjacking I was recently testing for Clickjacking and when I opened developer tools, I was warning
Content Security Policy: Ignoring “'unsafe-inline'” within script-src or style-src: nonce-source or hash-source specified
Do you guys think it is possible to bypass it, If yes can you share me the further information?

Thank You.

This warning just means that a script was already explicitly trusted by nonce-source or hash-source and that the additional unsafe-inline makes no sense in this context - and thus will be ignored. The warning does not indicate that any bypass could be possible.


TPM 1.2 or Intel PTT While configuring a Lenovo Thinkpad T450s I stumbled across the option choosing how one would like to implement TPM.

It gives the options:

Hardware TPM chip with TPM 1.2 mode
Intel PPT with TPM 2.0 mode

Can somebody advise me which option is currently the more secure option? (To be used with Windows 10.) I believe I read some time ago that some TPM implementations are vulnerable.

TPM is supposed to be implemented in hardware, but the Intel chipset on the motherboard (Platform Controller Hub) which contains the Intel Management Engine has a TPM implemented in software running on the chipset (not on the CPU) which is secure as long the chipset and its firmware are secure.

There have been security problems in Intel ME firmware, but as long as you will get firmware updates from Lenovo for as long as you plan to use it, it's fine. You will be unable to install firmware fixes Intel makes available without Lenovo's help, so make sure they'll support that specific model for as long as you need. If they, for example, require you to buy extra years of warranty just to download updates, that's a ripoff.

The real hardware TPM chip can also have security issues, and you probably remember the ROCA vulnerability. In that case too, you needed support from the OEM to install a firmware update in the TPM chip, so I guess the "patchibility" of both options is about the same.

The security track record should be better for the hardware TPM, because that's their main business while the TPM in Intel ME (and the rest of Intel ME) is not Intel's main business, and we know they have not consulted their internal security people on most design decisions for decades and it's coming to bite them in the behind.

The hardware chip being only TPM 1.2 and not TPM 2.0 is kinda weird. TPM 2.0 is not a new standard (released 2014).

I think I would choose the hardware chip.


How does Logitech Options software automatically launch from a mouse dongle? I recently purchased a Logitech MX Master 2S mouse.  I had no intention of installing the "options software" that came with the mouse.  I simply desired a wireless mouse that wasn't cheap and flimsy.

However, after immediately plugging in the wireless USB dongle, some manner of custom software was able to run without my consent, displaying the following window above all other windows:

There is no USB volume listed in File Explorer, and to my knowledge autorun from USB is disabled.  I was also unable to find an obvious process listed in the Task Manager.

How did this process start?  Additionally this seems like an ideal attack vector for Windows machines.  Can anyone provide some insight as to how the USB dongle (with no volume) can do this?

Update:
There does not appear to be any built-in logical disk within the dongle, as running wmic logicaldisk get name and diskpart> list volume revealed no additional drives or partitions.

Nic Hartley mentioned drivers. Windows 10 automatically installs drivers for unknown devices as soon as they are plugged in. If Windows does not have the driver for the device, it silently downloads the drivers online. Event if Windows does have the drivers, it still checks online for an updated version.
So, my theory is: that Windows downloads and installs the necessary drivers from Logitech. The Logitech driver then shows the popup to install the software.

You can test this theory by plugging the dongle into a Windows 10 PC that is not connected to the Internet and does not have the Logitech drivers installed.

If the popup is still shown, then try disabling the Logitech drivers in Device Manager.

Also, try using a tool like Sysinternals Process Explorer to find the process that created the Window. More information.


Is there any way an attacker can access the server and modify the site (php) code? I recently had a breach on my site (laravel). I got aware of it after I tried to pull the code from github and found out that some files were modified.
The files modified were mostly storage - logs/cache and index.php had error_reporting(E_ALL) in it.
And I am not sure what happened and like to know if there's a way an attacker can access the server through the site and also what precautions I can take to mitigate these kinds of scenarios.
I researched a little bit and found out about these methods. Can anyone explain which method could possibly give access to an attacker to actually modify code files:
Cross Site Request Forgery - I dont understand much about how this works.
Cross Site Scripting - There are very less users using the site at this point and authorization & authentication is in place.
Local File Inclusion - Laravel uses namespaces and no such inclusions is made directly is it still a concern then?
Remote File Inclusion - Laravel uses namespaces and no such inclusions is made directly is it still a concern then?
Session Hijacking - PHP Sessions were not in use as it was a api based service and used jwt token
Session Identifier Acquirement - PHP Sessions were not in use as it was a api based service and used jwt token.
SQL Injection - All the db queries uses laravel eloquent so there might be no sql injection.

Via uploading a file and executing it. Review uploads, php enabled functions and use 'noexec' (in UNIX/Linux) mount option on filesystem. If your app must execute local binaries, create a regular job to review which binaries are available to the app. Think about using chroot or namespaces for PHP app.


Storing server-side secret key in environment variable - is a concern? Is it a security concern to store server-side key in plaintext in environment variables? And specifically with PHP, would I be safe by not calling phpinfo() or other kind of dumper?

Yes, storing credentials in plaintext is always a security concern.

Depending on what you use those credentials for (e.g. database access), you might want to look at alternative methods of authentication, which do not rely on a pre-shared key.

If you do not have any options other than storing a pre-shared key in plain text, then there are still some things you can do:

Authentication Proxy between you and the server

The concept is simple. You can set up a proxy server between your web server and your target, e.g. a database. You use a strong authentication mechanism that is independent of your web server to connect and authenticate to the proxy, which then adds credentials to each request to the database.

This way, the credentials are never accessible directly by the web server.

Cleaning up after yourself

Storing credentials in an environment variable can be done right and horribly wrong.

The wrong way is this:

export DB_CRED=user:pass
mywebserver <options...>

Why? Because this environment variable is now exported to every other process from the same shell.

The very wrong way is this:

export DB_CRED=user:pass
mywebserver --credentials $DB_CRED

This is even worse, because any user on the same system looking at the running processes will see mywebserver --credentials user:pass running.

So what is the right way? It is to launch your application like this:

DB_CRED=user:pass mywebserver <options...>

Further, you must then unset this environment variable, once it is saved in a variable of your application.

Why is this better than exporting? Because the variable DB_CRED is only set for mywebserver. If the web server then unsets the variable, it does not exist for the shell anymore, only for the process.


TRUSTWAVE pci network vulnerability scan FAIL We are a small business and we process credit cards through our desktop pc via the webpage myvirtualmerchant.com

And trustwave keeps scanning our pc and giving us a fail status. Below is the report showing why we fail the scan.

Can anyone tell me what to do to correct this problem.

Also, we use firefox as our web browser. Internet explorer has been uninstalled.

I can see that most of the findings are related to port 3389 which is for remote desktop. You have some issues related to SSL certificate you use for remote desktop. I will try to mentioned and give some guidance for solving some of them.

TLSv1.0 is supported the port support what seems to an obsolete
version of TLS, you need to reconfigure the service to not support
this protocol version, I haven't done this myself before but as described here, it seems that there is a patch for this.
SS/TLS weak encryption algorithm, you remote desktop service support
weak algorithms, for this one you need to set the encryption level
to high from terminal services snap-in type tscc.msc in run please
refer to this link if needed and this link as well.

For the rest, you can google the error messages and see which configuration you need to change in the terminal service configuration. I hope this helps a little. I would help with the rest as well if you struggle.


How to use another SSL certificate for DHE-RSA while I already have one with domain? I'm working in IOT team to build a web based IOT system.
I'm using Dataplicity's Wormhole to host my nodeJS app on raspberry pi. I want to use DHE-RSA symmetric key encryption channel for sending/receiving data from client to server and vice-versa.
In case of DHE-RSA server generate DH parameter and then sign them with SSL private key and send it to the client. But, here Dataplicity host my website on a subdomain which have SSL, So, i don't know the key pair. Can I use another SSL to for DHE-RSA.
If, yes and how to send the certificate to client. Because, SSL is attach with domain but here the domain is third party's. So, in this situation how to solve this?
Thanks in advance...

The root of the problem is that your pi web server is running behind a NAT firewall.  Therefore, it is impossible (without port forwarding) for outside users to connect to your pi web server through the firewall.
Dataplicity's solution solves this problem using a proxy server of sorts.  If you look at the diagram at https://docs.dataplicity.com/docs/how-it-works, your pi first connects to Dataplicity's server (the NAT firewall allows this, because it's an outgoing connection).  Then outside users connect to Dataplicity's server, which then forwards their requests to your pi web server, and forwards the responses from the pi web server back to the users.  But, because outside users are connecting to Dataplicity's server (at *.dataplicity.io), the certificate that they see is for *.dataplicity.io.  This also means that *.dataplicity.io is able to access (and modify) the plaintext of the requests and responses as the are relayed to and from your pi web server.  They are essentially a man-in-the-middle.
A solution to this problem is to setup a public facing server (it can be a VPS).  Then, from the pi, create an ssh tunnel between the pi and the public server, such that incoming https connections to port 443 on the public server are forwarded back to the pi.  Then, point the A record for your FQDN to the public server, and go ahead and create your RSA keys on the pi, create a CSR for the FQDN (containing the RSA public key), get it signed by a CA, and configure the web server on the pi to use the cert and the private RSA key for TLS.  Then when a user points their browser to FQDN, they'll in fact be connecting to the pi (through the public server).  The certificate that the user sees will be the one that you created for your FQDN, and the TLS connection will be established using this certificate and the underlying RSA keys that you've created on the pi.  Then, all the public servers sees is the encrypted traffic passing through it.  If you specifically want the pi server to only allow TLS_ECDHE_RSA cipher suites, you can specify this in the web server configuration on the pi.


Is it insecure to expose private bucket names through signed URL? AWS provides signed url to objects in bucket.On backend we can connect with AWS and create such signed urls and send to front-endJust discussing this one use case where we use that signed url to make a put request through javascript, thereby directly uploading file to bucket from webpagehttps://medium.com/@khelif96/uploading-files-from-a-react-app-to-aws-s3-the-right-way-541dd6be689 But signed url contains the bucket name, although the bucket is private i.e. only authorised person can access it But are we still compromising security by letting general public know the private bucket name through the signed url?Is there a possibility that hacker can devise some means to hack into that private bucket, now that they are aware of the bucket name?Just putting one more thought, if someone is aware that if such webpage goes through audit, they will flag this as a possible threat to security

tl/dr: As long as the bucket is not publicly accessible (i.e. you need access keys to read/write), then don't worry about the name.  It
isn't private because your employees probably know it and
hackers/penetration testers routinely perform brute-force searches for
bucket names.  Also, asking "What if someone figures out how to hack
buckets?" is like asking, "What if the CIA planted malicious firmware
in all my computers?"  While theoretically possible, it probably isn't
your biggest concern.

It depends on what you mean by "private".
Actually Private
If you mean that the bucket has no read/write/access permissions from unauthenticated users, then revealing the bucket name in a signed URL doesn't matter because the bucket name is not sensitive data - the keys are.  Trying to hide the bucket name would just be security through obscurity, and in this particular case would add very little security.  Feel free to use signed URLs.
Merely Hidden
If you mean that the bucket allows public users to read/write/access it, and the only thing stopping people from doing so is that they don't know the bucket name, then yes, revealing the bucket name is a bad idea.  Of course for a bucket that contains private/sensitive data, this is a terrible way to manage your bucket anyway.  Hackers and penetration testers regularly find hidden buckets by using brute-force searching.  There are tools to make it easier.  As a result the only way to keep data in a bucket private is by denying all public access.
Threat Modeling
You also asked if you should hide the bucket name just in case some hacker finds a way to hack buckets knowing only the bucket name.  What you need is a threat model.  It's important to recognize that like all features in an application, every security measure has an associated cost (development time, possible loss of functionality, future maintenance costs).  Every security measure should also have a benefit.  As a result there is never really a point where something is "secure" or "not secure".  It's merely a matter of deciding when something is "secure enough", and each individual business is ultimately responsible for finding that point for themselves.  To get you started, I'll mention the risk you are concerned about and add some more to the list:

What if someone figures out how to hack an amazon bucket knowing just the bucket name?
Do you store you AWS keys in your code repositories?  What if one of your employees uses it to steal the data in your bucket?  After all, they already know everything anyway.
What if one of your employees wants to be able to make data available without a signed URL and so decides to just make the whole bucket public, forgetting that it also stores private data?

Personally, item #1 there would be the lowest on my list of concerns.  After all, something like 50% of all data breaches start with internal employees (either intentionally or not).  If someone did find some way to hack an AWS bucket knowing just the bucket name, it would be a huge deal.  It would generate world-wide headlines and Amazon would have people working around the clock until it was fixed.
Besides, you should stop thinking that you can keep a bucket name private.  You really can't.  Your employees probably all know it and they are as likely to cause leaks as "hackers" anyway.  Moreover, performing brute-force searches for buckets is a very common practice in both the hacking and penetration testing world.
Your bucket name isn't private.  It never will be.  Don't kid yourself into thinking otherwise.  Either way, there are an infinite number of possible things to be concerned about, and you don't have time to fix them all.  You need a threat modeling process to help you decide what is most important to your business, prioritize the potential risks for those assets, and then address them according to your available resources.


how to find a cryptography scheme (either authentication or encryption) for which some formal analysis of security has not been done yet I have a project in Cryptography where I have to discuss the provable security of any proposed scheme (encryption or authentication) which has not been discussed yet.

Any pointers on how and where to start?

I tried researching some schemes but I could not find any scheme for which any security analysis has not been already done.

How can I find a scheme for which the security analysis might not have been formally proved? I am need of a starting point.

Thanks

I suggest the Cryptology ePrint Archive:

http://eprint.iacr.org/