iSEC Partners

The pdf report https://www.isecpartners.com/files/iSEC_Aurora_Response_Recommendation… is the report referenced.

iSEC Partners/NCC Group - San Francisco, Seattle, Austin, New York City - Job Title - Security Engineer Like the old adage goes, April showers bring May jobs. That was lame, but our jobs and client engagements are not. If you love security and research, iSEC/NCC just may be a perfect fit for you. At iSEC, part of NCC Group, you will spend most of your day thinking about security systems and how they can break. This is a very creative job that gives individuals a lot of freedom to be clever while learning new technologies at a very fast pace. Typical engagements will pair you with another experienced security consultant who you will learn from and teach along the way. Engagements are usually 2-4 weeks long. In a year, you will be exposed to 15-20 products and technology stacks. Your work will typically initiate person-months of security improvements in products millions of people use. You will have access to senior engineers/architects and your findings/ideas will be heard by senior decision makers. You will have enormous impact in making the software people use safer. All of our consultants are also security researchers, with dedicated research time. We like to let our research speak for itself: https://isecpartners.github.io/ Check out all of our career opportunities here: https://www.isecpartners.com/about/careers.aspx We're always looking for folks passionate about what we do. We'd love to hear from you!

New York City, Seattle, and San Francisco - iSEC Partners - Application Security Consultants iSEC Partners is currently looking for Security Researchers and security-focused software developers to fill openings in its application security consulting practice. We are seeking entry, senior and principal level candidates. Job duties will include project delivery within iSEC consulting engagements and cutting-edge research into current technologies and attacks. http://www.isecpartners.com/careers/ iSEC Partners is a proven full-service security consulting firm that provides penetration testing, secure systems development, security education and software design verification. iSEC Partners' security assessments leverage our extensive knowledge of current security vulnerabilities, penetration techniques and software development best practices to enable customers to secure their systems against ever-present threats on the Internet. Primary emphasis is placed upon helping software developers build safe, reliable code. Areas of research interest include application attack and defense, web services, operating system security, privacy, storage network security and malicious application analysis. Our goal is to create a new standard for customer satisfaction and become the pre-eminent leader in security consulting, research and tool development.

either approach avoids leaking useful information, doesn't it? one does so by guaranteeing identical times. the other by passing the information through a one-way function. the link given in the advice you point to includes a fairly detailed discussion / comparison - https://www.isecpartners.com/blog/2011/february/double-hmac-verificati…

C'mon man, you're better than that. I'm sure you know how to use google to find the black hat presentation: https://www.isecpartners.com/media/105564/ritter_samuel_stamos_bh_2013… Which you then know how to use to find the papers by Joux. http://eprint.iacr.org/2013/095.pdf http://eprint.iacr.org/2013/400.pdf A lot of smart and proven people put together this information and if they're worried, I'm worried.

Original slide deck here: http://isecpartners.com/media/105564/ritter_samuel_stamos_bh_2013_cryp…

def encrypt(salt, password, data): ^^^^^^ You're the crypto library. Don't ask the user to choose the salt, they won't do it right. key = _expand_key(salt, password) Most crypto people would advise you to generate two separate keys for encryption and MAC. hmac = data[-HMAC_HASH.digest_size:] hmac2 = HMAC.new(key, data[:-HMAC_HASH.digest_size], HMAC_HASH).digest() if hmac != hmac2: ^^^^^^^^^^^^^ Possible timing attack. Consider doing another HMAC of each HMAC and comparing those instead. See https://www.isecpartners.com/news-events/news/2011/february/double-hma… offset = getrandbits(AES.block_size*8) Counter.new(AES.block_size*8, initial_value=offset, allow_wraparound=True) I don't like that you allow wraparound counters, in fact, I'd go so far as to call it broken. This is not allowed by NIST-specified CTR mode. Bad Things^TM will happen if multiple messages (or different parts of a single message) are ever encrypted with the same key. Seriously, screwups like this have shortened wars. return prefix + encrypted + hmac Put some type of magic constant in front of this. You'll be glad you did later when you have to change the format or simply the PBKDF2 count. HMAC_HASH = SHA256 but later... def _expand_key(salt, password): ... return PBKDF2(....) I don't see where you're telling PBKDF2 what hash to use for its HMAC. It's probably defaulting to something like SHA-1.