Fork me on GitHub
#clojure-uk
<
2016-11-24
>
thomas08:11:49

but morning means morning!!!

oliy09:11:49

It's about simplifying the way you interact with remote APIs and making the integration generative-testable, but I'm rubbish at writing synopses

agile_geek10:11:09

Good to see UGT getting a mention....again!

agile_geek10:11:15

@oliy nothing wrong with a shameless plug now and again (see me, @otfrom and @jonpither for examples!)

agile_geek10:11:24

I'll be there tonight BTW

mccraigmccraig10:11:51

perhaps it should be UTG, so as not to offend any non-english sensibilities @agile_geek ?

agile_geek10:11:26

@mccraigmccraig maybe the phrase 'Universal Greeting Time' should be translated to Esperanto?

mccraigmccraig10:11:48

it seems quite familiar ... "universala saluto tempo"

jonpither11:11:07

I'm going to come here begging for RTs tomorrow for the next clojure in

jonpither11:11:08

if anyone would like to feature on https://juxt.pro/clojure-in.html please let me know - the end of the pipeline is becoming visible

rickmoynihan13:11:14

jonpither: can’t wait to see it!

rickmoynihan13:11:26

its been a really nice series

otfrom13:11:28

acron 👋

otfrom13:11:39

is 1024 chars a suitable max password length?

acron13:11:18

Does anyone have experience 'proxying' multi-part uploads from one server to another? I have a server which expects multipart and have now introduced a front-facing gateway/BFF which is supposed to proxy requests. Simple for most requests but...tricky for multipart. Is this even a thing?

mccraigmccraig13:11:00

@acron can you not just forward the body-stream after parsing the headers to determine destination ?

mccraigmccraig13:11:56

@otfrom 1024 8-bit chars or unicode chars ?

otfrom13:11:37

I'm fine w/16 bit ones. I'm just thinking big enough to do everything, small enough to not be an attack vector. 😉

otfrom14:11:15

though I suppose that the ELB will have a 16MB limit on the request size. upside_down_parrot

mccraigmccraig14:11:31

if you end up having to parse the multipart stream @acron then @malcolmsparks work may help - https://github.com/juxt/yada/blob/master/src/yada/multipart.clj

glenjamin14:11:53

@otfrom do you know what the max input of the password hashing function is?

otfrom14:11:16

glenjamin I don't

otfrom14:11:47

I presume it is just a string and if it is long then bcrypt will take more time to hash it

glenjamin14:11:41

> the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string). from http://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length

acron14:11:51

@mccraigmccraig Thanks, I will have a look at this - it could be as simple as handling the body stream, I haven't tried yet 😎

otfrom14:11:47

glenjamin thx!

otfrom14:11:58

so... 56 bytes then it is

glenjamin14:11:50

I’d be tempted to set it to around 150 chars instead

glenjamin14:11:20

anyone who is picking passwords between 50 and 150 chars probably knows enough to expect some truncation along the way?

otfrom14:11:23

in UTF-8 each char is a byte isn't it?

glenjamin14:11:37

at least a byte - yeah

mccraigmccraig14:11:14

but it may be up to 4!

otfrom14:11:22

I think I'll say up to 50 characters

otfrom14:11:34

with a link to those who want to know more

glenjamin14:11:40

sounds sensible

glenjamin14:11:49

who’s the target audience?

otfrom14:11:02

eventually the general public

otfrom14:11:17

currently people working for local or national government

glenjamin14:11:20

emojis are probably making their way onto dictionary attacks, maybe I should include some cuneiform?

otfrom14:11:25

possibly some other enterprise users

otfrom14:11:41

I'd have more than just the one emoji

korny14:11:23

wow - 56 characters doesn’t sound all that much, really. Though that’s my brain being illogical - part of me thinks “I went from an 8 character password 10 years ago to a 16 character password now, I guess I’ll have to keep doubling” 🙂

acron14:11:30

NIST recommends 64 as a maximum

mccraigmccraig14:11:51

one of my diceware passwords is 31 chars long

korny14:11:17

I guess if people enter a 100 character password, they are probably making false assumptions. I don’t like the idea of limiting though, at some level.

korny14:11:28

I use dice passwords all the time, they are all sorts of lengths

mccraigmccraig14:11:03

i only have a few of them - and that's the longest

otfrom14:11:11

acron I wonder what NIST are hashing with then at 8 ish chars of that won't make a difference

acron14:11:47

TIL about diceware passwords, very neat idea

mccraigmccraig14:11:39

mostly in my current app we encourage people not to have passwords at all

thomas14:11:04

some of my IBM colleagues had passwords that there into the 100's char long.

thomas14:11:14

using lastpass or something like that.

korny14:11:51

I use https://github.com/christierney/diceware 🙂 And then store them in 1password.

thomas14:11:09

@otfrom what ever you do, don't fail it silently as one system I know of did.

thomas14:11:32

ie: enter password successfully -> try and enter again and get wrong password. but it did work if you filled in only the first 12 char of original.

reborg15:11:39

@acron if you need to produce (as opposed to parse) a multipart message, also this can help: https://github.com/reborg/applenews-api/blob/master/src/net/reborg/applenews_api/multipart.clj